Skip to content

Server 2008 Gpo User Rights Assignment Power

There are hundreds and possibly thousands of Administrator accounts on your network today. Do you have control over these accounts and what they are capable of doing and accessing?


Why Control the Administrator Accounts?


If you are like most administrators of Windows networks, your primary thrust of attention is towards the Active Directory enterprise. With all of the security concerns regarding domain controllers, servers, services, applications, and Internet connectivity, there is little time to spend ensuring that the Administrator accounts throughout your enterprise are controlled correctly.


The reason that these accounts need to be controlled is multifold. First, there are potentially thousands of these accounts on a medium to large network, so there are many avenues for these accounts to get out of control. Second, most companies allow "standard users" access to the local Administrator account, which is a recipe for disaster. Third, the original Administrator account should be used sparingly, so to limit the privilege is an excellent measure to take.


How Many Administrator Accounts do you have?


To determine the answer to this question, you need to do some ciphering (as Jethro Bodine would say). Since every Windows desktop computer has a local Administrator account, we can start here. These computers include Windows NT, 2000, XP, and Vista. Be sure to include all of the client computers that are used by "admins", developers, executives, and even in the server room as service or application devices. If you have kiosks, lab computers, centralized workstations, etc, these also need to be included. Don't count user accounts here, as the number of devices might not match up desktops with the number of users.


Now, you need to consider the number of servers that you have. Here, don't include domain controllers yet. For your servers, you will need to consider servers handling the following tasks: data storage, print, application, service hosting, back office, mail, fax, etc. Each of these devices has a local SAM and will therefore have a local Administrator account. This account might not be used very often, but that might be even more of a reason to control the privileges.


Finally, you need to consider your domain controllers. Here, you will have one important Administrator account, which is the account that controls Active Directory. Not only does this one Administrator account control Active Directory, but it is the root domain, as well as the enterprise admin. If you have more than one domain, you will have one of these key Administrator accounts per domain. The subsequent Administrator accounts only control power over the domain where they are located, but are still very powerful accounts.


Limiting Logon Privileges


There is not much you can do to physically limit the logon privileges of these Administrator accounts. However, these accounts should not be used on a regular, daily basis. Therefore, some form of action should be taken to limit the use. The obvious choice is to restrict which users know the passwords for these accounts. For the Active Directory related Administrator accounts, it is a good idea to have a process for applying the password where no one user knows the entire password. This can easily be done by having two different administrators input a portion of the password, then documenting that portion. If the account ever needs to be used, both documented portions of the password can be obtained. Another option is to use an auto-generating password program, which can create a complex password.


Restricting the Local Administrator Accessibility


Whether you are allowing the standard users to have admin access to their desktop or not, you need to limit their access to the local Administrator account. Two easy ways of doing this include changing the local Administrator account name and resetting the password for this account often. There is a Group Policy Object (GPO) for each of these settings. The first is under Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options, as shown in Figure 1. The policy you want to configure is Accounts: Rename Administrator Account.



Figure 1: Policy to rename the local Administrator account


The second policy you will need to configure is part of the new suite of policy settings that will be coming out in late 2007 (http://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx). This policy is part of the PolicyMaker suite, and is located under Computer Configuration|Windows Settings|Control Panel|Local Users and Groups, as shown in Figure 2.



Figure 2: Policy to reset the local Administrator account password


Note:
This will not prohibit the standard user from controlling this account periodically, as the only way to do that is to remove the standard user from having admin control over their desktop.


Reducing Network Access


As everyone knows (but few respect), the Administrator account should not be used on a daily basis. With this said, there is no reason to have the network configured to allow access around the network with this account. One great way to limit privileges for this account is to not allow the Administrator account access to servers and domain controllers from across the network. This can be handled easily by a GPO setting. This GPO setting is located under Computer Configuration|Windows Settings|Security Settings|Local Policies|User Rights Assignment, as shown in Figure 3. The policy you want to configure is named Deny Access to this Computer from the Network.



Figure 3: Policy to deny Administrator access to a computer from over the network


Other Configurations


You can also be very detailed with limiting the access of the Administrator account throughout the enterprise. Other examples of where you can limit access include:



  • Not using the Administrator account as a service account
  • Denying access to Terminal Services on servers and domain controllers
  • Deny Administrator the ability to logon as a service on servers and domain controllers
  • Deny Administrator account from logging on as a batch job

These settings will just limit the scope of influence that the Administrator account has for any one computer or the network. These settings won't prohibit a user that has admin privileges from configuring this access. In this case, you need to establish auditing of both the configuration of the Administrator account, as well as when this account is used for logging in and using User Rights. Again, these configurations are accomplished using GPOs. You can find these settings under Computer Configuration|Windows Settings|Security Settings|Local Policies|Audit Policy, as shown in Figure 4.



Figure 4: Policy to establish auditing of account use and management


Summary


The Administrator account is the most powerful account that is available in a Windows operating system world. This account is so powerful, it should not be used unless there is a specific need, such as disaster recovery or initial configurations. In order to limit the scope of influence that these accounts have, additional settings can be made to protect where the Administrator account can be used and what it can access. Group Policy is the mechanism that is used to distribute these reduced privilege settings to all computers where the Administrator needs to be limited. Once these settings are in place, the Administrator account will now be controlled, not only in function, but also for tracking in case an intruder attempts to attack your network with the account.



Read Next




Adding users to local security groups using Group Policy

You may find that you need to add users to one or more local groups, such as Power Users or Administrators, on their computer.  While you can do this fairly easily on a case by case basis, it's a lot more difficult to do in a large distributed environment.  This can be accomplished much easier using the Restricted Groups GPO setting in Group Policy.

The Restricted Group setting allows you to configure membership in groups within Active Directory or in the local security accounts manager (SAM) of domain-joined computers. 

In this example, we will add all domain users to the local computers' Power Users group for all computers in the domain.
Note: Be aware that this method will replace the membership of the group you are configuring, it does not merge this membership with any members who currently exist in the local group.
  • Open the Group Policy Management Console
  • Edit the Default Domain Policy
  • Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups
  • Right-click Restricted Groups and select Add Group...
  • The trick to adding a local group is to just type in the group name.  Do not browse to find the Power Users group, because this will resolve to the domain's Power Users group.  Type Power Users, as shown below, and click OK.
  • Another window will pop-up to let you configure the properties of the Power Users Restricted Group.  For Members of this group, click Add.
  • Click the Browse button and browse for the group in Active Directory that you want to add to the local Power Users group.  In this example, use Domain Users and click OK, as shown below.
  • Close the GPO Editor and the Group Policy Management Console
Wait a sufficient amount of time to allow the GPO to replicate throughout all the domain controllers in the domain, then restart the computers where the policy applies.  This is required because the GPO affects the Computer Policy which applies when the computer starts up.

When the policy is processed, the computer will attempt to resolve the Power Users name that you typed to a local group first, then a domain group if no local match is found.

You can do the same process above for any other OU to scope the GPO to a specific set of computers.  If you want to add users to the local Administrators group, simply type that name instead of Power Users.