7 More Reasons to Upgrade to Windows Server 2012 Active Directory

Much has been written in these pages about Active Directory (AD) improvements in Windows Server 2012—a lot of it by me! IT pros who are responsible for AD need to remember, however, that it’s not only explicit AD enhancements, such as the ability to clone virtual DCs, that might drive an AD upgrade.

It might be hard to believe, but AD isn’t the center of the IT universe. A more realistic analogy is that it's a critical part of the IT building’s foundation, like electricity. Employees must have it, typically 24×7, to get anything done, and they don't notice it until it doesn't work. To stretch that analogy a little further, AD also allows you to use a single switch to turn on all the ceiling light fixtures across your office floor instead of one fixture at a time. (This is my Authenticate once, access many times analogy.) How does this apply to AD upgrades? A number of new or improved capabilities in Server 2012 require upgrades to AD.

It's been my experience in corporate IT environments that other teams, looking at implementing a new OS or application capability, often aren't aware of the AD upgrade requirements of their project. Or if they are, they don't communicate those requirements to the AD team. When the requirements are finally dropped on the AD team’s doorstep, the project plan for the new capability is usually well underway and the AD folks are forced to devise and implement a hastily planned upgrade project. This phenomenon is a formula for unplanned downtime. The AD team’s other alternative is to tell the other team, "NO—not for a while." This is not a good career strategy.

Instead, look at the positive aspects of such a situation: If you don't have enough ammunition for a Server 2012 AD upgrade based on direct AD improvements alone, the AD upgrade requirements of other, higher-business-impact features might be enough. However you choose to look at it, it's in your best interest to understand which other Server 2012 features have AD upgrade dependencies. So, which new Server 2012 features require, or benefit from, an AD upgrade?

Dynamic Access Control

Dynamic Access Control (DAC) isn’t so much a single feature as it is a combination of new or improved technologies in Server 2012. Together, they provide a higher level of access control to and governance of Windows file servers.

The AD-related requirements for DAC depend on how broadly you plan to implement it:

Active Directory Federation Services 2.1

Active Directory Federation Services (AD FS) is now a full server role rather than an externally installed capability. If you're using AD FS for federated trust management (and you should be using some kind of federation solution, whether it’s AD FS, third-party on-premises software, or IDaaS), version 2.1 has greater flexibility in consuming claims. Before Server 2012, claims were created and stored in AD FS only. These claims were created from the user and group SIDs in the user’s Kerberos ticket or from LDAP queries that AD FS made to AD. In Server 2012, AD FS can consume AD user and device claims that are included in Kerberos tickets as a result of domain authentication. This is a much more integrated and flexible situation than that of its predecessor. AD FS includes these claims in a SAML token that it issues for the client, to be used by a web service such as Salesforce.com.

Enabling Kerberos claims in AD FS requires the following:

Active Directory-Based Activation

Product activation has also been integrated into Server 2012 with Active Directory–Based Activation (ADBA). Simply put, ADBA allows a product that supports Generic Volume License Key (GVLK) to automatically activate when it joins a forest that has been activated via the Volume Activation Management Tool (VAMT). This nice step forward for integration is tempered by the fact that the only products that recognize GVLK are Windows 8 and Server 2012. So, your volume activation infrastructure will get simpler … eventually. ADBA requires a Server 2012 schema update (to be able to store activation objects in AD), but it doesn’t require any DCs.

DirectAccess

If you aren’t already familiar with it, DirectAccess is a Microsoft network technology that enables a domain-joined client with Internet access, anywhere, to appear as though it is actually on the corporate network. Among many improvements to the technology in Server 2012 (and there are many improvements that make DirectAccess easier to deploy and use), you can now domain-join a client when it’s off the corporate network. This means you can join and manage a client without it ever having natively touched that network. DirectAccess requires a schema update.

Group Managed Service Accounts

Managed Service Accounts (MSAs)—introduced in Windows Server 2008 R2—attempted to solve the problem of changing service account passwords without impacting the services that relied on them. Unfortunately, a limitation of MSAs is that they must be used on a per-computer, per-service basis. This strongly limited their adoption. Server 2012 introduces Group Managed Service Accounts (gMSAs—have you noticed how lowercase letters are sneaking into acronyms?), which allow services running on multiple hosts to use the same gMSA account. Microsoft SQL Server clusters are a good scenario for gMSAs.

Cross-Domain Kerberos Constrained Delegation

Kerberos Constrained Delegation (KCD) is the ability of a service account to act on behalf of users in multi-tier applications to access a limited (hence “constrained”) set of back-end services. Before Server 2012, KCD worked only when the front-end service account was in the same domain as the back-end service. With Server 2012, these multi-tier applications can now span multiple domains.

This capability requires the following:

Functional Levels

What about AD domain and forest functional levels? AD-related capabilities in Server 2012 have become much less dependent on these settings than in previous OS versions. The “Functional level features and requirements” section in the TechNet article “Upgrade Domain Controllers to Windows Server 2012” provides more information about current requirements and about functional levels in general.

As I stated earlier, there’s one circumstance that might require you to bump the domain functional level. If you want all your DCs to advertise that they support claims (with or without mandatory Kerberos armoring and Flexible Authentication Secure Tunnel—FAST—as defined by RFC 6113), you’ve got to upgrade them all, then increment the domain functional level.

There are no specific features or capabilities that require Server 2012 domain functional level; it will, however, ensure that if you create any new domains, they will automatically be at the Server 2012 domain functional level.

Start Simplifying

You might not be able to justify Server 2012 AD on its merits alone (though you certainly should implement it), but other improvements might do the trick. Your security team will love gMSAs, and line-of-business (LOB) apps will appreciate the extra flexibility that KCD provides. Also, the basic implementation of AD claims and expressions for access control will let everyone start simplifying their security environment.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.