Active Directory Enhancements in Windows Server 2008

Windows Server 2008 contains a variety of enhancements to Active Directory (AD) services. A standout AD feature change is the new read-only domain controller (RODC). As the name indicates, this enhancement adds a read-only mode for DCs, so you can’t write changes to the AD database, and you can replicate only one way from other DCs. However, unlike the Windows NT Server 4.0 Backup Domain Controllers (BDCs), which might come to mind, an RODC can be configured to store only the passwords of specified users and computers. This limitation reduces the risks in case an RODC is compromised. The Server 2008 RODC feature, because it has the potential to reduce attack vectors thus improving physical security, will have a major impact on how you deploy and manage DCs in branch offices and the perimeter network (aka the DMZ).

Before I examine the RODC, I’ll show you other enhanced AD features in Windows 2008. I’ll walk you through the AD functional levels, both the domain functional levels (DFL) and the forest functional levels—FFL). This should give you a good understanding of the requirements for deployment of RODC and other new options, such as Fine-grained password policies (FGPP) and DFS replication for SYSVOL, which I’ll cover here. In addition, I’ll discuss changes made to DNS in Windows 2008 so that the DNS service works with smoothly with RODC.

For a quick overview, see a Web Table 1 which lists the RODC and other important enhancements to AD.

AD Functional Levels The RODC requires at least FFL2 (Windows 2003). What does this mean? Let’s look at the background of AD functional levels. AD functional levels were introduced with Windows Server 2003 to avoid conflicts between AD features specific to each OS version. Such conflicts can occur when multiple OS versions are deployed on DCs in an AD domain or forest. Functional levels are especially important when you want to introduce changes that affect the AD replication mechanism or other domain- or forest-wide features that downlevel versions of the Windows Server OS don’t understand.

For example, suppose you’re upgrading from a Windows 2000 (Win2K) forest, which is functional level 0, to a Windows 2003 forest. After all DCs in a domain are upgraded or replaced with Windows 2003 DCs, you can increase the domain’s functional level (DFL) to DFL2 (Windows 2003). DFL2 enables features such as DC Rename and the ability to write the last logon timestamp. After you switch all domains in aforest to DFL2, you can finally upgrade the entire forest’s functional level (FFL) toFFL2 (Windows 2003). FFL2 introduces featuressuch as transitive forest trusts, domainrename, and linked value replication (LVR).LVR is a major improvement for the replicationof large multi-valued attributes suchas group membership. With LVR, if youmake changes (e.g., adding or removing amember to or from a group) to a long list of values, only those changes are replicated toother DCs, instead of replicating the wholelist of values with every change of the list, asWin2K DCs do.

Note that many new features in Server 2008 AD don’t have a specific requirement for a DFL or FFL, but a minimum of DFL2 and FFL2 is desirable. Microsoft made an effort to ensure implementation of RODCs in domains hosting Windows 2003 DCs. This allows companies to deploy RODCs without first having to upgrade the whole domain or forest. But expect some Windows 2003 hotfixes along with Server 2008 to help make the two DC versions work smoothly with each other in the same domain. (For information on deploying RODCs in a forest containing Windows Server 2003 DCs, see the Learning Path.)

Four new features are enabled when you switch to DFL3 (Server 2008). Two of those affect AD design: the ability to assign different password policies to users in the same domain and the use of DFS replication for SYSVOL. No new AD features are enabled after you switch the forest to FFL3 (Server 2008)—i. e., once all DCs in the forest are running Server 2008. However, switching to FFL3 means that all domains in the forest must run Server 2008 DCs and that no domains or DCs with a legacy OS can be added to the forest. See Table 1 for a summary of new AD features by functional level.

Fine-Grained Password Policies
For OS versions prior to Server 2008, an AD domain can have only one password policy that applies to the user accounts in the domain. The password policy determines rules for password length, expiration date, and complexity for every account in the domain. Because these settings are defined via a Group Policy Object (GPO— i.e. the domain’s Default Domain Policy), many administrators thought they could apply multiple password policies simply by adding different GPOs at different organizational unit (OU) levels in the domain. However, these GPOs applied only to the computer’s objects located in the respective OUs and would thus affect only local accounts on those computers. Many companies found this situation disappointing and confusing.

Server 2008 changes this limitation by introducing Fine Grained Password Policies (FGPP). This feature is available only when all DCs in a domain are running Server 2008 and the domain has been switched to DFL3 (Server 2008). Although DFL3 still won’t let you apply different password policies to different OUs, DFL3 does let you define different password policies directly to a user account or to a group. Note that these policies also allow you to set different lockout rules. So, for example, you can set sensitive accounts to lock out after fewer attempts than with ordinary user accounts. To reduce the overall management effort, the best practice is to specify policy at the group level rather than the user level.

Because users can be members of multiple groups, potentially more than one of which is assigned a password policy, Server 2008 AD includes a feature to determine the resulting policy for any user. In case no policies have been assigned to the user or any of the user’s group memberships, the default domain policy applies. This feature gives companies flexibility in setting password policies. Although most companies have learned to live with the pre-Server 2008 limitations of a single password policy per domain, some organizations have deployed different domains just to allow creation of different policies. With Server 2008, you can use FGPP instead. Companies can consolidate domains previously used for different password policies and eliminate the hardware and operational costs associated with additional domains. Most companies will value the ability to enforce tighter policies for sensitive accounts in a domain, such as the administrative accounts and those used by services.

You manage the new password policies via Password Settings objects (PSO) created in the Password Settings Container in the system container of an AD domain. Currently, no native GUI or scripting tools are available from Microsoft to manage PSOs. Although ADSI Edit is not the sexiest GUI to work with for this purpose, this tool, which is now installed natively on every DC, works well to allow easy creation and management of PSO objects. Other UIs and new PowerShell cmdlets might be made available by Microsoft in the future, but already there are various tools available for free on the Internet to download and manage PSOs. See the Learning Path for more information on tools.

Using ADSI Edit to Create PSOs
Using ADSI Edit, you can create PSOs in five steps:

Using DFSR for SYSVOL
A key enhancement of Windows Server 2003 R2 was a new, efficient file replication service. Surpassing its predecessor in integration with DFS, the new file replication service was called DFS Replication (DFSR). A major new feature was the ability to restrict the replication traffic to just the changes in files between two DFS replicas. So if a file of many hundred megabytes is changed by just a few bytes, DFSR ensures that only the changed bytes are replicated to the various replication partners. Previously,with NT File Replication System (NTFRS), any change in a file (including changes to attributes such as a file’s NTFS permissions) caused the whole file to replicate. Now Server 2008 adds even more scalability enhancements to DFSR, such as an increased number of parallel file replication threads, and the removal of the 5,000 DFS targets limit per AD-integrated DFS root. (Now DFS roots can have an unlimited number of DFS targets.)

Ever since the availability of DFSR in Windows 2003 R2, AD administrators had hoped to leverage this new service for SYSVOL, after upgrading all DCs to Windows 2003 R2. However, this was not possible— SYSVOL had to keep using the inefficient NTFRS engine for replicating their Group Policy changes and the contents of the scripts folder (NETLOGON share). The inefficiency of NTFRS was actually one cause for AD architects to sometimes design multidomain forests, merely to reduce the NTFRS traffic if a large company had many slow high-latency network links that DCs needed to replicate across.

Continue on Page 2

Server 2008 will finally make DFSR available for replication of SYSVOL between DCs. All DCs in a domain must be running Server 2008, and the domain must be switched to DFL3 (Server 2008). However, in contrast to some other replication-related features, the switch to DFL3 does not automatically change the replication of SYSVOL from NTFRS to DFSR. A fairly cumbersome procedure, which uses the new DfsrMig.exe tool available on every DC, lets you create a new DFS root for the SYSVOL content. This new root uses DFSR while the original SYSVOL still uses NTFRS. As part of the migration process, you copy the original SYSVOL contents to the new SYSVOL folder, called SYSVOL_ DFSR by default.

After you switch to DFL3 and migrate to DFSR for SYSVOL, the SYSVOL share will leverage the new SYSVOL_ DFSR folder. From then on, the SYSVOL share’s contents will replicate much more efficiently. If you’re planning a new AD forest, inefficient SYSVOL replication will no longer be a reason to design a multi-domain forest.

DNS Changes
I don’t have the space here to explain all of the DNS changes in Server 2008. For this overview, you need to know that DNS has been updated to allow read-only zones, which are required to support the DNS service with the RODC role. The new readonly zones are similar to secondary DNS zones, except that the read-only zones are integrated in AD and can only be hosted on an RODC. As you might guess, a read-only DNS zone won’t accept dynamic updates from clients. So a special mechanism for RODCs ensures that clients are directed to the nearest writable DNS server for dynamic DNS registrations and update requests. Within five minutes after telling a client which server to update the DNS information on, the RODC’s DNS service will try to connect to that same DNS server to instantly replicate the DNS changes to its own database.

Another new AD-related DNS feature allows clients to locate DCs in the “next closest site” when they can’t connect to a DC in their own site, avoiding potentially slow connections to other remote DCs during failover. This new capability, a function of the DNS clients on Windows Vista and Server 2008, uses site-topology information and site-link costs stored in AD to determine the next closest site, before querying DNS to provide a DC in the respective site. This feature has been back-ported to Windows XP in the latest service pack. It can be enabled via GroupPolicy Object (GPO):

What’s the Big Deal with RODC?
A challenge with any Win2K or Windows 2003 AD deployment has always been the placement of DCs in remote sites (such as branch offices) that aren’t necessarily as physically secure as a company’s data center.

Except for special Operations Master (FSMO) roles such as the Schema Master and the PDC emulator, all DCs prior to Server 2008 are basically equal. Administrators of any Win2K or Windows 2003 DC can write changes to the AD database and can replicate these changes to other DCs in their AD domain or forest. Therefore changes performed on a single DC can affect the whole domain or even the whole forest. A malicious user with physical access to a DC, say, in a branch office, can fairly easily make an elevation-ofprivilege attack to damage or even destroy a company’s entire AD forest and dependent services.

As shown in Figure 1, the malicious change on the rightmost branch-office DC replicates out to the central hub DC, which then replicates that change to all other DCs in the enterprise. Furthermore, because all DCs always copy the full AD domain partition, including the passwords of all users and administrators in that domain, a compromised DC would also allow a thief to perform password cracking attacks against the DC’s AD database, enabling additional remote attacks. (See that thief in Figure 1? He just stole a DC.)

The Server 2008 RODC was designed to reduce such risks. You can use an RODC in locations that might not offer the same physical security as a datacenter but require rapid, reliable, and robust authentication services, even if the network link to a remote datacenter is not available. Companies that require such authentication quality in their branch offices no longer have to deploy ordinary writable DCs into these sites. Organizations now have the option to deploy RODCs, which by default don’t replicate passwords locally and never replicate local changes back to any other DC. RODCs have a one-way only replication connection agreement with their writable DC replication partner. Various changes in Server 2008’s underlying replication architecture ensure that this agreement can’t be changed. For example, RODCs aren’t members of the Enterprise Domain Controllers security group, which grants writeable DCs various write permissions to the AD database.

Password Replication Policies (PRP) determine which passwords to replicate to an RODC. Determining how to configure PRPs for your company will be a key challenge for the management of RODCs. PRPs are managed per RODC and provide a list of groups, users, or computer accounts that are either allowed or denied permission to cache their password on an RODC. The PRPs are stored with the computer account object of the respective RODC in AD, as Figure 2 shows.

Deploying RODCs is an extremely attractive proposition to increase security in branch office and DMZ deployments. As Figure 3 shows, you would deploy writable DCs in a Server 2008 AD infrastructure only in fully trusted networks (data centers). You can safely deploy RODCs in edge networks. As a result, an AD infrastructure attack like the scenario shown in Figure 1 is now limited to the attacked RODC in the branch office. And because the RODC doesn’t store any administrator user secrets (passwords) by default and will typically be configured to cache only the passwords of the users in the RODC’s site, a stolen RODC doesn’t pose the same risk to a company that a fully writeable DC does.

An RODC can also be a Read-Only Global Catalog (ROGC). Note however, that while ROGCs are supported to be used as GAL servers for Outlook clients, they aren’t supported as GCs for use by Exchange servers. This will have an impact on administrators who want to deploy the RODC in a branch office but also maintain a local Exchange server.

You can compare the features of an RODC with those of a proxy server. If a user is authenticating in a site that has an RODC, the user’s client will locate this RODC like any other DC and attempt to authenticate to the RODC. In fact, clients usually won’t know if they’re talking to a writeable DC or an RODC, because the RODC will retrieve all the data it needs on behalf of the client. When the user authenticates for the first time to this RODC, the RODC will need to talk to a writeable DC (usually across the WAN to a DC in a hub site) and authenticate the user against this writeable DC. If the RODC is allowed to cache the user’s password hash, as determined by the RODC’s PRP, the RODC will be able to fully authenticate the user the next time without needing to contact a writeable DC.

RODCs have other attractive features that distinguish them from writable DCs: For example, you can delegate local administrator rights (or other roles) to domain users or groups to a specific RODC, without granting the users any special rights in your AD domain. You do so by using the managedBy attribute of an RODC computer object or by assigning local roles through NTDSUTIL. This capability saves you from requiring a domain admin account for maintenance tasks on branch-office DCs that can also be performed by users with lower privileges. (This includes the task of promoting new DCs.) This capability is restricted to RODCs.

More to Learn
Server 2008 debuts several major AD enhancements, which are introduced this article. RODC is clearly the feature that Microsoft spent most effort on, as you can see by looking at the changes RODC required Microsoft to make to Server 2008’s underlying replication architecture. The Learning Path lists some further resources on Server 2008 AD enhancements and RODC.