Best practices for delegating control in Active Directory

The following excerpt is from Chapter 2 of the free eBook "Administrator shortcut guide to Active Directory security" written by Derek Melber and Dave Kearns and available at Realtimepublishers.com. Click for the complete book excerpt series.

Best practices for delegating control in AD

You might be tired of me hounding you on the phases of planning and testing, but I can't stress enough how important these two phases are in the stability, security, and long-term effectiveness of your AD deployment. Thus, the initial best practice for AD delegation of control is planning and testing. The next best practice is to use the power of AD as much as possible by employing OUs for delegation, non built-in groups for delegation, and nested OUs for the optimum design of your delegation.

• OUs for delegation -- OUs must be designed and implemented properly and the correct objects (user, group, computer) must be placed in them in order for delegation to be successful.
• Use of non built-in groups -- Built-in groups give too wide of privilege in the domain, so the delegation design must include the creation and location of new groups designed solely for delegation.
• Use of special administrative accounts -- For best security and autonomy of data administrators' and service administrators' tasks, it is ideal to create user accounts for when the user performs these tasks.
• Use of nested OUs -- There will be various levels of data administrators within AD. Some will be delegated control over an entire data type, such as servers, and others might only be given a subset of the data type, such as file servers. This hierarchy is established by creating OUs and sub-OUs, with the delegated administration at the top having more privilege than those lower in the OU structure.

There are additional best practices and tips that have been successful for many organizations that use delegation of administration to control security of AD. One best practice while delegating administration is to not provide too much delegation. For example, suppose you are delegating administration to a user in the sales department. You are giving the user the ability to control membership in the groups for the sales department. The OU structure related to sales might look something like:

Sales

An easy solution for delegating the administration would be to create a new group in the Groups OU named Sales_Groups_Admins. You would then add the appropriate users from the Users OU to the Sales_Groups_Admins group. The final step would be to delegate at the Groups OU administrative control to change group membership to the Sales_Groups_Admins group.

Although this process would accomplish the goal, it also provides too wide of privilege for the members in the Sales_Groups_Admins group. As the Sales_Groups_Admins group is located in the Groups OU, all of the members of the Sales_Groups_Admins group can add or remove members to this group too. Thus, they could add employees to the group that should not have the privilege to modify group membership for the other groups in the OU.

A solution to this potential vulnerability is to create an Administrative OU at each level where delegation is performed. For example, the OU structure would now look like:

Sales

You would still create the users in the Users OU, but you would not create the Sales_Groups_Admins group in the Groups OU. Instead, you would create this group in the Administrative OU. Then when you delegate administration for this group to control the group membership for groups in the Groups OU, it will not include the Sales_Groups_Admins group.

Another best practice when working with delegation is to perform regular audits on who has been given delegated administrative privilege to different levels in AD. There are two methods to audit this activity. If your company has the manpower and stamina to audit as the activity occurs, you will need to use the built-in auditing that is provided for the OS. If your company is running low on manpower and the IT staff already has too many things to do, it might be best to perform manual audits on the delegation in AD. This can be performed by first documenting where any delegation is configured. If documentation is available, tools such as dsacls.exe and acldiag.exe can acquire the delegation configurations at each level in AD. Then a quick comparison of the actual settings versus the documented settings can be performed.

Any delegation that performed at the domain level can typically be accomplished by using the built-in groups for domain administration. These groups include Domain Admins, DNSAdmins, DHCP Admins, RAS and IAS Servers.

Delegation control over sites and site replication is typically controlled at the forest level because site management is a forest-level function. You typically would not attempt to delegate specific site responsibilities because the service administrators responsible for site management would need to control all sites as a whole, not independently. Membership in the Enterprise Admins group would provide the typical site administration roles and responsibilities. If granular control over sites is needed, there are specific tasks that can be delegated.

Click for the next excerpt in this series: Directory tools, part 1.