13.7 Providing Security for Active Directory Objects

The concept of providing security for Active Directory objects can be viewed in two different ways. First, you can consider the idea that you need to secure the object itself, so that no one can access it. By default, this is taken care of in the operating system and was discussed in the earlier "Providing Security for the Domain" section. However, we need to discuss another approach: delegation of administrative control.

Delegation of administration control, or just delegation as it is usually referred to, is not as complex as the name implies. Delegation is nothing more than setting permissions on objects in Active Directory. The permissions are set on objects in Active Directory the exact same way that you set permissions on files and folders on an NTFS volume. There is a Delegation Wizard, which is useful for some tasks , but more complex permissions require manual attention. Examples of delegation include:

Giving the HR managers the ability to change group membership for the HR groups
Giving the branch office staff the ability to create their own global groups
Giving the helpdesk the ability to reset passwords for all user accounts, except for the IT staff

One thing to keep in mind as you secure objects in Active Directory is the OU design. The OU design must be considered before the delegation is performed. Otherwise, you might be giving too much control or affecting the wrong objects with the delegation.

Delegation is typically provided to give administration over user accounts, group accounts, and GPO linking. Very little can be delegated to control for a computer account, printer, or shared folder.

One of the more complex aspects of delegation is whether to use user accounts or group accounts to delegate control to. If you consider OUs to be like folders and user accounts (and the other objects) like files, it becomes easy.

Microsoft has developed extensive documentation on delegation of administration. To obtain this documentation, go to: http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en.

13.7.1 Example: Delegating Control for Helpdesk Admins

Mary is the domain administrator for Contoso. The Contoso Corporation has a main office and a branch office. The branch office has an IT staff that completely controls all aspects of the user, computer, and group objects for that office. The main office has more than 10,000 employees, so the administration of Active Directory is more time-consuming than for the branch office. To help the domain administrators offload tasks, the IT director is going to allow the helpdesk staff to reset passwords for main office employees who forget them. This will reduce the calls to the domain administrators who have taken care of this issue since migrating from Windows NT. The IT director does not want the helpdesk staff to be able to reset passwords for the IT staff or any employee at the branch office.

To accommodate the delegation and GPO deployment, the top-level OU structure has been determined and implemented, as shown in Figure 13-9.

Figure 13-9. Example of a top-level OU design to incorporate delegation and GPO deployment

There are some important design decisions to note regarding the OU design. First, notice how the IT staff and the employees for the main office are separated into different OUs. Also, the branch office is in a separate OU structure than the main office. This allows for the separation that is needed for the delegation of administration. However, note that all the user accounts are under a top-level OU, which allows for "global" delegation to be made at the top-level OU, without making a user a domain administrator or giving him too many privileges. Finally, notice that there is an Administrative OU at each level of OUs. This OU provides a holding area for all "administrative groups" that have delegated privileges over the OUs directly below it. This is to keep track of groups that are used to provide access to resources on the network versus the groups that are used to delegate administration to objects in the Active Directory.

The creation of the Administrative OUs is not necessary for a fully functional and successful delegation model. However, it has provided an excellent method for administrators to keep track of each type of group in a complex Active Directory implementation.

13.7.1.1 Delegating control

John, Paul, George, and Ringo are all on the helpdesk staff. Mary needs to give them delegated privileges that meet the requirements of the IT director. She would take the following steps to complete the delegation:

Open Active Directory Users and Computers.
Expand the domain structure down to the Administrative OU under the MainOffice OU.
Right-click on the Administrative OU, then click the New Group menu option.
Right-click the Reset_PW_Main_Emp group account, then click the Properties menu option.
Select the Member Of tab.
Click the Add button.
Make sure the domain name is listed in the From This Location text box. If it is not, click the Locations button, select the domain name from the Locations window, then click the OK button.
Type John in the "Enter the object name to select" text box, then click the OK button.
Repeat step 9 for Paul, George, and Ringo.
Right-click on the Employees OU under the MainOffice OU, then click the Delegate Control menu option.
Click Next .
Click the Add button.
Find the Reset_PW_Main_Emp group and add it to the list.
Click the OK button.
Click the Next button.
Select the "Reset user passwords and force password change at next logon" checkbox, then click the Next button.
Click the Finish button.

The power of delegation is tremendous, if executed properly and maintained well. Here, you can see that the members of the Reset_PW_Main_Emp group can now take care of all the password reset needs for the employees located in a single OU. This provides ultimate control for the domain administrators, while allowing junior-level administrators and other employees to help with routine tasks. The other benefit of the delegation as you can see from the example is that the scope of influence is limited by a good OU design and delegation model. A final note is that delegation was required here rather than just adding these user accounts to the Account Operators group, due to this action providing these users too broad administrative privileges.

13.7.2 Example: Auditing Management of AD

Derek is the enterprise administrator for Contoso. His company is responsible for more than 250 training facilities throughout the United States. The company has three Active Directory domains, one the empty root. Derek has two domain administrators, Ashelley and Alexandrea, who are responsible for the other two domains. The domain administrators have been reporting that changes have been made to Active Directory objects without their knowledge or written documentation. When a problem occurs from a change, no one is confessing to the change.

You know that auditing the Active Directory management can solve much of the confusion, as long as one of the domain administrators reviews the logs generated from the audit. You instruct each domain administrator to configure auditing for Active Directory to track when any object is managed within her respective domain.

13.7.2.1 Configuring auditing for DCs

Ashelley and Alexandrea need to configure auditing for their respective domains but wonder whether they can make a single setting in the root domain. After much research and failure, they realize that they can't configure a single setting in the root domain that configures auditing on their domains. They realize that there is no GPO setting that they can configure in the root domain that flows down to the child domains.

They then realize that they can just configure the same settings within their respective domain to configure auditing for Active Directory management. To configure their domain, they perform the following steps:

Edit the Default Domain Controller Policy using the Group Policy Editor. (This can be done in many ways: use the Group Policy tab from the Domain Controllers OU property sheet and select Edit, use the GPMC, or configure the Domain Controller Security Policy from any domain controller.)
Under Computer Configuration, expand the nodes down to the Windows Settings\Security Settings\Local Policies\Audit Policy .
Double-click Audit Account Management from the righthand pane.
Select the Define These Policy Settings checkbox.
Select the Success and Failure checkboxes.
Select the OK button.
Close the Group Policy Editor window.

Enabling success and failure is not required but will indicate when someone makes a change to an Active Directory account, as well as when someone attempts and fails to make a change. The GPO changes made here will be effective upon the next refresh of the GPOs to the domain controllers in the domain. If any sites need to be spanned with the replication, the convergence time to all domain controllers might be hours or days, depending on the replication schedule.

13.7.2.2 Viewing Security Log in Event Viewer

After all the domain controllers have received the new audit setting, they will immediately begin to log when accounts are managed within Active Directory. Each domain will log only the activity performed on the domain controllers and Active Directory from its domain. The logs will be logged on the domain controller where the management occurred. To simplify the management of the audit logs, Ashelley and Alexandrea could configure which domain controller the other administrators use when they update objects in Active Directory. If this is not done, the domain administrators would need to gather the logs from each domain controller manually. For more information on auditing and collecting audit logs, see Chapter 15.

A tool such as EventComb could also be used. EventComb allows an administrator to gather logged entries from the domain controllers and then place them into files that are centrally located. The EventComb tool is a free download available at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=9989D151-5C55-4BD3-A9D2-B95A15C73E92.

To review the audited events from auditing of Active Directory management, you need to go into the Event Viewer and find the Security Logs. These are the steps:

Click Start All Programs Administrative Tools Event Viewer.
Select the Security Log from the left pane.
Scroll down the right pane until you find an event that you want to review.
To view events related to account management, look for those that say Account Management in the Category column.
Double-click the event to open the Event properties sheet.
The Event describes the Date, Time, Source, User, Computer, and description of the event. The Description will include the object that was modified, as well as any particular information regarding the domain controller and supporting information related to management of the object.

If you have not reviewed many Event log files, you may be shocked with how much information is logged in such a short period of time. Be prepared to spend plenty of time going through the logs, to look for security problems or attacks. Be sure to use tools like EventComb to organize and gather all the events from computers around the network.

If you are having trouble trying to decrypt the description for a logged entry, be sure to use TechNet (either on the CD/DVD format or the online version at www.technet.com) and www.eventid.net to help you find better descriptions for the logged entries. The best search uses the ID number and a portion of the description that seems to be unique wording or phrasing .