This documentation is archived and is not being maintained.
Special Coverage: Windows Server 2008
What's New in Active Directory Domain Services
At a Glance:
- Using the new Server Manager with ADDS
- Running domain services on Server Core
- Read-Only Domain Controllers
- Changes to passwords, backing up, and auditing
With Windows 2000, Microsoft introduced the world to Active Directory. The next major release, Windows Server 2003, brought significant improvements to Active Directory, but no
earth-shattering changes. Today, Active Directory® is a very mature, robust directory service. Even so, the Active Directory team has provided several substantial advancements in the latest version to improve the security and manageability of this core network service.
Back around the turn of the century, Active Directory was the thing that authenticated a user when he logged in, applied group policies to the user and his computer, and helped him find the printer he was looking for. Just a few years later, Microsoft released a standalone variant called Active Directory Application Mode (ADAM).
By 2006, this had all changed. Active Directory was no longer a specific technology. It's now a brand name that identifies a collection of in-the-box Windows® identity and access control services. Figure 1 provides a quick rundown of what makes up the Active Directory brand.
|Current Active Directory Technology||Previously Called||Description|
|Active Directory Domain Services (ADDS)||Active Directory||What we used to call Active Directory. It provides Kerberos and NTLM-based authentication for domain users and computers, and manages OUs, users, groups, group policies, and much more.|
|Active Directory Lightweight Directory Services (ADLDS)||Active Directory Application Mode (ADAM)||A high-performance LDAP server based on the same source code used by ADDS.|
|Active Directory Certificate Services (ADCS)||Certificate Service||Provides strong authentication using X.509 certificates.|
|Active Directory Rights Management Services (ADRMS)||Rights Management Server||Protects digital assets, such as documents and e-mail, from unauthorized use by creating rights-protected files and containers.|
|Active Directory Federation Services (ADFS)||Active Directory Federation Services||Provides Web single-sign-on and identity federation for WS-* compliant Web services.|
So, to use the proper terminology, this article is about Domain Services. But to be clear, this is still the same Active Directory you've grown to love since 2000.
Server Manager in Windows Server 2008
The first two improvements for Active Directory I am going to discuss really aren't changes in Active Directory Domain Services (ADDS); rather, they are changes in Windows that will change the way you manage Active Directory. The first, the new Server Manager, shows up as soon as you boot your Windows Server® 2008 server for the first time. (The second is the Server Core installation, which I'll get to in a moment.)
Server Manager will probably look familiar to you from the Configure Your Server Wizard in Windows Server 2003, which comes up by default after you install Windows Server 2003. That version, however, isn't very useful for day-to-day administration, and everyone I know checks the "Don't display this page at logon" box.
Server Manager in Windows Server 2008, on the other hand, is quite useful (see the article by Byron Hynes in this issue of TechNet Magazine for an overview of Server Manager). First, as you can see in Figure 2, Server Manager is now a Microsoft® Management Console (MMC) snap-in rather than a Microsoft HTML Application (HTA). This means it has a full-featured user interface that is familiar and easy to customize. Out of the box, Server Manager lets you manage the installation of server roles (major services such as DNS, ADDS, and IIS) and features (software components, such as the Microsoft .NET Framework, BitLockerTM drive encryption, and Windows PowerShellTM). Beyond the ability to add and remove software, Server Manager also provides a single point of contact for running diagnostic tools (such as the Event Viewer and PerfMon) and system configuration utilities (such as Device Manager and the Windows Firewall snap-in). If you add in the MMC snap-ins for Active Directory—for instance, Users and Computers, Domains and Trusts, and Sites and Services—you'll have a pretty nice interface to perform day-to-day management of your Windows Server 2008 domain controller (DC).
Figure 2 Server Manager in Windows Server 2008 (Click the image for a larger view)
Windows Server 2008 Server Core
Windows Server Core is a new Windows installation option that provides a trimmed-down version of Windows containing only the components necessary to run certain key server roles, including Active Directory Domain Services. (Figure 3 lists the roles supported by Server Core.) Although a Server Core installation has a graphical UI, it doesn't run the Windows desktop shell and almost all of the graphical tools for managing and configuring Windows are absent (see Figure 4). In their place, you get a command window and a terrible feeling in the pit of your stomach that you don't know what to do next. How do I change the computer name? How can I configure a static IP address?
Figure 4 There's not much to see in the Server Core UI (Click the image for a larger view)
The first few minutes in front of a Server Core installation can be unsettling. But after a little time re-familiarizing yourself with WMIC, NETSH, and NETDOM, you'll be able to do all the usual setup and configuration tasks with no difficulty. And you still get Regedit and Notepad to satisfy your graphical tool needs.
The main advantage to Server Core is that much of the code you get with a typical Windows installation, which you may not need for these core server roles, is removed. This reduces the potential attack surface for malware (a good thing) and reduces the amount of patching and rebooting you'll have to perform on your DCs (an even better thing). And you get a much smaller disk footprint and reduced hardrive requirements—these aren't usually a big deal, but it can be a help in virtualized server environments.
Will the lack of graphical utilities make managing ADDS difficult? Not at all. You can perform almost all of your management tasks remotely by running the utilities on your workstation and connecting to the domain controller over the network. I expect that the vast majority of DCs will eventually be running on Server Core installations.
The first change you'll notice in ADDS itself is the new DCPROMO. It works the same as DCPROMO in Windows Server 2003, but it's been completely rewritten to make it easier to use. For instance, you don't have to enter your domain administrator credentials—DCPROMO can use the credentials of your current login to promote the server. Nor do you have to type DCPROMO /ADV to get the Advanced Mode DCPROMO options—now there's a checkbox on the first DCPROMO dialog to enable these options. Advanced mode also lets you select the existing domain controller to replicate from. This means you can keep the replication load of DCPROMO off of your production DCs.
When you promote a DC into a new domain or forest, DCPROMO gives you the option to set the forest and domain functional level, rather than having you do this later. You can also specify the Active Directory site you want to place the DC in during the promotion process, which is very useful in the unattended DCPROMO scenario. DCPROMO will even suggest the best site for the DC based on the DC's IP address.
The new DCPROMO also collects all of the configuration options onto a single page, providing one place where you choose whether the new DC will be a global catalog (GC), a DNS server, or a read-only DC. You don't have to go to an obscure location in the Active Directory Sites and Services snap-in to mark the DC as a GC.
But perhaps the nicest feature in the new DCPROMO is the ability to save all the DCPROMO settings in a response file just before the promotion process starts. This is much simpler—and less error-prone—than cobbling up the response file by hand. You can then use the response file to perform unattended DCPROMOs on other servers. And for you script fanatics, all of DCPROMOs options are now accessible from the command line.
Read-Only Domain Controllers
In the early days of Active Directory, enterprises often deployed domain controllers at every site at which users might log in. This was common in banks, for instance, placing a DC in every branch office. The logic was that users at the branch office would be able to log in and access local network resources even if the WAN failed.
At the time, the need for physical security of DCs wasn't well understood. I saw domain controllers tucked beneath desks where they could easily be accessed by people walking by. It wasn't until a few years later that Active Directory architects fully comprehended the security risk that an unsecured DC creates, and IT organizations started consolidating their DCs back into more centralized datacenters. Branch office users then had to authenticate over the WAN, but it was a worthwhile trade-off for the added security.
Active Directory in Windows Server 2008 changes the equation with respect to branch office deployments by introducing read-only domain controllers, or RODCs. These represent the biggest change in Windows Server 2008 Domain Services.
The Active Directory team focused on the requirements of the branch office scenario when they designed the RODC and they adopted the goal of "What happens in the branch office, stays in the branch office." The point is that if you deploy a DC in a physically insecure branch office, there's ultimately nothing you can do to prevent the DC (and the machines that trust that DC) from being compromised, but you can prevent that compromise from spreading from the branch office out to the rest of the domain.
Note that even though they constitute a huge change to the ADDS infrastructure, RODCs are quite straightforward to implement. Your domain must be at Windows Server 2003 forest functional level, and there must be at least one Windows Server 2008 DC in the domain. And beyond simply being a branch-office solution, RODCs make sense in Internet-facing environments and in situations where the DC is placed in the network perimeter.
DC Gone AWOL
There are several classes of threats to consider in a branch office. The first is the "stolen DC" scenario, where someone walks off with the DC or the disk of the DC. Beyond the local service disruption, the risk is that the attacker ultimately gains access to all of the user names and passwords in the domain and from there elevates his privileges to gain access to protected resources or cause a denial of service. To address this threat, RODCs, by default, don't store the password hashes in the Directory Information Tree (DIT) of the RODC. So to authenticate a user to the domain, when a user first authenticates to a particular RODC, the RODC passes the request to a full domain controller (FDC) in the domain. The FDC processes the request and, if successful, the RODC issues a replication request for the password hash.
A compromised RODC could potentially request password hashes for sensitive accounts. To prevent this, the domain administrator can configure a password replication policy for each RODC. The password replication policy is made up of two attributes on the RODC's computer object. The msDS-RevealOnDemandGroup attribute contains the distinguished names of groups, users, or computer accounts whose passwords may be cached on the RODC (these are typically the users and computers in the same site as the RODC). The msDS-NeverRevealGroup contains the distinguished names of groups, users, or computer accounts whose passwords may not be cached on the RODC (for instance, the domain administrator account should never have its password hashes cached on an RODC). When the RODC requests the password hash for a particular account, the FDC evaluates the request against the password replication policy to determine whether the password hash should be replicated to the RODC. When a DC is stolen, this limits the vulnerability to those passwords that happen to have been cached on the stolen RODC at the time it was removed from the network, and it eliminates the possibility of a critical password being compromised.
The RODC computer object contains two other attributes to help you determine exactly which accounts should have their passwords cached. The msDS-AuthenticatedAtDC attribute lists the accounts that have been authenticated to the RODC, and the msDS-RevealedList attribute names the accounts whose passwords are currently stored by the RODC.
User and computer password hashes are not the only secrets stored on a DC. The KrbTGT account contains the keys for the Kerberos Key Distribution Center (KDC) service running on each domain controller. In a typical scenario, each KDC in the domain shares the same KrbTGT account, and it is possible that an attacker could retrieve these keys from a stolen DC and use them to attack the rest of the domain. However, each RODC has its own KrbTGT account and keys, eliminating that possibility.
It is also not unusual for applications to store passwords or other secrets in the DIT. If an attacker were to steal a DC, she could possibly steal these application passwords and use them to gain access to the applications. To mitigate this risk, Windows Server 2008 Domain Services allows administrators to define the Read-Only DC Filtered Attribute Set (RO-FAS). Attributes that are part of the RO-FAS are never replicated to RODCs, and thus they can't be retrieved from a compromised DC. You assign attributes to the RO-FAS by setting bit 9 (0x0200) of the searchFlags attribute of the corresponding attributeSchema object in the schema.
Barbarians inside the Gate
Another class of threat for branch office domain controllers is the case of a local server administrator elevating his privilege by leveraging the DC's privileges to gain access to other domain resources or to engineer a denial of service attack. Again, if the local administrator has physical access to the domain controller, there's little that can be done to prevent compromise. But it is possible to prevent the attacker from using the branch office domain controller to compromise other DCs in the domain.
RODCs are not trusted as domain controllers by the full DCs in the domain. From a trust standpoint, FDCs treat RODCs as member servers in the domain. An RODC is not a member of the Enterprise Domain Controllers or Domain Controllers groups. The RODC account has very limited ability to update anything in the directory, and therefore even if an attacker does compromise the RODC account, she'll gain almost no useful privileges.
RODCs don't even show in the normal DS replication topology. Because RODCs look like normal member servers rather than domain controllers, the Knowledge Consistency Checker (the KCC, which is the process on each DC responsible for calculating the DS replication topology) won't build connection objects from RODCs. No full DC or RODC will try to replicate from an RODC. On the other hand, the RODC will create a connection object representing an inbound replication agreement from a full DC, but this connection object only exists in the RODC's replica; no other DC has a copy of that connection object. From a replication standpoint, RODCs are like Roach Motels for directory objects. Objects replicate in, but they don't replicate out.
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 image 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.
|Certificate Service DCOM Access|
|Distributed COM Users|
|Event Log Readers|
|Incoming Forest Trust Builders|
|Network Configuration Operators|
|Performance Log Users|
|Performance Monitor Users|
|Pre-Windows 2000 Compatible Access|
|Remote Desktop Users|
|Terminal Server License Servers|
|Windows Authorization Access Group|
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).
|mSDS-PasswordReversibleEncryptionEnabled||Boolean indicating whether passwords are encrypted using reversible encryption.|
|mSDS-PasswordHistoryLength||Number of entries maintained in password history.|
|mSDS-PasswordComplexityEnabled||Boolean indicating whether password complexity restrictions are enabled.|
|mSDS-MinimumPasswordLength||Integer defining minimum length of password.|
|mSDS-MinimumPasswordAge||INTEGER8 indicating minimum password age before it can be changed.|
|mSDS-MaximumPasswordAge||INTEGER8 indicating maximum password age before it must be changed.|
|mSDS-LockoutThreshold||Integer indicating number of failed logins before lockout.|
|mSDS-LockoutObservationWindow||INTEGER8 indicating number of nanoseconds within which consecutive failed logins have to occur to trigger lockout.|
|mSDS-LockoutDuration||INTEGER8 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:
- If a password policy is linked directly to a user object (not via group membership), that password policy will be applied.
- 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.
- If there are multiple PSOs with the same precedence, the one with the lowest objectGUID value will be applied.
- 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.
- If there is more than one PSO with the same precedence value, the one with the lowest objectGUID value will be applied.
- 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 image 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 images, 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 images in Virtual Hard Disk (VHD) format. This is the same format that Microsoft Virtual Server 2005 uses to store its virtual disk images. This means you can take a backup image 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-image of each disk block of the DIT before it is overwritten by an update operation. By combining the saved before-images 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 image 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.
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.
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 image for a larger view)
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.