How Can I Add a Domain User to a Local Administrators Group?

Hey, Scripting Guy! How can I add a domain user to the local Administrators group in a computer?

— MB

Hey, MB. One reason we started doing this column was because we wanted to know more about what system administrators do (and script) on a regular basis. As it is, sitting here in our luxurious penthouse suites atop the Microsoft campus, we’re not always fully in tune with the way things are done in the real world. For example, in the Script Center we have a sample script that shows you how to add a user to the local Administrators account:

strComputer = “atl-ws-01”
Set objGroup = GetObject(“WinNT://” & strComputer & “/Administrators”)
Set objUser = GetObject(“WinNT://” & strComputer & “/kenmyer”)
objGroup.Add(objUser.ADsPath)

So what’s wrong with this script? Nothing, except that this might not be the most practical example ever devised. After all, this script shows you how to add another local user to the Administrators group. That’s OK, but what most of you really want to know (as we can tell by the number of emails we’ve received to this effect) is how to add a domain user to the local Administrators group. Message received, loud and clear: Let’s show you how to add a domain user to the local Administrators group.

Incidentally, the script to do this is almost identical to the script for adding a local user to the Administrators group. The only difference, as we’ll see in a moment, occurs in line 3. In the preceding script, we bind to a local user account on a computer using this line of code:

Set objUser = GetObject(“WinNT://” & strComputer & “/kenmyer”)

We then pass the ADsPath of that user account to the Add method, which adds the user to the group:

objGroup.Add(objUser.ADsPath)

We want to do the same thing with our new script, only we don’t want to bind to a local user account, we want to bind to a domain user account. And so that’s what we’re going to do, substituting in a new line 3:

Set objUser = GetObject(“WinNT://fabrikam/kenmyer”)

Here we’re using the WinNT provider to bind to the fabrikam domain; more specifically, we’re using the WinNT provider to bind to the kenmyer user account in the fabrikam domain. Ah, we see some of you are upset by this. “Why are they using the WinNT provider?” you’re muttering. “Aren’t they supposed to use the LDAP provider when binding to Active Directory?”

The answer to that question is yes, most of the time. However, suppose we used the LDAP provider to retrieve the ADsPath for kenmyer, using code like this:

Set objUser = GetObject(“LDAP://CN=kenmyer,OU=Finance,dc=fabrikam,dc=com”)

That looks OK, except we get back an ADsPath that looks like this:

LDAP://CN=kenmyer,OU=Finance,dc=fabrikam,dc=com

That’s OK, too … at least until you try passing that value to the local computer. Remember, the Security Account Manager on the local computer speaks WinNT, it doesn’t speak LDAP. If you try passing an LDAP path to the local computer it just won’t work.

Instead, we need to pass an ADsPath that looks like this:

WinNT://fabrikam/kenmyer

And guess what? If we bind to the fabrikam domain using the WinNT provider, that’s exactly the kind of ADsPath we’ll get back. If you’re working strictly with Active Directory then you should use the LDAP provider. But if you’re going to grab an account out of Active Directory and use that account in a local computer group you’ll have to use the WinNT provider.

We know: all this talk of providers and ADsPaths and what-not is making your head spin. But don’t fret too much about that. Instead, just use this script to add a domain user (a user named kenmyer, in the fabrikam domain) to the local Administrators group on the computer atl-ws-01:

strComputer = “atl-ws-01”
Set objGroup = GetObject(“WinNT://” & strComputer & “/Administrators”)
Set objUser = GetObject(“WinNT://fabrikam/kenmyer”)
objGroup.Add(objUser.ADsPath)

And keep those cards and letters coming in!