Learn about Windows PowerShell
Hey, Scripting Guy! How can I use alternate credentials when searching Active Directory?-- PT
Hey, PT. So what’s the big idea here? Devoted readers of this column (both of them) know that we usually love tackling questions where the answer involves searching Active Directory. Why? That’s easy: because we don’t really answer those questions. Instead we simply hammer out a script and then, instead of explaining how the script works, tell people to read the two-part series Dude, Where’s My Printer? for more information. As you can tell, that makes for a nice, easy day at the office.
But your question is different: unfortunately for us, specifying alternate credentials isn’t mentioned anywhere in our series on searching Active Directory. That means we’re actually going to have to answer this question. Talk about unfair: not only do we have to come in to work, but now we’re expected to actually do something while we’re here!
Trust us: that is not the American way.
So we’ll make a deal with you: we’ll answer your question, but only by focusing on the part of the script where you specify alternate credentials. If you need more information about the rest of the code, or if you need more information about searching Active Directory, please see the two-part series Dude, Where’s My Printer?
Boy, if only we had a dollar for every time we’ve said that.
Here’s a script that uses alternate credentials in order to search Active Directory:
Const ADS_SCOPE_SUBTREE = 2
Set objConnection = CreateObject("ADODB.Connection")Set objCommand = CreateObject("ADODB.Command")objConnection.Provider = "ADsDSOObject"
objConnection.Properties("User ID") = "fabrikam\kenmyer"objConnection.Properties("Password") = "A2sXrco1Fq1#om!"objConnection.Properties("Encrypt Password") = TRUEobjConnection.Properties("ADSI Flag") = 3
objConnection.Open "Active Directory Provider"Set objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 1000objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
objCommand.CommandText = _ "SELECT Name FROM 'LDAP://DC=fabrikam,DC=com' WHERE " _ & "objectCategory='user'" Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirstDo Until objRecordSet.EOF Wscript.Echo objRecordSet.Fields("Name").Value objRecordSet.MoveNextLoop
Like we said, for today we’re going to focus on these four lines of code, the four lines where we specify the alternate credentials:
Note that these four lines of code are required only if you want to conduct the search under alternate credentials; that is, only if you want to bind to Active Directory using a user account other than the one you used when logging on to Windows. If you want to do a search using your current logon credentials all you have to do is remove these four lines of code and the script is good to go.
As you can probably tell (the object reference objConnection is a dead giveaway), these four lines of code involve four properties of the ADO (ActiveX Data Objects) Connection object. The properties User ID and Password should be self-explanatory: these are simply the user name and the password for the account you want to use when binding to Active Directory. In this example, we’ve specified the User ID using the domain\user name syntax. However, we could also specify the user name as the logon name itself (e.g., kenmyer) or as the user’s UPN (Universal Principal Name): email@example.com. That’s entirely up to you.
As for the password, we’ve hard-coded the password into the script for educational purposes. Needless to say, however, that’s not the way we recommend that you do things. Instead, you should probably have the script prompt you for a password each time the script is run. If you’re not sure how to do that, well, don’t worry about it: as we are wont to do, we’ll simply refer you somewhere else. (In this case, a previous Hey, Scripting Guy! column on prompting for - and masking - passwords.)
That leaves us with just two properties to dispose of. Setting Encrypt Password to True simply tells the script to encrypt the password when sending it across the network; by default, this value is set to False. The ADSI Flag property, meanwhile, is a bitmask property used to specify authentication options. The value 3 is actually a bitmask value composed of two separate properties:
Requests secure authentication. When this flag is set, Active Directory will use Kerberos, and possibly NTLM, to authenticate the client.
Requires ADSI to use encryption for data exchange over the network.
You can find more information about the ADSI Flag property in the ADSI SDK.
That’s really all you have to do: configure the appropriate values for those 4 properties and away you go.
Now, if you’ll excuse us, we need to take a break. After all, the last thing we expected to have to do at work today was work!