How to use the Group Policy based Restricted Groups feature to create secure and flexible administrative delegations.
One common problem in Windows Active Directory environments is how to delegate administrative control over member servers and client computers. The only default option is to use the Domain Admins group, since it is added to all local Administrators groups on all domain members when the machine is joined to Active Directory.
Every Windows computer, either client or server, will have a local account database called “SAM” (Security Account Manager). In the local SAM database we will always find the familiar Administrators group. This local group is by default given control over all rights and permissions on each local server. Membership in the local Administrators group is most often necessary to handle the server, including everything from operating system configuration, installation of applications, troubleshooting and patching. The problem is however how to make sure the correct IT staff accounts has the membership on the correct servers or clients.
Some common ways to accomplish this:
1. Adding all accounts that need some administrative access to the Domain Admins groups. This is the simplest way, but extremely unsecure, since one single incorrect action from any Domain Admins member could destroy every single computer and server in the organization, including all critical data.
The number of accounts in Domain Admins also tend to grow and both service accounts and temporary consultants could be members for years, perhaps with very weak passwords.
2. Another approach is to manually add accounts or groups to the correct local Administrators group for different servers. This is a much better option, for example adding the IT staff accounts responsible for SQL to the local Administrators group on all SQL servers. Some disadvantages however is the problem to maintain the local memberships over time when people are hired or leaves the company, or when new servers are added, since we have to attach to each server to add/remove accounts in the local SAM database.
This would be hard for a smaller organization, but nearly impossible if having hundreds of servers and thousands of clients.
3. A third option is to use a Group Policy based method called “Restricted Groups“. This will make maintenance fast, more easy to survey and much more secure. This could be used for both servers and client computers in companies of all sizes. It will also work on all operating systems running Windows 2000 or newer.
Restricted Groups has been available in Active Directory for over ten years, but unfortunately many administrators are not aware of this powerful feature.
Here is a step-to-step guide how to setup up the Restricted Groups feature.
Begin by creating as many groups as you have need for different administrative delegation. Keep in mind that it is better to have too many groups than too few, since more groups will give more flexibility in the future. Make the groups with the scope Domain Local and give them descriptive names and good descriptions. Place the groups in a suitable Organizational Unit. Above is some groups that should be used for delegation of PC clients in different sites of a fictional company.
Now create a new Group Policy Object and link it to the first OU with client computers. Give it a good name and select “Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Groups”. See above the view in the Group Policy Editor.
In the first Add Group dialog (above) select the new Domain Local group you made for this OU, see above. Do not select the Administrators group at this moment. OK to move on.
On the next screen use the lower Add (this is very important, do not use the upper Add button) and then select “Administrators” and finish with OK. This does not remove any accounts or groups already present in the local Administrators, it will only include the new domain group.
Now we are done with the first GPO. Repeat this for every OU with computers, create a new GPO and link to the OU and configure the Restricted Group option to add the proper Domain Local Group to the local Administrators.
For all computers (either servers or clients) the new domain groups will be included on the next background Group Policy refresh, typically within two hours. The result will be as above, where members of the domain based Admin-BER-clients group now is local adminstrators of all clients in Berlin OU. The screenshot above shows the Administrators group in the SAM database of a computer in this OU.
The result will be that we have a number of easily recognizable groups in Active Directory, in which we can drop either global groups or single accounts and in one action give the IT staff administrative permissions to hundreds of computers. We can also by the same simple action remove the access.
When new clients or servers are installed and being placed in the correct OU the GPOs will make sure the Admin groups are properly populated. This will even work when moving existing computer accounts between the Organizational Units.
Isn’t “Restricted Groups” the old way to do it (2003 style) ?
Today i tend to use GPP for this kind of things, is it a better approach or am i mistaken ?
Thanks for the comment Neb. I think both ways work good, but an advantage for using the older Restricted Groups way is that it always works for any Windows server, including even Win 2000. The extra CSE for Group Policy Preferences is only guaranteed on Windows 2008 and newer, so to be sure to reach for example all Windows 2003 servers the Policy way could be safer.