Delegation of administrative control might be the sole reason you moved from your old directory service to AD. Many want to move to AD to take advantage of the efficiency, security, scalability, and ROI that delegation provides. The ability to provide detailed task privileges to all areas of the IT staff, as well as to non-IT professionals, is why delegation is so useful.
There are many tasks that can be delegated within AD, but they can all be broken down into two categories: data administration and service administration. Data administrators control the resources that are stored in AD, such as user, group, and computer accounts. They also control member servers and the resources that reside on these computers. The administrative responsibilities that are associated with these tasks are broken down into categories to help organize the delegation that must occur to get all of the tasks done. Once the categories are created and the AD design finalized to include data administration, the delegation of these tasks can be completed. Delegation of data administration is provided within AD by giving data administrative groups permission over the objects that they will control.
Service administration and the delegation of the related tasks differ greatly from data administration. Service administration controls the directory service, ensuring it is configured properly, available, and stable. Service administration is typically delegated by adding user accounts to existing groups that already have privileges to control aspects of AD administration. These groups and additional groups are configured with user rights on domain controllers to give them additional delegated privileges. These delegated tasks are assigned from categories that organize the different AD administration tasks necessary to keep AD running.
You must begin delegating within AD early in the directory implementation. This best practice is one of many that you will be introduced to with regard to delegation of administration in AD. This chapter will also explore additional AD delegation best practices in areas such as logical and structured designs, the use of roles, and a clear understanding of your delegation model.
Once the delegation is implemented, the job is not done. You will still need to monitor and control the delegation for the production environment. This task typically can be broken down into three areas: logging, monitoring, and auditing. Each area is critical to ensuring that security within AD is maintained. Finally, we will take a look at tools that can help you complete your delegation within AD.
Data administration is not only the administration of data—it entails almost every delegation aspect outside of supporting the directory service itself. Data administration includes the following responsibilities:
The common thread among all of these responsibilities is controlling privilege access to a resource. In some cases, the resource is a file and in other cases the resource might be an entire server. Regardless, the structure of allowing, or delegating, these responsibilities must be designed, implemented, and maintained.
Data administrators are responsible for clients and servers, so there is the potential for them to control GPOs, which offer an ideal means of controlling all computers in the domain for security and configuration settings. As we have seen, GPOs provide control that is targeted and final. However, should a data administrator have control over GPOs that are targeted to clients and servers? This question can only be answered by the individual company and IT department. Take caution when considering this decision as you are giving data administrators a great deal of power when you give them control of a GPO.
GPOs can control security permissions on the target computer, group membership on the target computer, security settings, and much more. If a data administrator is delegated control to create, link, and edit GPOs, there is nothing that administrator can't do with or to the target computer. Also, if there are any user accounts in the OUs to which the data administrator has been delegated privilege, the administrator will also have control over these user accounts on the network. Ideally, you will not give any data administrator the ability to create or edit GPOs, instead delegating only the ability to link a GPO to an OU.
It is a common delegation to provide data administrators with the ability to create objects, such as user and group accounts. However, it is often overlooked that once this delegated privilege is given to a user, the user has full control over that object because the user owns the object (as with files and folders, the user that creates an AD object becomes the owner of the object). Thus, if you do want users to have full control access over the objects in AD, do not provide them with the ability to create the object. Alternatively, you can implement a process to change object ownership once an object has been created by a user.
As you think about the overall design of data management delegation, consider the myriad options that you have available. The following lengthy list highlights data management categories and the delegation responsibilities that might fall under each role:
It is ideal to delegate data administration at the OU level, which allows for the greatest control over who is able to delegate and which objects a user can control. As a guideline for the data administration delegation process, the following list suggests steps that will need to be performed for every delegation that occurs within AD related to data administration:
After you delegate administrative privileges to users in the environment, you will need to provide them with tools so that they can perform administrative tasks. The preferred tool for administering user and group accounts is the Microsoft Management Console (MMC) Active Directory Users and Computers console. This tool can be installed on client computers by installing the Adminpak, which is on the server installation media as well as under the system files on any domain controller.
Another option is to create Taskpads, which are individual tasks created from the original Active Directory Users and Computers console but have a narrow scope to control what the user has access to. These Taskpads are discussed in more detail in Chapter 2.
Service administrators configure and manage AD and domain controllers, ensuring the directory service is functional and available. They have privileges that can cross domain boundaries, with the forest acting as the security boundary. Service administrators can act as data administrators, but data administrators cannot perform directory service administrative tasks. The overall mission of the service administrator is to make sure AD is running smoothly and efficiently.
With the scope of the service administrator controlling such important aspects of the company and network, there should be very few service administrators for any given task. Some companies have a team of 5 to 10 IT professionals that control service administration tasks, which allows for separation of duties as well as coverage in case an employee leaves or is promoted out of the role.
Service management delegation is slightly more complex than data management delegation. Service administration tasks have greater ramifications if performed incorrectly and the AD configurations can be more difficult. The following lengthy list highlights service management categories and the delegation responsibilities that might fall under each role.
Service administration is delegated by adding user accounts to administration groups. These groups have default privileges, but they can also be given additional privileges through user rights. The following list provides suggested service administration group models and their privileges:
Like data administration delegation, service administration delegation needs to be considered early in the AD design process. Although some of the delegation can be achieved by group membership, service administration still requires some OUs for controlling group membership and other delegation tasks. The following is a suggested process for how to delegate your service administration:
6. Add the appropriate user accounts to the security groups for each role.
At this point in the process, you need to provide the appropriate tools to the service administrators.
What is a best practice? In this context, we are going to define a best practice as a suggestion or recommendation from a valued, experienced source. A best practice is something that can be quantified, based on experience and analysis. The best practices here are from years of experience with AD, security, and delegation. Any good delegation strategy or best practice must be based on structured and logical thought processes, including a methodology of separating and organizing the different tasks into categories that are easily tracked and understood. Both of these factors will be molded into a model, which can then be implemented. The implementation stage is just as important as the design phase because mistakes here result in security issues down the road. In the following sections, we cover all of these areas of best practice delegation.
When you develop the model for your delegation, it must be structured and logical so that it can be implemented and managed with ease. Best practices that you should follow as you develop your delegation model include:
As you design the delegation model, consider using roles as the core structure for the administration task. Roles categorize the different tasks so that you can either provide full access to each task in a role or partial access to a few of the tasks. We have already broken down the data and service administration delegation options into roles. You can either use these roles or develop your own roles as a basis for your delegation model.
As a best practice for delegation, you need to develop a delegation model. This model will be the underlying structure for your AD design and how the objects in AD are organized. You will need to consider all of the different aspects of how your company is organized, especially with regard to the IT administration staff. You will need to work this consideration into the delegation model. In the end, the delegation model will provide the foundation for the overall AD structure and specific delegation for data and service administration. A good delegation model will
As you deploy and implement the delegation, there are some best practice considerations that you should keep in mind. Some of these can cause more initial work, but the time that they save in the long run is well worth the initial effort. When you implement delegation, make sure you consider the following:
It is foolish to design, implement, and manage delegation without some way of ensuring that the desired delegation is the actual resulting delegation. To do so, you can have different levels of checking on the delegation of AD administration. First, you can establish a log that tracks changes to delegation as well as the use of delegation privileges. Next, you can monitor, either manually or automatically, the activity that occurs as a result of delegation of tasks. Finally, an audit needs to be done to ensure that the documented delegation is the current delegation.
The following sections explore each of these areas to ensure that delegation at all steps in the process is covered and correct. If you are not satisfied with the built-in capabilities of the Windows OS with regard to these tasks, investigate tools from ScriptLogic, Aelita, NetPro, and BindView. These tools provide more robust and efficient solutions.
You can produce logs of delegation activity with the built-in logging feature of Windows. With this feature, you can track almost every activity that occurs to an object, service, or setting within the OS. Ideally, you will set up logging on the domain controllers to track when data administrators manage the objects contained in AD. If there are any servers that contain resources, you will also need to enable logging on those servers. For service administrators, you will primarily establish the logging only for the domain controllers, because these computers are the only servers that control AD.
The logging settings that need to be enabled to track delegation and the use of delegated privileges include:
To ensure consistent and persistent configuration of the logging settings, it is best to use GPOs to deploy these settings. For domain controllers, use a GPO linked to the Domain Controllers OU. For all other computers, create a new GPO, link it to the appropriate OU containing the computer accounts, then configure the audit policy settings in the GPO.
The logs generated from these settings are tracked in the Security Log of the Event Viewer. The security logs are kept in the log until they are archived or overwritten by newer events. Each OS configures the size of the security log differently, but it is a good idea to increase the size of this log to more than 10MB for domain controllers to ensure that all of the information is captured between archiving of the log. If there is a lot of traffic on the domain controller or there are numerous resources being tracked, it might be a good idea to increase the security log size to 50MB or more to ensure that no events are lost.
Once you have the logging and tracking established, you need to be made aware of when a critical event occurs. Even if the event is not logged, you still want to be made aware of the event occurring. Unfortunately, Microsoft does not have any such tool built-in to the Windows OS and really don't have many options that provide such monitoring. The Microsoft Operations Management (MOM) product provides some good monitoring over the OS; however, you might want to look at other tools that can provide you with more advanced monitoring capabilities over AD and the delegation that you have established over tasks.
When you evaluate your need for monitoring, you will need to consider the following features that some tools, none built-in, provide:
Once the logs have been established and there is a monitoring tool in place, auditing needs to be performed to make sure that nothing is missed. Also, auditing provides a process in which the events that are logged can be reviewed to find trends of security attacks or vulnerabilities. The first step to auditing is to create an audit trail. We have already discussed this step in the logging section earlier.
Employing a centralized tool is very beneficial when it comes to auditing. It can take days to track down the events from all of the domain controllers and servers in the organization. Tools such as EventCombMT from Microsoft can help, but this tool does not provide the efficient interface and query mechanisms that are really needed to ensure that a good audit can be performed on the event logs. Be sure to investigate tools from ScriptLogic, Aelita, NetPro, and BindView to help solve these issues.
Make sure that you also include the delegation audit. This audit includes the reporting of the delegation of administration on OUs and the membership in groups that you need to know in order to provide a good audit on delegation in AD. For these additional control checks, you will need to obtain a tool that allows you to efficiently list and organize ACLs of AD objects. You will then need to quickly access the membership of groups, especially those that were created specifically for delegation. Finally, you will need to audit the service administration default groups, which provide control over AD-related functions.
There are plenty of tools that can be used to help develop and report on the delegation of administration for AD and the objects in AD. It cannot be stressed enough how important it is to have the design of the delegation well thought out and implemented first. A poor delegation model is very difficult to administer regardless of the delegation tool.
Although there are plenty of tools that are available to help implement your delegation model in AD, we will explore the Delegation of Control Wizard, which is a free, built-in tool that is part of the Active Directory Users and Computers console. This tool offers many of the standard delegation tasks already configured for you to just click for an easy implementation. However, with many configurations required for a large organization and the need to report on the delegation that is in place, other tools are also needed to ensure successful delegation. The different tools that can be used to delegate administration in AD include:
We will discuss each tool and talk about their benefits and weaknesses. I must also stress that this is not an exhaustive list of tools that can be used for delegation of administration in AD. The tools not listed might provide a better solution because they offer GUI-based solutions, which can help with the overall implementation and reporting of the delegation in such a complex environment.
The Delegation of Control Wizard is built-in to the Active Directory Users and Computers console, where most of the administration of AD objects takes place. The wizard is designed to walk you through the decisions to configure the permissions on the objects in AD. Of course, the wizard is also designed to help configure the large number of permissions on objects in AD. The wizard will begin by asking questions about
When the wizard is finished asking questions, it configures the ACL on the object in which the wizard was initiated as well as down through the AD structure following the rules of inheritance that are configured for the objects being affected.
Although I have only mentioned that the Delegation of Control Wizard is available in the Active Directory Users and Computers console, it is also available to configure delegation to objects located in the AD Sites and Services console. In each AD tool, the Delegation of Control Wizard provides a default list of administrative tasks that configure the permissions on the objects automatically. These default administrative tasks differ slightly between Win2K Server and WS2K3 domain controllers, due to the updated list that the WS2K3 domain controllers provide. The following list summarizes the WS2K3 domain controller offerings of default administrative tasks in each AD tool:
To use the Delegation of Control Wizard to delegate the resetting of passwords on an OU, you would follow these steps:
This process will configure the needed permissions on the user accounts in the OU so that the configured users can reset the password and check the box to force the password to be changed when the user logs on again.
If an administrative task is not listed, yet you want to delegate that task to a user or group, you can create a custom task in the wizard. This task can be very daunting because there are literally hundreds of detailed permissions that can be set on any one object in AD. Rather than create a custom task, you can modify the underlying file that configures the default list of administrative tasks. This file, Delegwiz.inf, can be customized to include any set of permissions to make up an administrative task.
As you can see, the Delegation of Control Wizard is easy to use and extremely efficient. However, there is one flaw with the tool. The tool can only "add" delegation permissions, it can't remove permissions. We will look at other tools—such as ScriptLogic's Active Administrator (AA)—that can report on and remove the delegated permissions if you have configured too much to a user or group.
The ACL Editor is the rawest tool for establishing the delegation on an object in AD. The editor allows you to view, modify, and add the security configurations of objects in AD, just like you can for files and folders. The Delegation of Control Wizard is a GUI-based tool that performs this same task.
A benefit of the ACL Editor is the additional detailed configurations that can be made to the security description of the object. The permission that controls access to an object is just one of many settings associated with the overall security of an object. You can also configure the following security-related settings by using the ACL Editor:
Figure 4.1: SACL settings configure auditing for objects in AD.
The ACL Editor can be accessed from either the default administrative tools (Active Directory Users and Computers and AD Sites and Services) or from ADSI Edit, which is a GUI-based tool that allows you to see the objects located in AD.
ADSI Edit is a free tool that comes on the Windows installation CD-ROM. You can find the tool, adsiedit.msc, under the Support Tools directory. Ideally, you will install the entire suite of support tools, which will make the ADSI Edit tool available from the Start menu.
If you are using Active Directory Users and Computers to access the ACL Editor, you might find that it is not available by default. If such is the case, to access the ACL Editor, you will first need to enable the Security tab on the objects that exist in AD. To enable the ACL Editor, click View on the toolbar in the Active Directory Users and Computers console, then select the Advanced Features menu option. The Security tab (which shows the ACL Editor) will be accessible for the objects in AD. To access the ACL Editor, follow these steps, right-click an object in the Active Directory Users and Computers console, select the Properties menu option, then select the Security tab on the Properties sheet for the object you are viewing.
The majority of administrative tasks that you will need to delegate won't show up on the initial Security tab, because the standard permission shown on this tab are more geared toward typical access of the object—not delegation of administration to the object. To access the permissions that relate to the administrative tasks associated with delegation, follow these steps once you are on the Security tab of the object.
You will find that the options for configuring delegated administration are almost overwhelming using this method. The following list provides guidelines that will help you configure the delegation more efficiently using the ACL Editor:
The Ldp.exe tool allows you to access the raw data and objects located in AD. The tool uses the Lightweight Directory Access Protocol (LDAP) operations to view, manage, and create objects in AD. Like the ADSI Edit tool, this tool is part of the Support Tools located on the installation media.
The tool requires you to connect to a domain controller, then bind to the AD database, and finally view the contents of the database. After you have used the tool one time, you will see that it is rather simple. However, first use of the tool can be a bit confusing.
Dsacls.exe can take much of the manual labor out of reporting the existing delegation on any object in AD. The other tools that have been reviewed can update and view the existing permissions on any object in AD, but using them to get a complete list of all permissions that are configured on the objects can be very time consuming. Dsacls.exe is a command-line tool that reports and modifies permissions more efficiently than any of the other tools mentioned. This tool is also available from the Support Tools on the installation media.
Acldiag.exe is another command-line utility that reports on the permissions of AD objects, helping track the delegation that has been configured on the objects. Acldiag.exe will also delineate between inherited and explicit permissions, helping track where delegation might have been configured on individual objects, instead of at higher levels such as OUs or the domain. Acldiag.exe is part of the Support Tools suite, like the other tools mentioned.
Dsrevoke.exe is a new tool for Win2K and WS2K3 domain controllers and is designed to work in conjunction with the Delegation of Control Wizard. As we have already discussed, the wizard is not capable of removing any permissions, only adding them to an object. The Dsrevoke.exe tool is a free tool from Microsoft that was designed to remove delegated administrative authority.
With the complexity of AD administration, you will need to provide other administrators and non-IT professionals with the ability to help manage all of the tasks required to keep AD running. Some tasks are for controlling the core objects in AD and other tasks ensure that the directory is secure, stable, and available. In addition to following the suggested best practices, it is important to remember that delegation needs to be maintained and audited to ensure a secure AD environment.
This guide has walked you through the implementation of security for the information contained in and the resources protected by AD. Although this task is complex, by following the suggested best practices, you can attain and maintain a secure AD environment.