Local Control

Provide users with local admin access via this nifty script.

• By Bill Boswell
• 10/15/2003

Bill: In our environment we set all users to have local admin access to their PC. We manually add the Domain User to the Local Administrators group of the PC they use. Is there a way via a logon script to add the locally logged on user automatically to the local admin group?

I came across the ADDUSERS.exe file, but this requires use of a local admin account and prompts you for a password. I'm looking to be able to have a user logon to their PC via our default domain and, when the logon script runs, to automatically add the users domain account into the local administrators group of the PC without any user intervention.
—Daniel

Daniel: I think I have a good solution, but it uses Group Policy Objects so it only works if your clients run Windows 2000 or XP. Here goes:

There's a Security Group Policy called Restricted Groups. This policy allows you to specify the membership of a group on a local machine or in the domain. The policy setting is in Computer Configuration | Windows Settings | Security Settings | Restricted Groups.

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

When you test this policy, be sure to create a test GPO and link it to a test OU. You don't want to cause havoc on your desktops during testing if you accidentally overwrite a critical member in a critical local group.

Create the policy setting by right-clicking the Restricted Groups icon and selecting Add Group from the flyout menu. This opens an Add Group window.

Don't click the Browse button. This allows you to browse the domain, but you want to control the membership of a local group. Instead, just type the group name into the field exactly as it appears in the local group listing. For example, to control the membership of the local Administrators group, type "Administrators". (The policy entry is not case-sensitive.)

When you click OK, a Properties window opens. The window has two parts: "Members Of This Group" and "This Group Is A Member Of."

Click Add next to the Members Of This Group field. The Add Member window opens. Click the Browse button and browse for a group called INTERACTIVE. This is a well-known SID representing the user that has logged on at the console of the machine.

Putting the Interactive group into Administrators gives local admin privileges to whoever logs in at the console. Use a bit of caution here, because some applications finesse the local logon feature for network clients. For example, the IUSR account in IIS is given local logon, so you don't want to apply this policy to any machines running IIS or Personal Web Services. To be completely safe, don't link this GPO to any OUs that contain servers.

Because the Restricted Groups policy overwrites the current content of the specified group, you'll need to also add the Domain Admins group and the local Administrator account to this restricted group policy. Don't browse for the Administrator account; just type the word "Administrator" into the Add Member window. Otherwise, you'll add the domain Administrator account and the local Administrator account will not have admin rights.

As soon as you click OK on the list of names, the policy gets written to Sysvol. If you wait for 90 to 120 minutes, the standard background refresh at the clients will pull the policy from Sysvol and the security engine will apply the policy to the local SAM. If you want to hurry up the process for testing, run GPUPDATE at a Windows XP desktop or SECEDIT /refreshpolicy machine_policy at a Windows 2000 desktop. Use the Computer Management console to see the local accounts and groups and verify that the Administrators group has the members you specified.

A final word of caution. Some applications require local administrative access. These apps typically install a member in the local Administrators group. Before you put this Restricted Groups policy into production and overwrite all the current membership entries, you'll want to sweep the Administrators group on your desktops to find any non-standard members. Here's a brief script that obtains a list of member computers in a domain and prints out the membership of the local Administrators group:

Set RootDSE = GetObject("LDAP://RootDSE")
domainDN = RootDSE.Get("DefaultNamingContext")

Set connection = CreateObject("ADODB.Connection")
connection.Provider = "ADsDSOObject"
connection.Open

Set command = CreateObject("ADODB.Command")
Set command.ActiveConnection = connection
Command.Properties("Page Size") = 3000
   'big page size for lots of computers
Command.Properties("searchscope") = 2 'search entire domain
Command.CommandText = "SELECT AdsPath, cn _
   FROM 'LDAP://" & _
   domainDN &_
   "' WHERE objectcategory = 'computer'"

Set rs = command.Execute

On Error Resume Next
Do Until rs.EOF
   computerFlatName = rs.fields("cn")
   WScript.Echo _
     "Members of Adminstrators local group on " & _
     computerFlatName
   Set administrators_group = GetObject("WinNT://" & _
     computerFlatName & "/administrators,group")
   If Err.Number <> 0 Then
   WScript.Echo vbTab & "Computer not available."
   Else
     For Each member In administrators_group.members
     WScript.Echo vbTab & member.name
     Next
   End If
   Set administrators_group = Nothing
   Err.Number = 0
   WScript.Echo vbNL
   rs.MoveNext
Loop

You can modify the script to use an OU rather than the entire domain to reduce the network traffic.

Hope this helps.