Administrative Role Separation on RODCs
It's very common for a branch office DC to be managed by a local server administrator who does everything from running backups on the domain controller to cleaning keyboards. But it is a security risk to grant a remote site administrator the rights necessary to do general maintenance on a domain controller, and the site admin can potentially elevate her privileges in the domain. RODCs provide two kinds of administrative role separation to mitigate this threat.
With the first form of role separation, the domain administrator can promote the RODC in the normal way using DCPROMO, or she can use a two-step process where the actual promotion process is securely delegated to the branch site administrator, without granting any domain administration rights. The domain administrator pre-creates the RODC computer account in the domain using the Active Directory Users and Computers MMC snap-in, as shown in Figure 5.
Figure 5 Pre-creating the RODC computer account (Click the p_w_picpath for a larger view)
Selecting "Pre-create Read-only Domain Controller account" runs an abbreviated version of DCPROMO that performs all the tasks that require administrative access to the domain, including creating the computer account, assigning the RODC to a site, specifying the DC's roles, specifying the password replication policy, and defining the user or group that will need the rights to complete the DCPROMO operation on the RODC. The delegated administrator or group is stored in the managedBy attribute of the RODC computer object.
The delegated administrator can then run DCPROMO on the server itself. DCPROMO will detect the pre-created account and turn the server into an RODC. Running DCPROMO in this way does not require domain administrator credentials.
The second way RODCs provide administrative role separation is by creating local administrative roles on the RODC itself. These roles look like machine local groups—they are stored in the registry of the RODC, and they can only be evaluated on the RODC. But instead of using the Computer Management MMC snap-in to manage them, the administrator manages local RODC roles using NTDSUTIL. Figure 6 lists the local administrative roles on an RODC. These roles correspond one-for-one with the built-in groups in Windows.
plus.gif Figure 6 Local RODC administrative roles

Account Operators
Administrators
Backup Operators
Certificate Service DCOM Access
Cryptographic Operators
Distributed COM Users
Event Log Readers
Guests
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Terminal Server License Servers
Users
Windows Authorization Access Group

RODC Oddities
Because RODCs are read-only and no other domain controller will replicate from them, RODCs exhibit some unexpected behaviors. For instance, lingering objects—meaning objects that have been deleted everywhere else but on a particular DC because the DC was unable to replicate for longer than the tombstone lifetime of the forest—are normally detected by the outbound replication partners of the DC. But since RODCs have no inbound replication partners, there is no lingering object detection for them.
RODCs will not service LDAP update (add, modify, delete, rename, or move) operations. Instead, RODCs return an error with an LDAP referral to a writable DC that can service the operation. If the application that issued the LDAP update doesn't properly handle the referral operation, the application could fail.
Finally, if a user from another domain in the forest attempts to authenticate to an RODC, the RODC must be able to access a full DC in its own domain in order to obtain the trust password to properly pass the authentication request to the DC in the user's domain. If the network connection between the RODC and the full DC in its domain is unavailable, the authentication will fail.

Fine-Grained Password Policies
The ability to define more than one password policy in the domain was probably the most-requested feature for Windows Server 2008 ADDS. As you probably know, in Windows 2000 and Windows Server 2003 Active Directory, each domain supports only a single password policy that is applied to all security principals in the domain. If you need a separate password policy for a specific group of users, you have to create a separate domain. But now a new feature in Windows Server 2008 ADDS, called Fine-grained Password Policies, lets you define multiple password policies in a domain.
The new strategy uses groups to apply fine-grained password policies to users. You first define the fine-grained password policy by creating a new msDS-PasswordSettings object in the CN=Password Settings Container, CN=System, DC=<domain> container. The msDS-PasswordSettings object (PSO for short) contains attributes that parallel the password policy setting in Group Policy (see Figure 7).
plus.gif Figure 7 Attributes in the mSDS-PasswordSettings object

AttributeDescription
mSDS-PasswordReversibleEncryptionEnabledBoolean indicating whether passwords are encrypted using reversible encryption.
mSDS-PasswordHistoryLengthNumber of entries maintained in password history.
mSDS-PasswordComplexityEnabledBoolean indicating whether password complexity restrictions are enabled.
mSDS-MinimumPasswordLengthInteger defining minimum length of password.
mSDS-MinimumPasswordAgeINTEGER8 indicating minimum password age before it can be changed.
mSDS-MaximumPasswordAgeINTEGER8 indicating maximum password age before it must be changed.
mSDS-LockoutThresholdInteger indicating number of failed logins before lockout.
mSDS-LockoutObservationWindowINTEGER8 indicating number of nanoseconds within which consecutive failed logins have to occur to trigger lockout.
mSDS-LockoutDurationINTEGER8 indicating number of nanoseconds account is locked out.
You then assign the password policy to users or groups by adding the user or group names to the multi-valued mDS-PSOAppliesTo attribute of the PSO. Once you accept the idea that you don't apply password policies to OUs, it's pretty straightforward. But there is some additional complexity.
Users are usually members of many groups. So what happens if there are multiple conflicting password policies associated with a user because of these group memberships? In this case, ADDS uses a precedence evaluation to determine which password policy should be applied. It works like this:
  1. If a password policy is linked directly to a user object (not via group membership), that password policy will be applied.
  2. If there are multiple password policies linked directly to the user, the policy with the lowest precedence value (as determined by the value of the msDS-PasswordSettingsPrecendence attribute of the PSO) will be applied.
  3. If there are multiple PSOs with the same precedence, the one with the lowest objectGUID value will be applied.
  4. If no PSOs are linked directly to the user, ADDS will evaluate the PSOs linked to the user's groups. If there is more than one PSO, the PSO with the lowest value in the msDS-PasswordSettingsPrecedence attribute will be applied.
  5. If there is more than one PSO with the same precedence value, the one with the lowest objectGUID value will be applied.
  6. If no PSOs are associated with the user, the domain password policy will be used.
User objects have a new attribute called msDS-ResultantPSO to help sort out exactly which PSO applies to a user. This attribute contains the distinguished name of the PSO that governs the password of that user.
Fine-grained password policies give you more flexibility than you could ever need, but you must manage these policies carefully and keep them simple. There is no in-the-box utility for defining fine-grained password policies; you will either need to use ADSIEdit or find a third-party utility.

Restartable Active Directory Service
Every time you take a domain controller down for DIT maintenance you cause some disruption in your network service levels. Windows Server 2008 DCs have a new feature that lets you stop the directory service without completely shutting down the DC.
The NET STOP NTDS command stops ADDS on a Windows Server 2008 DC. When you do this, the Local Security Authority (LSASS) process on the DC continues to run, but it unloads all the ADDS-related DLLs and the directory service becomes unavailable. LSASS then behaves essentially as it would on a member server by forwarding domain authentication requests to a DC. Because the DLLs that handle ADDS are unloaded, you can apply ADDS-related patches or perform an offline defrag of the DIT. Starting ADDS is as simple as NET START NTDS. Restoring the DIT from a system state backup still requires you to boot into directory service repair mode, however.
It's important that you understand that the directory service is not a real Windows service. It is still an integral component of LSASS and you can't stop LSASS without shutting down the machine. But the ability to start and stop the directory service in Windows Server 2008 is a convenient option.

Backup and Recovery
The entire backup and restore mechanism has been revamped in Windows Server 2008. I won't go into all the details here, but the new Windows Server Backup has some changes that affect ADDS.
Windows Server Backup is a volume-based backup solution, meaning it backs up entire disk volumes at a time. It also only backs up to disk (or disk-like) devices—there is no tape support.
There is a system state backup option for the WBADMIN command line backup utility. Using the WBADMIN START SYSTEMSTATEBACKUP command, you can now create a backup p_w_picpath that contains all the critical system files necessary to restore Active Directory on a domain controller. There is, however, a potential for as many as five volumes in the backup set, but the volumes in the backup set will contain only the files needed for a system state restore. Even more annoying is that, as of the RC0 build of Windows Server 2008, you cannot perform a system state backup to a network share. You must have a local disk volume available to store system state backup p_w_picpaths, and that volume must not be part of the system state backup volume set. You may have to add a new disk volume to every domain controller on which you perform system state backups.
Performing a system state restore is simple. Just boot the DC into Directory Services Restore Mode and run the WBADMIN START SYSTEMSTATERECOVERY command. The result is a non-authoritatively restored DIT, on which you can authoritatively restore specific objects using NTDSUTIL, just as you did in Windows Server 2003.
One aspect of Windows Server Backup deserves special mention: it stores backup p_w_picpaths in Virtual Hard Disk (VHD) format. This is the same format that Microsoft Virtual Server 2005 uses to store its virtual disk p_w_picpaths. This means you can take a backup p_w_picpath created with Windows Server Backup and mount it as a disk drive in a virtual machine running under Microsoft Virtual Server. You can then browse the backup contents as if it were a normal disk drive!
Another change regarding ADDS backup is the ability to use the Volume Shadow Copy Service to create point-in-time snapshots of Active Directory. When you create a snapshot using NTDSUTIL, the Volume Shadow Copy Service saves the before-p_w_picpath of each disk block of the DIT before it is overwritten by an update operation. By combining the saved before-p_w_picpaths with the current version of the DIT, the Volume Shadow Copy Service can construct a complete snapshot of the DIT with very little overhead. A typical snapshot takes only a few seconds to create, regardless of the size of the DIT.
By itself, this is an interesting capability, but not all that useful. However, in Windows Server 2008, ADDS includes a command-line utility called DSAMAIN that mounts the snapshot p_w_picpath in read-only mode. This provides a standalone LDAP server, much like an ADLDS instance that contains the contents of your directory at the time of the snapshot. You can browse the directory using the LDP utility or other LDAP tools and retrieve versions of directory objects from an earlier point in time.

SYSVOL Replication with DFS-R
Windows Server 2003 R2 featured a revamped Distributed File Service (DFS) that incorporated a brand-new file replication mechanism called DFS-R. It uses remote differential compression, which substantially reduces file replication traffic by determining which blocks of a target file need to be replicated to bring it into sync with the source file. However, Windows Server 2003 R2 still uses File Replication Service (not DFS-R) to replicate SYSVOL between domain controllers. Because of this, SYSVOL replication continued to be a source of problems for Active Directory administrators.
When running at the Windows Server 2008 domain functional level, Windows Server 2008 can replicate SYSVOL using DFS-R, improving the speed and robustness of SYSVOL replication. And this makes it reasonable to place large files in SYSVOL to make them available on all DCs. To use DFS-R for SYSVOL, you must first migrate the old SYSVOL data to DFS-R using the DFSRMIG utility. This process has four steps:
  • Create the Active Directory objects required by DFS-R.
  • Create the new file structure for SYSVOL on each domain controller.
  • Switch over all domain controllers to use the new SYSVOL.
  • Remove the old SYSVOL.
Depending on the size of your SYSVOL and the number of domain controllers you have, this process may take a while, but the improved performance and reliability make the effort well worth your while.

Auditing Improvements
The auditing system in Active Directory for Windows Server 2003 is both a blessing and a curse. On the one hand, it provides a pretty comprehensive, flexible, and secure solution for tracking changes in the directory. But some may argue that it suffers from several significant usability problems.
Enabling auditing of directory changes on a Windows Server 2003 domain controller is pretty much an all-or-nothing affair—it's either on or it's off. And the volume of audit traffic on a busy enterprise DC can render auditing impractical. Configuring the auditing system to produce the messages that you really need by fiddling with individual security descriptors is tedious and prone to error. The audit messages themselves are often cryptic, and in many cases don't contain the information you need, such as the before and after values of changed attributes. And collecting, correlating, and archiving the messages from multiple domain controllers is not really feasible using the native Windows tools.
The directory services auditing system in Windows Server 2008 addresses some of these problems. First, there are four new audit subcategories for directory service auditing: DS Access, DS Changes, DS Replication, and Detailed DS Replication. So if you want to just audit directory changes, you don't have to wade through all of the read and replication events. But, if you want to include object deletions in your audit log, you must enable DS Access. This generates messages for all DS object accesses, essentially putting you back to generating too many messages. And it is still up to you to configure the security descriptors to generate the audit messages that you want for the objects you care about.
The audit messages have been substantially cleaned up so that they are both readable and contain the data you need. In particular, directory changes generate audit log entries that contain the old and new values of changed attributes. This is a huge improvement. The only downside here is that the old and new values appear in separate audit log entries, so you have to correlate them to really understand the change that was made. Many add-on audit-log collection products, including the Microsoft Audit Collection Services, support this kind of correlation.

UI Improvements
The Active Directory Users and Computers, Sites and Services, and Domains and Trusts MMC snap-ins have always been adequate for managing Active Directory. In Windows Server 2008, the basic admin tools have been cleaned up and introduce a couple of nice new features. If you enable Advanced Features, the Properties dialog for each object displays an additional tab titled Attribute Editor. This is the same attribute editor tab used by ADSIEdit, which lets you inspect and edit all of the attributes of the object. The tab itself now offers better decoding of encoded attributes, such as the userAccountControl attribute. Figure 8 shows how seamlessly the attribute editor is integrated.
Figure 8 Attribute Editor in Active Directory Users and Computers (Click the p_w_picpath for a larger view)

Wrapping Up
Aside from the key points I've discussed in this article, there are many other improvements you'll find in ADDS in Windows Server 2008. For instance, the KDC uses the 256-bit Advanced Encryption Standard (AES-256) if the domain is in Windows Server 2008 domain functional level. You can enable Accidental Deletion Prevention of objects by checking the appropriate box on the Object tab for any DS object. The Extensible Storage Engine that provides the data management service has been enhanced to use single-bit error correction, reducing the likelihood of a hardware or software error in the disk subsystem from corrupting the DIT. The DNS service starts processing requests before it has completely loaded the DNS database. The DC Locator module has been enhanced so that if it fails to find a DC in the desired site, it will try to locate a DC in the next nearest site instead of simply using any DC it can find in the domain. And NTDSUTIL now supports RODCs and Volume Shadow Copy Service snapshots.
Clearly, Windows Server 2008 provides a substantial number of improvements in Active Directory Domain Services. Taken together, these changes will significantly improve the security and manageability of ADDS. The best thing, however, is that integrating Windows Server 2008 into your Active Directory environment doesn't involve a massive migration—it's an easy and incremental process