This tutorial describes the security to be used to ensure that Active Directory Configuration and processes, procedures and controls are aligned with Industry best practice and provide a compliant Active Directory.
This tutorial does not discuss specific design details or act as a guideline through the steps necessary to accomplish the tasks described. It provides reference material that could be used as a guide to implementing the standard.
It is intended for Auditors  and to help them liaise between IT, operations, compliance and senior business representatives. Understand business requirements, build risk assessment models and lead the process to implement change and mitigation.

Active Directory presents organizations with a directory service designed for distributed computing environments. Active Directory allows organizations to centrally manage and share information on network resources and users while acting as the central authority for network security.

The following section lays out the fundamentals for auditing the AD environment

Data Access

There are several reasons to control access to data stored in Active Directory, these include legal requirements due to the presence of personal data and business requirements to limit access to confidential or restricted data.

Note that access to data stored on Windows 2000 Servers, whether directly in the NTFS file system or stored within Databases such as Oracle or SQL will also normally be controlled by objects (Users and Groups) in Active Directory.

Object Management

The control of objects (Users, Groups, Computers etc.) is subject to strict operational controls to ensure that only the rightful owners are able to determine access rights.

It is a critical part of the design process of any Active Directory environment to consider the structure desired for the objects within Active Directory. Without this template to work with it will be almost impossible to create a structure that can be controlled in the required manner. The final design may also be dictated by the use of a Third Party management tool that may allow for a simpler OU design while still retaining the ability to delegate administrative authority to groups of objects contained in the same OU.

Service Management

Management of areas like DNS, Group Policy, Replication topology etc should go through a thorough review and controls should be put in that ensure that only a core set of Administrators have access to these areas.
There is always an element of trust needed when trying to design a delegation model, consider the following facts about Active Directory administrative roles:

Forest owners maintain the right to control domain-level services and to access data that is stored on any domain in the forest.
Domain owners maintain the right to access data that is stored on the domain or on its member computers.
Domain owners, although operating autonomously from forest owners and other domain owners, cannot prevent another malicious domain owner from controlling their services and accessing their data.

This high degree of collaboration and trust that is required among the authorities that are responsible for the management of domains in a forest necessitates that all administrators who manage domains be highly trusted. Therefore, Active Directory domains in a forest should never be deployed with the objective of isolating business units that do not trust each other.

Windows  requires verification of every user's identity before it allows access to network resources. The process of verifying the identity of users, also known as authentication, is part of the logon process. The process of granting or denying access to a resource is called authorization. During authentication, all entities identify themselves to the security system by means of a unique user ID. Active Directory stores security-related identity information for users, as well as their credentials (such as passwords), in the form of a user account object. The system generates a unique security identifier (SID) for every account object that can be authenticated or authorized for access to resources. Every SID contains the identifier of the domain in which the object resides.
Objects with a SID are also known as security principals. The following types of objects act as security principals:

• User: a person or a service that requires user credentials
• Computer: a workstation or server running Windows
• Group: a set of users, computers, or other group

Active Directory security policies and procedures can be divided into the following layers:

Physical security for domain controllers and the network (physical access to domain controllers, backup data, and network components)
Administrative authority (security management and secure administrative practices)
End system (domain controller settings, policy settings, and deployment practices)

This approach makes it easier to isolate and therefore verify the integrity of the different layers of security that protect access to and the objects in Active Directory.

AD Security and Administrative Boundaries
The Active Directory forest represents the outermost boundary within which users, computers, groups, and other objects exist. Active Directory domains are always part of a forest. They are the boundaries for administration and security policies. This means that policies, such as password complexity and password reuse rules, cannot be inherited from one domain to another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and groups that reside in that domain.

As Active Directory is implemented after the Windows 2000 Operating System, a secure Windows 2000 implementation is required before installing/implementing Active Directory.

The delegation of Active Directory administration should be restricted to authorized personnel only

All Domain Controllers that are deployed in an extranet should be in a separate forest

AD Security baselines should be applied to all Domains before adding External Trusts between them

SID filtering should be enabled when an external trust is created between domains in separate forests

Membership of the 'Schema Admins' group should be granted on a Temporary basis only

Anonymous access should be disabled

Recommendations for Secure Domain Controller Deployment

Access to Ntds.dit, AD logs and Sysvol should be limited to authorized personnel only

Pre - Windows 2000 group 'Pre-Windows 2000 Compatible Access' should not be populated.

W2K forests and domains should be run in Native mode only

Script signing on domain controllers should be implemented

Establish Secure Domain and Domain Controller Policy Settings

The password settings should be enabled in accordance with an approved password standard

Account lockout policy settings should be applied at the domain level

The standard Kerberos policy settings should be applied

The standard Domain controller User Rights Assignment policy settings should be applied

Auditing should be implemented according to the standard auditing policy as defined

A process and/or tool should exist and be used for reviewing logs for auditing and troubleshooting purposes

Audit Policy settings should be applied on Domain Controllers

Auditing on the Schema directory partition should be enabled in accordance with an approved policy

Auditing on the Configuration directory partition should be enabled in accordance with an approved policy

Auditing on the Domain directory partition should be enabled in accordance with an approved policy

The Domain Controller Security Options policy settings should be applied in accordance with an approved policy

The domain controller event log policy settings should be applied in accordance with an approved policy

Selecting Policy Settings for Mixed Operating System Environments

Anonymous access to Domain Controllers should be restricted

SMB signing should be used between trusting forests for securing communications.

Restricting Anonymous Access to Domain Controllers and Domain Controller Resources

The Security Option policy 'Additional restrictions for anonymous connections' should be set to 'Do not allow enumeration of SAM accounts and shares'.

Enabling SMB Signing on Domain Controllers

SMB Client and Server signing should be enabled to ensure that SMB signing is used

Applying Selected Domain and Domain Controller Security Settings

New 'Group Policy' settings related to security should be set with the highest precedence

Recommendations for Deploying Secure DNS

Only authorized personnel should be granted DNS administrator privileges

A Change and Approval management process should be used to approve configuration changes to DNS

Only the default groups (Enterprise Admins, Domain Admins, Administrators, DNS Admins, and SYSTEM) and AD Admin user groups should be allowed to apply ACL's on DNS data

Active Directory integrated DNS zones should be implemented

The DNS cache on domain controllers should be protected by enabling the 'Secure cache against pollution' setting in DNS

Forwarders should be used instead of secondary zones

Separate internal and external namespaces should be used

NTFS file permissions should be set on zone files for Non-ADIZ DNS

Secure Administrative practices

The Number of Service Administrator Accounts should be restricted

Separate Administrative and User Accounts for each Administrative Users should be implemented

The Domain Administrator Account should be Hidden (Renamed)

Administrative accounts should reside in a separate OU

Accounts from outside the forest should not be made members of Service Administrator groups

Administrative Privileges (granted via Groups) to AD should be documented

A Process should exist to prevent abuse, defined, in accordance with the documented AD Administrative Privileges

The Account Operators group should not be used

The Membership of the Service Administrator Group should be hidden

Delegation of Forest-Level Operations should be restricted to authorized and approved personnel only

Delegation of Domain-Level Operations should be restricted to authorized and approved personnel only

Data administrators manage data that is stored in the directory but that is not related to directory service configuration or the operation of Active Directory itself. Data administrators manage local resources, such as print and file shares on local servers, and they also manage the group and user accounts for their own part of the organization.
In simple terms, delegation of data administration is accomplished by creating groups, granting the appropriate user rights to those groups, and applying Group Policy settings to the members of those groups. After these steps are complete, delegation is a matter of adding user accounts to the groups that are created. The critical part of this operation is granting proper access and applying the proper policies to maximize security, while still allowing the administrators to perform their delegated functions.

Taking a more realistic approach things are not as simple as delegating control over the entire set of objects in an OU, there may be additional rules, processes and procedures to follow when creating new objects and also modifying objects. It may also not be desirable to delegate control over the entire object but rather only certain attributes on the object.

Careful thought needs to be put into the design of Active Directory when considering all these elements. It may be that a simple structure of OU's may be better when considering the application of Group Policies but a more complex structure would be needed to be able to delegate the management of separate groups of objects to different data administrators.

It may also be worth considering the use of Third Party applications that can perform a variety of controlling tasks such as process and procedure control, limiting updates to defined attributes on an object (more simply that Active Directory can implement this), enforcing naming standards etc. Naming Conventions should be established for User (specific attributes) Groups and other objects in Active Directory.

Checklist

Naming Conventions should be established for User (specific attributes) Groups and other objects in Active Directory.

Every object should have a defined Administrative owner

Every object should have a defined owner

All extended schema classes/attributes should have a defined business owner

The 'Administrators' or  Domain Admins groups in each domain should own the domain root object for that domain partition

Domain Local Groups should not be used for controlling Read Access to Global Catalog Data

Concurrent Group Membership Changes should be avoided

All Infrastructure and Configuration changes to the AD environment should be approved via an approval process/body

Change Control procedures should be in place to ensure changes are communicated to all relevant parties who may be affected by any changes to the Active Directory environment

Testing procedures should exist to validate AD infrastructure and configuration changes in a development forest before being applied to any AD production forests

Secure Active Directory Operations

All AD Domain Controllers should be backed up on a periodic basis

The Backup Operators group should be protected

The application of all AD Hot-fixes and Service Packs should be approved via a change and approval process/body

A Forest recovery test should be performed on a yearly process

Baseline information about Domain controllers should be documented

Managing Forest-wide Configuration Settings

The MaxQueryDuration value should be set to 180 seconds with the NTDSUTIL tool.

Managing Service Administrator Account Security

Administrator Group memberships should be reviewed at regular intervals via an approved process/body

Delegation of Administrator rights should be reviewed at regular intervals via an approved process/body

A list of DS Restore mode passwords should be maintained in a secure location

The number of administrators that have access to DS Restore mode passwords should be restricted

Users with Administrator level access to AD should be familiar with all security policies

Monitoring Changes to Active Directory

Changes to the Active Directory infrastructure are identified by either a security log event, such as an addition to a service account group membership, or by an information change in the report generated for an infrastructure component.

Changes in the Active Directory schema should be logged for auditing and troubleshooting purposes

The addition or removal of Domain Controllers should be logged for auditing purposes

Changes in replication topology should be logged for auditing and troubleshooting purposes

Changes in LDAP policies should be logged for auditing and troubleshooting purposes

Changes in dSHeuristics should be logged for auditing and troubleshooting purposes

Changes in forest-wide operations master roles should be logged for auditing and troubleshooting purposes

Changes in domain-wide operations master roles should be logged for auditing and troubleshooting purposes

Changes in trusts should be logged for auditing and troubleshooting purposes

Changes in AdminSDHolder should be logged for auditing and troubleshooting purposes

Changes in GPOs for the Domain container and the Domain Controllers OU should be logged for auditing and troubleshooting purposes

Changes in GPO assignments for the Domain container and the Domain Controllers OU should be logged for auditing and troubleshooting purposes

Changes in the membership of the built-in groups should be logged for auditing and troubleshooting purposes

Changes in the membership of the all non built-in administrative groups should be logged for auditing and troubleshooting purposes

Changes in the audit policy settings for the domain should be logged for auditing and troubleshooting purposes

Changes in Administrator accounts should be logged for auditing and troubleshooting purposes

Monitoring for Disk Space Consumed by Active Directory Objects

Monitoring should be in place to check for AD database size and growth-rate for auditing and troubleshooting purposes

Monitoring Domain Controller Status

Domain Controllers should be monitored to ensure they are available to service client requests

Domain Controllers should be monitored for replication success against defined replication intervals

Domain Controllers restarts should be monitored and logged for auditing and troubleshooting purposes

Monitoring Changes in Domain Controller Performance Counters

Domain controller system resources should be monitored for auditing and troubleshooting purposes

LDAP responsiveness should be monitored for auditing and troubleshooting purposes

Monitoring Changes in System State and Executables

Changes in the current system state and executables should be monitored by comparing them to the baseline reference

Enterprise Admins (EA) Forest

This group is automatically added to the Administrators group in every domain in the forest, providing complete access to the configuration of all domain controllers. This group can modify the membership of all administrative groups. Its own membership can be modified only by the default service administrator groups in the root domain. This account is considered a service administrator.

Schema Admins (SA) Forest

This group has full administrative access to the schema. The membership of this group can be modified by any of the service administrator groups in the root domain. This account is considered a service administrator because its members can modify the schema, which governs the structure and content of the entire directory.

Administrators (BA) Domain

This built-in group controls access to all the domain controllers in its domain, and it can change the membership of all administrative groups. Its own membership can be modified by the default service administrator groups BA and DA in the domain, as well as the EA group. This group has the special privilege to take ownership of any object in the directory or any resource on a domain controller. This account is considered a service administrator because its members have full access to the domain controllers in the domain.

Domain Admins (DA) Domain

This group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Its own membership can be modified by the service administrator groups BA and DA in its domain, as well as the EA group. This is a service administrator account because its members have full access to a domain’s domain controllers.

Server Operators (SO) Domain

By default, this built-in group has no members, and it has access to server configuration options on domain controllers. Its membership is controlled by the service administrator groups BA and DA in the domain, as well as the EA group. It cannot change any administrative group memberships. This is a service administrator account because its members have physical access to domain controllers and they can perform maintenance tasks (such as backup and restore), and they have the ability to change binaries that are installed on the domain controllers.

Account Operators (AO) Domain

By default, this built-in group has no members, and it can create and manage users and groups in the domain, including its own membership and that of the SO group. This group is a service administrator because it can modify the SO group, which in turn can modify domain controller settings. As a best practice, you should leave the membership of this group empty and not use it at all for any delegated administration.

Backup Operators (BO) Domain

By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Its membership can be modified by the default service administrator groups BA and DA in the domain, as well as the EA group. It cannot modify the membership of any administrative groups. While members of this group cannot change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system binaries) on the domain controllers. Because of this, they are considered service administrators.

Administrator DS Restore Mode

This special account is created during the Active Directory installation process, and it is not the same as the Administrator account in the Active Directory database. This account is only used to start the domain controller in Active Directory Restore mode. When it is in restore mode, this account has full access to the directory database, as well as files (including operating system binaries) on the domain controller. Because of this, this account is considered a service administrator.