RE: [ActiveDir] Active Directory Cookbook

[Robbie Allen]

Title: Message

You are right, that wasn't the best way to fix them.  I added those quick fixes a while back so the scripts wouldn't fail on forests with password complexity enabled.  I just added "corrected" code for 6.1-6.3 (http://www.rallenhome.com/books/adcookbook/code.html#ch6).  All I did was comment out the lines that set userAccountControl and put a note about why it isn't necessary to set it.

 

Thanks!

Robbie Allen 

-----Original Message-----
From: Michael B. Smith [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 25, 2003 3:35 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Active Directory Cookbook

OK, Robbie fixed the examples on the webpage for the Tuna book (although I personally don't like the way he changed 6.3) -- however, his change was to set userAccountControl to disabled (514).

 

Is there an advantage, or disadvantage, either way -- to setting userAccountControl before the first SetInfo or not? Just preference?

---

From: Joe [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 25, 2003 2:00 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Active Directory Cookbook

Rick, I think he may be referring to our conversation....

 

1.

 

Here is what I vote for:

 

set objParent = GetObject("LDAP://<ParentDN>")
set objUser   = objParent.Create("user", "cn=<UserName>")
objUser.Put "sAMAccountName", "<UserName>"
objUser.Put "userPrincipalName", "<UserUPN>"
objUser.Put "givenName", "<UserFirstName>"
objUser.Put "sn", "<UserLastName>"
objUser.Put "displayName", "<UserFirstName> <UserLastName>"
objUser.SetInfo
objUser.SetPassword "password1"
objUser.AccountDisabled=FALSE
objUser.SetInfo

 

Note you don't have to set the account disabled. The default useraccountcontrol on the create will be disabled. You need to swing back and enable it and set the password.

 

 

2.  If a single domain

    adfind -default -f "&(objectcategory=person)(samaccountname=*)" -dn

 

    NOTE: That may pull trust accounts to, I don't have trusts set up on my home domain to check.

 

    If multiple domain forest

 

    adfind -h dcname -default -f "&(objectcategory=person)(samaccountname=*)" -dn

             or

    adfind -b dc=domain,dc=com -f "&(objectcategory=person)(samaccountname=*)" -dn

 

    NOTE: Same note.

 

    If you do get trusts as well, you need to filter them out and at 1:53AM the thing I think you would do is add a (!samaccountname=*$) which really sucks because !'s kill search time.

 

  

The first single domain query yanked my 2034 userids in my home domain in about 5 seconds. That is with a PIII-930 with 512 MB running about 10 normal apps(one is VPC 5.2 with a Windows Server 2003 Enterprise guest fired up and allocated 64MB RAM) against my W2K DC which is PII-450 w/ 128MB RAM.

 

 

  joe

 

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Friday, October 24, 2003 6:35 PM
To: [EMAIL PROTECTED]

Michael -

 

1) Yes, this is one way.  Just discussed this topic on the list, with code samples, so check the archives.  Setting the user to disabled and then applying the complex password is valid.

2) Not there directly....  ;-)

 

Rick Kingslan  MCSE, MCSA, MCT
Microsoft MVP - Active Directory
Associate Expert
Expert Zone - www.microsoft.com/windowsxp/expertzone
 

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith
Sent: Friday, October 24, 2003 12:35 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Active Directory Cookbook

It's a great book.

 

Two questions: 1) did you guru's here on activedir come to the conclusion that, due to password complexity, a user should be created disabled? Does that affect any recipes other than 6.1, 6.2, and 6.3? 2) I think you should add one of the simplest and (in my opinion) the most common AD query as a recipe: how to find all the users in a domain.

---

From: Robbie Allen [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 12:43 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Active Directory Cookbook

Thanks for all of the positive feedback about the book.  I give the credit to my all-star cast of reviewers :-) 

 

My main goal was to produce a reference that would help AD admins get their job done quicker and easier.  There is just too much stuff AD admins have to remember and that's why I thought the O'Reilly cookbook format would work especially well in this case.

 

If you have the book (or even if you don't), be sure to check out the following web site, which has all of the code in the book and any corrections: http://www.rallenhome.com/books/adcookbook/code.html

 

Keep the feedback coming....

 

Regards,

Robbie Allen

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 11:51 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [ActiveDir] Active Directory Cookbook

Agreed - I got mine yesterday from Amazon and I must say that this should be on the shelf of every AD administrator. Period.

Michael Parent MCSE MCT
Analyst I - Web Services
ITOS - Systems Enablement
Maritime Life Assurance Company
(902) 453-7300 x3456

"Lou Vega" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/24/2003 10:37 AM Please respond to ActiveDir

To:        <[EMAIL PROTECTED]>         cc:                 Subject:        [ActiveDir] Active Directory Cookbook

Received my very own copy of Mr. Robbie Allen's "Tuna" book last night from Amazon.com - in the first night's reading the book is already proving it's worth as I see how to do certain things much simpler than I had done them before (with regards to the VBScripts included), as well as learn new things I didn't realize could be done (in both AD2K and AD2K3). The book will be very handy as I continue to stand up my development Windows 2003 domain.
 
To anyone else on this list who hasn't gotten it yet...it's a worthwhile addition to your Active Directory library.
 
To Robbie (and all the others who assisted him!) - thanks for a great resource!
 
r/
Lou