Here’s a script that uses alternate credentials in order to search Active Directory:


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”) = TRUE

objConnection.Properties(“ADSI Flag”) = 3

objConnection.Open “Active Directory Provider”

Set objCommand.ActiveConnection = objConnection

objCommand.Properties(“Page Size”) = 1000

objCommand.Properties(“Searchscope”) = ADS_SCOPE_SUBTREE

objCommand.CommandText = _

“SELECT Name FROM ‘LDAP://DC=fabrikam,DC=com’ WHERE ” _

& “objectCategory=’user'”

Set objRecordSet = objCommand.Execute


Do Until objRecordSet.EOF

Wscript.Echo objRecordSet.Fields(“Name”).Value



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:

objConnection.Properties(“User ID”) = “fabrikam\kenmyer”

objConnection.Properties(“Password”) = “A2sXrco1Fq1#om!”

objConnection.Properties(“Encrypt Password”) = TRUE

objConnection.Properties(“ADSI Flag”) = 3

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., jdalbera) or as the user’s UPN (Universal Principal Name): 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:

Constant Value Description
ADS_SECURE_AUTHENTICATION 1 Requests secure authentication. When this flag is set, Active Directory will use Kerberos, and possibly NTLM, to authenticate the client.
ADS_USE_ENCRYPTION 2 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.