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.