Windows Server 2008 R2 is known for its new Hyper-V implementation with zero down-time migration capabilities; however, changes to Active Directory (AD) in Server 2008 R2 are almost as compelling and hint at this important infrastructure’s future developments. The new AD features can be separated into two areas—manageability enhancements and "everything else," which includes some very useful capabilities.
Domain and Forest Functional Level Changes
Server 2008 R2 offers a new domain functional level, which you can enable after you have all Windows Server 2008 R2 domain controllers (DCs) in the domain. It adds support for the new authentication mechanism assurance features we will discuss shortly.
Server 2008 R2 also offers a new forest functional level. It requires all DCs in the entire forest to be running Server 2008 R2 and adds support for the new Recycle Bin feature. Unlike previous Windows Server domain and forest functional level changes, this operation isn’t one-way and can be reversed providing you haven’t activated any feature that requires the domain or forest level.
For example, if you’ve moved to the Server 2008 R2 forest functional level and haven’t enabled the Recycle Bin, you could drop the forest functional level back down to the Server 2008 functional level. After you move to a Server 2008 R2 functional level, you aren’t able to add Windows Server 2003 or Server 2008 DCs to the domain or forest. Before you can introduce a Windows Server 2008 R2 DC into a domain, you must perform a schema update as well as other tasks to be able to use certain new features in Server 2008 R2.
If you’re coming from a Windows 2003 domain as opposed to a domain already prepared for Server 2008, you’ll also need to update Group Policy objects (GPOs). In terms of co-existence, Windows 2000 SP4, Windows 2003 and Server 2008 DCs can exist in a domain with Server 2008 R2 DCs. Windows NT 4.0 BDCs aren’t supported in a domain with Server 2008 R2. Obviously as we start changing domain/forest functional modes we are restricted to the OS level of DCs to match our domain/forest level.
Managebility Features
Server 2008 started the big push for Windows PowerShell-based management across the OS and services, but not all components had PowerShell support (many, in fact, did not). Server Core’s new minimal installation mode with reduced footprint and attack surface didn't even support PowerShell because of the .NET dependency, which wasn’t available on Server Core.
Server 2008 R2 remedies many of these PowerShell omissions. Server Core now supports many components of .NET, which means PowerShell is supported on Server 2008 R2 Server Core installations, and many roles and features that previously didn't support PowerShell now do, including AD.
The AD PowerShell implementation includes 75 PowerShell cmdlets and a PowerShell provider with an additional 14 cmdlets. Microsoft estimates that around 70 percent of AD functions can be performed with direct AD cmdlets written specifically to address the actions. The other 30 percent of these actions can be accomplished with PowerShell but not with dedicated cmdlets; instead, combinations of cmdlets are used.
Active Directory Web Service
A new Active Directory Web Service (AD WS) is installed on Server 2008 R2 DCs; it operates over port 9389. The required firewall exception is enabled automatically as part of the role installation (including server core DCs); however, if you control firewall exceptions via Group Policy, you need to ensure you open this new port. Currently most tools connect using LDAP and remote procedure calls (RPCs).
However, offering a web service for AD access enables a superior developer experience and forms the first stage of a bigger objective, which is the enablement of AD for cloud and distributed service scenarios. AD PowerShell cmdlets use the interface provided by AD Web Service (ADWS). If a DC can’t be found offering the ADWS, then the AD PowerShell cmdlets won’t work.
It’s therefore very important you have a sufficient number of R2 DCs running ADWS across all domains that a PowerShell cmdlet might query. Although you can disable ADWS, it’s discouraged. Note that when Server 2008 R2 is released, an out-of-band update for Windows 2003 and Server 2008 will be released to add ADWS to these AD implementations.
Active Directory Administrative Center
Active Directory Administrative Center (ADAC) (see Figure 1) is a new interface designed to replace Active Directory Users and Computers. In future server versions, ADAC will also replace AD Domains and Trusts and AD Sites and Services, offering a single administrative interface for all AD management along with support for features that currently don't have any graphical interface, such as Recycle Bin and fine-grained password policies (FGPPs).
ADAC lets you manage users, groups, computers, and organizational units (OUs) and offers powerful and intuitive search and filter options. Within a single instance, it lets you manage multiple domains and even connect to multiple DCs simultaneously.
ADAC is built on PowerShell but currently doesn’t display the PowerShell commands that would be used to complete actions; this may be an option for a future version. ADAC consists of many layers; for example, it uses PowerShell, and PowerShell uses ADWS. ADAC’s many new components and dependencies on the new 2008 R2 capabilities actually give us a very rich platform for AD management.
Even More Great Management Features
In addition to the key features above, you’ll also find more components related to management. Each is extremely useful in its own right.
Active Directory Health Model. This is a single authoritative source for diagnostic information, which is used by the management packs and best practice analyzers. This health model can also be accessed by other third-party applications if necessary.
Best Practices Analyzer (BPA) for Active Directory. This is available through Server Manager and allows the installation of the selected DC to be validated against all the AD best practices. It’s a useful “quick access” check point to confirm configuration.
Management Pack for Server 2008 and Server 2008 R2. Although not an AD feature, a new System Center Operations Manager 2007 management pack monitors all features related to Server 2008 and Server 2008 R2 Active Directory implementations. See the Microsoft download page.
The Really Good Stuff
Server 2008 R2’s new management features give you many more options. However, the two most-sought after functions of Server 2008 R2 actually lie outside of management: Managed Service Accounts (MSAs) and the AD Recycle Bin.
Managed Service Accounts. Service accounts—dedicated AD accounts that run a server service—are the longest-standing security vulnerability in AD. Because services such as SQL Server and Exchange depend on these accounts, changing their passwords will interrupt the service.
To combat this problem, many installations opt to use built-in accounts such as the local system and network service accounts, which are then shared by many services. However, if one service is compromised, all the services using the same built-in account could be compromised. This has finally been fixed in R2 with MSAs.
MSAs in Server 2008 R2 are AD accounts that are designed to simplify password and SPN management by automatically changing the account’s password on the server when it’s changed in AD. The SPN configuration is required for Kerberos to correctly function and currently must be done by a domain administrator; with the MSA, you can delegate the SPN update to any user, along with the ability for the service to automatically update the SPN for its managed service account.
It should be noted that an MSA can be used only on one computer, no sharing between computers. To take advantage of the password management capabilities of MSAs, you can have domains running in Windows 2003 or later, but they must have run the Server 2008 R2 forest and domain preparations.
To access the SPN management capabilities, you must be running in Server 2008 R2 domain mode, which means using only Server 2008 R2 DCs. To use an MSA, machines must be running Server 2008 R2 or Windows 7.
When the Server 2008 R2 domain preparation is run, a new container is created, Managed Service Accounts. This is the default location for managed service accounts; however, you can change the location if needed.
All management of MSAs is performed via PowerShell cmdlets both within AD and on the server side. After you add an MSA in AD, give it any required rights, and install it to a service, you configure the service on the host to use the MSA, and that's it.
A virtual account works in a similar fashion to an MSA but is a local machine account. It doesn’t have any password management capabilities and doesn’t use AD. You can think of a virtual account as just additional network service accounts that have their own profiles. You don't add or remove virtual accounts; you just tell a service to use a virtual account.
AD Recycle Bin. Deletions happen within AD, sometimes caused by admin error. When this happens, you can boot into directory services restore mode and perform authoritative restores of certain objects, or you can try to reanimate the tombstoned object directly through utilities such as ADRestore from technet.microsoft.com/sysinternals.
Both have their problems. An authoritative restore is a pain and requires taking a DC offline during the restore process (and you need a good backup). Reanimating a tombstoned object takes away most of the attributes of the object, and all linked value attributes are removed (such as group memberships).
With Server 2008 R2 AD, we can enable the Recycle Bin, which allows the restoration of any deleted object through a simple PowerShell cmdlet, Restore-ADObject. Currently it doesn’t have a graphical interface; however, the PowerShell cmdlet still offers a lot of flexibility in restorations. When you restore an object from the Recycle Bin, all of the object’s attributes, both linked and non-linked, are completely restored, which means group memberships are also restored.
To enable the Recycle Bin, you must be at the Server 2008 R2 forest and domain functional level. After you enable it, the feature can never be disabled.
A deleted object can exist in one of two states after you enable the Recycle Bin: deleted or recycled. When an object is first deleted, it goes into a deleted state and is stored in the Deleted Objects container with its distinguished name mangled. An object stays in the deleted state for the msDS-deletedObjectLifetime duration, which by default is the same as the tombstoneLifetime duration—180 days. Both of these default times can be changed.
After the msDS-deletedObjectLifetime has passed, the object becomes a recycled object, and most of its attributes are stripped away (including linked attributes). After an object is in a recycled state, it can’t be restored—not via the Recycle Bin capabilities nor from an authoritative restore. The recycled state always wins: If you perform an authoritative restore of an object in a recycled state, it is placed back into that recycled state again. Once the tombstoneLifetime has passed, the object will be physically deleted via the garbage collection process.
Any objects that were in tombstone state at the time the Recycle Bin is enabled are automatically set into recycled state, which means you can’t undelete them via the Recycle Bin or an authoritative restore (because their attributes were already mangled per normal pre-Recycle Bin functionality). It should be noted that the Recycle bin is available for Active Directory Lightweight Directory Services (ADLDS) in addition to Active Directory Domain Services (AD DS).
Provisioning, Security, and Migration
Sometimes you need to complete a computer provisioning including joining a domain in environments where a DC might not be available. A new feature called offline domain join lets machines join a domain without having to contact a DC over the network.
The process uses a new command-line tool, Djoin.exe, which initially provisions the new machine with an account in AD and saves required information to a text file. The machine then uses the text file to be joined offline to the domain, and after a reboot, the computer becomes part of the domain. This is available only on Server 2008 R2 and Windows 7 computers.
A new feature called authentication mechanism assurance lets administrators add additional universal group memberships to a user’s Kerberos token when a certificate-based logon method is used. Services can then check for this universal group membership in the user’s token, which identifies details about the certificate-logon performed.
Different universal group memberships can be set in the token based on the certificate issuance policy object identifier (OID). This is very useful in federated identity management situations (such as ADFS) and claims-consuming applications in general.
The information in the token can be extracted to check the authorization level and to grant authorization appropriately, depending on whether a certificate-based logon method was used and the OID of the certificate. Authentication mechanism assurance requires Server 2008 R2 domain mode.
Lastly, Server 2008 R2 offers migration wizards and documentation to help migrate AD and DNS services to new servers. Since Server 2008 R2 is 64-bit, some companies will need to combine adopting Server 2008 R2 with a hardware refresh and possibly a virtualization platform. The new migration wizards and documentation offer detailed guidance for the entire process. The migration portal can be found at Microsoft’s website.
Deciding What to Do Next
Many organizations running Windows 2003 question whether they should adopt Server 2008 today or skip it and go straight to Server 2008 R2. Several different considerations can drive a decision to adopt Server 2008 R2.
You need to look at the feature sets available in the releases. Decide if the benefit of the feature warrants adopting Server 2008 today—for example, to take advantage of Read-Only DCs, Server Core, DFS Replication of SYSVOL, and FGPPs—or whether you can wait and jump straight to Server 2008 R2.
However, it’s important to realize that the decision whether to migrate to Server 2008 or to Server 2008 R2 doesn’t have to be “all or nothing.” Many of the new Server 2008 R2 features can be obtained by implementing only a few Server 2008 R2 DCs while leaving the majority of DCs on Server 2008. Obviously one of the most sought-after features, the AD Recycle Bin, is also the most complex and most expensive, requiring every DC in the entire forest to be running Server 2008 R2. The fact that Server 2008 R2 must run on 64-bit hardware might also be a deciding adoption factor.
