The Future Of WindowsDirectory Services in Windows Server "Longhorn"
Byron Hynes
This column is based on a prerelease version of Windows Server, code-named "Longhorn." All information herein is subject to change.
A number of improvements in Active Directory will come your way with the next version of Windows Server, code-named "Longhorn." Some of the changes are significant and open up exciting new avenues toward better manageability and efficiency. One of the most obvious changes in Active Directory is the naming of features and functions. Everything that relates to identity management is now grouped under the Active Directory® banner. What you and I have thought of as Active Directory in Microsoft® Windows Server® 2003 is now Active Directory Domain Services (ADDS), and there are a number of other additional services, including Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, formerly Active Directory/Application Mode, or ADAM), Active Directory Certificate Services (ADCS), and Active Directory Rights Management Services (ADRMS).
Each of these services represents a server role—a new concept in Windows Server "Longhorn." You can choose to have a computer dedicated to one server role or to several, and you can administer server roles using Server Manager, shown in Figure 1. From there you can add roles, find help, and perform other necessary administrative tasks.
Figure 1** Server Manager **(Click the image for a larger view)
As you can see, the new approach organizes day-to-day functions and features into logical groups that are accessible in Server Manager.
Functional Levels
Windows Server "Longhorn" introduces a new functional level for forests and domains. The Windows Server "Longhorn" forest functional level (which will be renamed on release) doesn't add any new functionality on its own, but it ensures that all domains in the forest are at the Windows Server "Longhorn" domain functional level, which enables two new enhancements. The first is the use of the newest distributed file system (DFS) replication engine for the SYSVOL share, which is more robust, granular, and efficient. The second is added support for 256-bit Advanced Encryption Services (AES) encryption for the Kerberos authentication protocol. Using the latest functional level will give the best performance, but you can continue to operate at lower functional levels as you migrate to Windows Server "Longhorn."
A number of schema extensions to support various features have also been introduced, all of which are fully compatible with the existing schemas in use today. Domain controllers running Windows Server "Longhorn" can happily co-exist and interoperate with those running Windows Server 2003.
Support for Server Core
Active Directory Domain Services is one of the server roles that will work in a Server Core installation of Windows Server "Longhorn." Server Core, which is not covered in detail in this article, is a minimal installation option where only core server functionality is retained. Server Core does not install the Windows shell and does not use a graphical user interface, saving quite a bit of overhead.
Read-Only Domain Controller
For some environments, the most significant feature for ADDS in Windows Server "Longhorn" is a Read-Only Domain Controller (RODC), which allows you to easily deploy a domain controller that hosts a read-only replica of the domain database. This is well suited for locations where physical security of the domain controller can't be guaranteed or where other applications must run on the domain controller and be maintained by a server administrator (who, ideally, is not a member of the Domain Admins Group). Both of these scenarios are common in branch office deployments.
A read-only domain controller is installed by simply enabling one checkbox in the Installation Wizard, as shown in Figure 2.
Figure 2** Installing the Read-Only Domain Controller **(Click the image for a larger view)
Before the release of Windows Server "Longhorn," if users had to authenticate with a domain controller in a different location, the traffic would have to cross a wide-area network (WAN) link. WAN links are often slower and more expensive than local area network (LAN) connections, and sometimes are more susceptible to service disruption. One possible solution was to deploy a DC into the remote site or branch office. However, this introduced other problems, including replication traffic, and the need to maintain physical security over the DC in the branch office—something that is all too often lacking in small and remote branch sites. In other cases, branch offices have poor network bandwidth connected to a hub site, increasing the amount of time required to log on.
With the exception of account passwords (unless specifically configured otherwise), an RODC holds all the Active Directory Domain Services objects and attributes that a writable domain controller holds. However, locally originating changes cannot be made to the replica stored on the RODC. Instead, changes are made on a writable domain controller and replicated back to the RODC. This prevents changes made at branch locations from potentially polluting or corrupting the forest via replication, thus eliminating one avenue of attack.
Local applications that request read access to the domain directory information can obtain access directly from the RODC, while Lightweight Directory Access Protocol (LDAP) applications that request write access receive an LDAP referral response. This referral response directs them to a writable domain controller, normally in a hub site.
Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This reduces the workload of bridgehead servers in the hub and the effort required to monitor replication. RODC unidirectional replication applies to both ADDS and Distributed File System (DFS) Replication. The RODC performs normal inbound replication for ADDS and DFS Replication changes.
In the domain database, each security principal has a set of approximately 10 passwords or secrets, called credentials. An RODC does not store user or computer credentials, except for its own computer account and a special "krbtgt" account (the account that is used for Kerberos authentication) for each RODC. The RODC is advertised as the Key Distribution Center (KDC) for its site (usually the branch office). When the RODC signs or encrypts a ticket-granting ticket (TGT) request, it uses a different krbtgt account and password than the KDC on a writable domain controller.
The first time an account attempts to authenticate to an RODC, the RODC sends the request to a writable domain controller at the hub site. If the authentication is successful, the RODC also requests a copy of the appropriate credentials. The writable domain controller recognizes that the request is coming from an RODC and consults the Password Replication Policy that's in effect for that RODC.
The Password Replication Policy determines if the credentials are allowed to be replicated and stored on the RODC. If so, a writable domain controller sends the credentials to the RODC, and the RODC caches them, as shown in the sidebar "How a Read-Only Domain Controller Works."
After the credentials are cached on the RODC, the next time that user attempts to log on, the request can be directly serviced by the RODC until the credentials change. When a TGT is signed with the RODC's own krbtgt account, krbtgt, the RODC recognizes that it has a cached copy of the credentials. If another DC has signed the TGT, the RODC will forward requests to a writable domain controller.
By limiting credential caching only to users who have authenticated to the RODC, the potential exposure of credentials by a compromise of the RODC is also limited.
By default, no user passwords will be cached on an RODC, but that's not necessarily the most efficient scenario. Normally, only a few domain users need to have credentials cached on any given RODC, compared with the total number of users in a domain. You can use the Password Replication Policy to specify which groups of users can even be considered for caching. For example, by limiting RODC caching to only users who are frequently at that branch office, or by preventing the caching of high-value credentials, such as administrators, you can reduce the potential exposure.
Thus, in the event that the RODC is stolen or otherwise compromised, only those credentials that have been cached need to be reset, and, as I'll discuss, you'll know exactly which accounts those are, as Figure 3 shows.
Figure 3** Cached Account Info **(Click the image for a larger view)
Administrator Role Separation
In many branch offices, a domain controller is given additional server roles or tasks to perform, such as acting as a file or print server. In other cases, a line-of business application is installed on a domain controller out of necessity. This creates a problem: in order to administer those applications and servers, an employee at the branch office needs to have administrative credentials. And anyone who can administer one Windows Server 2003 domain controller can administer the entire domain.
In Windows Server "Longhorn," an administrator can be given permission to manage only a particular RODC, without having the access that would let him manage other domain controllers and without having to be made a member of the Domain Admins security group unnecessarily.
User Interface and Tool Improvements
To support the functions of an RODC and to make it easy to monitor password replication, a new Password Replication Policy tab appears on the properties page of a domain controller in Active Directory Users and Computers, as shown in Figure 4.
Figure 4** The Password Replication Policy Tab **(Click the image for a larger view)
By clicking the Advanced button on this tab, you can see which passwords have been sent to the RODC, which ones are stored there, and which accounts have authenticated against that RODC, as shown in Figure 5. Since the list includes accounts that have authenticated, even if they are outside the groups that are allowed to have their passwords replicated, you can use that information to decide which groups should be included in the Password Replication Policy.
Figure 5** Advanced Password Replication Policy **(Click the image for a larger view)
A number of changes have been made to the venerable dcpromo utility, more formally known as the Active Directory Domain Services Installation Wizard. This wizard can be launched as a full graphical application by choosing the Add Roles command in the Initial Configuration Tasks (ICT) page that runs immediately after the installation of the operating system. Choose Add Roles and then ADDS in Server Manager or invoke dcpromo from a command line or the Run box.
As soon as you use the wizard in graphical mode, you'll notice better organization of elements and choices, as related items are grouped together. There are also more options. You can access the advanced mode from the UI without using the /adv switch to perform tasks such as creating a new domain tree, installing from media (to reduce initial replication over a WAN), or selecting the source domain controller for initial replication.
Some improvements have been made to make your job easier and reduce frustrating errors. For example, if you are using the wizard to create a new domain controller in an existing domain or forest, you can browse for existing domains instead of having to type the NetBIOS name.
New pages have been added to specify additional options, to let you configure the DC as a global catalog server, as a DNS server, and as an RODC. In the wizard you can also configure site selection, set functional levels, create a password replication policy for RODCs, and configure DNS delegation.
As a command-line tool, dcpromo can be run in a completely unattended way. Unlike the same tool in Windows Server 2003, an unattended installation does not require a response to any user interface prompt, such as needing to restart the computer. This makes it easier to use ADDS on Server Core installations of Windows Server "Longhorn."
ADDS Auditing
Microsoft adds a lot more functionality to auditing for directory services in Windows Server "Longhorn." In Windows Server 2003, you could turn auditing on or off for directory access, but even if you had full success auditing enabled, the audit trail did not include what information had been changed. Now, it can.
In Windows Server "Longhorn," the auditing policy for ADDS has the following four subcategories:
- Directory Service Access
- Directory Service Changes
- Directory Service Replication
- Detailed Directory Service Replication
For most IT pros, there are two key facts to remember about these changes. First, the Directory Service Access auditing gives essentially the same information as it did under Windows Server 2003, but the Event ID is changed from 566 to 4662. Make note of this change if you use tools to parse the security event log. Second, the new category Directory Services Changes records both the previous value and the current value of the changed attribute.
To implement auditing in ADDS, you use the Global Audit Policy, System Access Control Lists (SACLs), and the ADDS schema. The components work together in order to give you both a flexible and comprehensive auditing framework.
The Global Audit Policy controls whether or not any auditing is done on ADDS. If auditing is enabled, the Global Policy controls which of the four subcategories of access (listed earlier) are audited. The Global Audit Policy is usually applied in the Default Domain Controllers Group Policy object, so it applies to the entire directory on the domain controller.
Although the Group Policy tools can turn the Global Audit Policy on or off, you must use the Auditpol.exe command-line tool to view or configure the subcategories. They are not exposed in the graphical user interface.
A SACL is a part of an object's security descriptor. By specifying entries in the SACL, you tell the system two things: which actions and which users (or security principals) you care about. In other words, you specify which users attempting to perform which actions should be recorded in the event log. So if you want to record changes to User objects made by Domain Admins but not by the users themselves, you can control this with SACLs. A SACL applies to an object (and can be defined for new objects, and inherited from container objects).
You can also configure the ADDS schema to limit change auditing to particular attributes. Since SACLs are applied to the object by default, access or changes to any attribute are recorded. This could generate a lot of logging activity, and perhaps not all attributes matter to you. So, at the attribute level, you can set a flag to prevent changes to that attribute from being logged.
SearchFlags is an attribute defined in the class that defines attributes, so it's an attribute of an attribute. It is also a bitmask, where each bit of a one-byte value represents a different on/off setting. You might find it easier to get your head around it by thinking of it as a property of an attribute. In Windows Server 2003, seven of these values are used to control various settings, including the indexing and GC replication of the attribute. In Windows Server "Longhorn," the eighth bit (with a value of 128) is used to control whether or not changes are logged. If this bit is set, ADDS will not log change events when modifications are made to that attribute. This applies to all objects that contain the attribute. In Beta 2, you cannot use the graphical user interface to set the eighth bit.
By default, in Windows Server "Longhorn," the Global Audit Policy is turned on and the Directory Service Changes is set to log successful changes.
Restartable ADDS
In Windows Server "Longhorn," ADDS is a restartable service. This simply means that the ADDS Services can be stopped and started without rebooting the domain controller. This allows administrators to perform functions that can't be done while the service is running (such as an offline defragmentation of the database) more easily and without entering Directory Services Restore Mode.
There are three possible states for a domain controller running Windows Server "Longhorn": ADDS Started, ADDS Stopped, and Directory Services Restore Mode. Let's examine each of these states.
ADDS Started The domain controller is operating normally.
ADDS Stopped The server has characteristics of both a domain controller in Directory Services Restore Mode and a domain-joined member server.
As with Directory Services Restore Mode, the ADDS database (Ntds.dit) is offline. The Directory Services Restore Mode password can be used to log on locally if another domain controller can't be contacted for logon.
As with a member server, the server is joined to the domain. Users can log on interactively or over the network by using another domain controller for domain logon. However, a domain controller should not remain in this state for an extended period because it can't service logon requests or replicate with other domain controllers.
Directory Services Restore Mode This mode (or state) is unchanged from Windows Server 2003.
The flowchart in Figure 6 shows you how a domain controller that is running Windows Server "Longhorn" can transition between these three possible states.
Figure 6** A Domain Controller on Windows Server 'Longhorn' Can Transition between Three States **
Looking for More?
It is impossible in one short article to explain the depth of the new ADDS features in Windows Server "Longhorn." But as you saw, new Active Directory features will solve a number of problems you previously had to try to work around or simply live with. As the release of the final version of the product draws near and you want to learn more, rest assured that additional documentation will be made available publicly. For now, the best place to look for updates during the beta phase is the Windows Server "Longhorn" Web site.
Byron Hynes works in the Windows Server User Assistance group at Microsoft. In the past, he worked as a consultant and trainer, and has a range of experience including running a regional Internet backbone, troubleshooting client-server and Web-enabled applications, and designing databases schemas, network infrastructure, and security models. You can reach him at bhynes@microsoft.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.