Re: using dsadd remotely
From: Stew Basterash (stewartbash_at_hotmail.com)
Date: 03/31/04
- Next message: Chad: "Adding Bulk Number of User Accounts"
- Previous message: Chriss3: "Re: Making all users local admin on workstations"
- Next in thread: Derek Melber [MVP]: "Re: using dsadd remotely"
- Reply: Derek Melber [MVP]: "Re: using dsadd remotely"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 31 Mar 2004 08:27:51 -0600
The problem with W2K3 is the password policy... I had this very issue...
Change password policy, or change your password to make it meet the
complexity requirments of W2K3... I was lucky... My script included a file
that contained usernames and passwords... only one met the complexity
requirements... it was obvious when all accounts were created but only one
was enabled...
"Stivie S." <stefan.suesser@computacenter.com> wrote in message
news:387B4D5A-F408-49F6-99FA-9CB345A9EF54@microsoft.com...
> Hi Derek,
>
> my 2nd thought was that your domain may use a password policy that
prevents setting the password you specify in your script. For example, when
I try to run the "dsadd" command against our W2K3 AD domain without
specifying a password that meets our password policy, I get the following
error:
> "dsadd failed:cn=test12345,ou=myOU,dc=domain,dc=com:Unable to update the
password. The
> value provided for the new password does not meet the length, complexity,
or history requireme
> nt of the domain."
>
> However, the user account gets created but is "disabled"
>
> ----- Derek Melber [MVP] wrote: -----
>
> Stivie,
>
> I had considered that, and included the -samid, but got the same
error. So,
> I took your line of thought and even added a password, since AD
requires it.
> I still get the same error, with -samid and -pwd.
>
> --
> Derek Melber
> BrainCore.Net
> derekm@braincore.net
> "Stivie S." <stefan.suesser@computacenter.com> wrote in message
> news:14FAEFCA-701F-4F96-A949-64E5ED68D09C@microsoft.com...
> > Hi Derek,
> >> as you may know, the user-class in Active Directory has mandatory
and
> optional attributes. The mandatory attributes must be set when a new
user is
> created, the optional attributes may be set, but are not required.
> > From the AD schema documentation, there are 8 mandatory attributes
for the
> user class. 6 of them are set automatically by the system, the other
two you
> have to specify when you create a user. These two attributes are
"common
> name" and "sAMAccountName".
> > You provide the "common name" in your "dsadd" call, so I would try
to add
> the user with specifying the sAMAccountName, in addition. As dsadd
tries to
> "guess" the sAMAccountName when you do not provide one, make sure
that the
> samID you specify when calling "dsadd" is unique in your domain.
> >>> ----- Derek Melber [MVP] wrote: -----
> >> Any dsadd guru's out there?
> >> I am just testing and playing with dsadd and it seems to be a
quirky
> command. I have my 2k3 DC and my XP Pro client (joined to the
domain). I am
> logged into my XP Pro box as a domain admin from the DC. I run the
dsadd
> tool to create a user in the domain using the following syntax:
> >> dsadd user "cn=user1,ou=ou1,dc=acme,dc=local" -s dc1
> >> I get the following back:
> >> dsadd failed:cn=user1,ou=ou1=dc=acme,dc=local:The network
path was
> not found.:Set password failed.
> >> Then, I go to DC1 and the user is created!
> >> Any ideas?
> >> --
> > Derek Melber
> > BrainCore.Net
> > derekm@braincore
>
>
>
- Next message: Chad: "Adding Bulk Number of User Accounts"
- Previous message: Chriss3: "Re: Making all users local admin on workstations"
- Next in thread: Derek Melber [MVP]: "Re: using dsadd remotely"
- Reply: Derek Melber [MVP]: "Re: using dsadd remotely"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
