In Windows Server 2008, organizations can use Active Directory Domain Services (AD DS) to manage users and resources, such as computers, printers, or applications, on a network. AD DS includes many new features that are not available in previous versions of Windows Server Active Directory. These new features make it possible for organizations to deploy AD DS more simply and securely and to administer it more efficiently. This topic provides an overview of the improvements in AD DS. For details about the improvements, see the following topics that describe the new features in Windows Server 2008 AD DS:
AD DS: Auditing.
AD DS: Fine-Grained Password Policies.
AD DS: Read-Only Domain Controllers.
AD DS: Restartable Active Directory Domain Services.
AD DS: Database Mounting Tool (Snapshot Viewer or Snapshot Browser).
AD DS: User Interface Improvements.
AD DS: Owner Rights.
AD DS: Auditing The global audit policy Audit directory service access controls whether auditing for directory service events is enabled or disabled. This security setting determines whether events are logged in the Security log when certain operations are carried out on objects in the directory. You can control what operations to audit by modifying the system access control list (SACL) on an object. In Windows Server 2008, this global audit policy is not enabled by default. Although the subcategory Directory Service Access is enabled for success events by default, the other subcategories are not enabled by default.
If you define this policy setting (by modifying the default Domain Controllers Policy), you can specify whether to audit successes, audit failures, or not audit at all. Success audits generate an audit entry when a user successfully accesses an AD DS object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an AD DS object that has a SACL specified.
You can set a SACL on an AD DS object on the Security tab in that object's properties dialog box. Audit directory service access is applied in the same manner as Audit object access; however, it applies only to AD DS objects and not to file system objects and registry objects.
AD DS: Fine-Grained Password Policies You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.
For example, you can apply stricter settings to privileged accounts and less strict settings to the accounts of other users. In other cases, you might want to apply a special password policy for accounts whose passwords are synchronized with other data sources.
AD DS: Read-Only Domain Controllers Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a way to deploy a domain controller more securely in locations that require fast and reliable authentication services but cannot ensure physical security for a writable domain controller.
However, your organization may also choose to deploy an RODC for special administrative requirements. For example, a line-of-business (LOB) application may run successfully only if it is installed on a domain controller. Or, the domain controller might be the only server in the branch office, and it may have to host server applications.
In such cases, the LOB application owner must often log on to the domain controller interactively or use Terminal Services to configure and manage the application. This situation creates a security risk that may be unacceptable on a writable domain controller.
An RODC provides a more secure mechanism for deploying a domain controller in this scenario. You can grant a nonadministrative domain user the right to log on to an RODC while minimizing the security risk to the Active Directory forest.
You might also deploy an RODC in other scenarios where local storage of all domain user passwords is a primary threat, for example, in an extranet or application-facing role.
AD DS: Restartable Active Directory Domain Services Restartable AD DS reduces the time that is required to perform certain operations. AD DS can be stopped so that updates can be applied to a domain controller. Also, administrators can stop AD DS to perform tasks, such as offline defragmentation of the Active Directory database, without restarting the domain controller. Other services that are running on the server and that do not depend on AD DS to function, such as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while AD DS is stopped.
AD DS: Database Mounting Tool Although the Active Directory database mounting tool does not recover deleted objects by itself, it helps streamline the process for recovering objects that have been accidentally deleted. Before the Windows Server® 2008 operating system, when objects or organizational units (OUs) were accidentally deleted, the only way to determine exactly which objects were deleted was to restore data from backups. This approach had two drawbacks:
Active Directory had to be restarted in Directory Services Restore Mode to perform an authoritative restore.
An administrator could not compare data in backups that were taken at different points in time (unless the backups were restored to various domain controllers, a process which is not feasible).
The purpose of the Active Directory database mounting tool is to expose AD DS data that is stored in snapshots or backups online. Administrators can then compare data in snapshots or backups that are taken at different points in time, which in turn helps them to make better decisions about which data to restore, without incurring service downtime.
AD DS: User Interface Improvements AD DS user interface (UI) improvements provide new installation options for domain controllers. Furthermore, the updated Active Directory Domain Services Installation Wizard streamlines and simplifies AD DS installation.
AD DS UI improvements also provide new management options for AD DS features such as read-only domain controllers (RODCs). Additional changes to the management tools improve the ability to find domain controllers throughout the enterprise. They also provide important controls for new features such as the Password Replication Policy for RODCs.
AD DS: Owner Rights Owner Rights is a well-known security principal that you can add to the DACL of an object to specify the permissions that are assigned to owners of objects in the directory service. This added security feature overrides the default behavior of owners of objects in the system. Because owners of objects (as specified in the security descriptor of the object) have WRITE_DAC permission, they can give rights to themselves and to other security principals as they see fit.
The Owner Rights security principal is specified using the well-known security identifier (SID) S-1-3-4. For example, if the Owner Rights security principal is located in the fabrikam.com domain, its distinguished name (also known as DN) can be expressed this way: CN=Owner Rights,CN=WellKnown Security Principals,CN=Configuration,DC=fabrikam,DC=com.
By default, Owner Rights are not defined on objects. This means that the pre–Windows Server 2008 behavior of owners having WRITE_DAC permissions to the objects that they own still applies.
When you add the Owner Rights security principal to objects, you can specify what permissions are given to the owner of an object. For example you can specify in the access control entry (ACE) of an object that the owner of a particular object is given Read permissions or you can specify NULL permissions to an object, which grants the owner of the object no permissions.