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:
- If you want to use modern conditional expressions (the ability to AND authorization conditions with expressions rather than security groups) or Access Denied help, you just need to upgrade your Windows file servers to Server 2012.
- If you want to implement claims in AD and Kerberos, or Central Access Policies (which require claims), you must have one or more Server 2012 DCs (and thus upgrade the schema). You must also configure \Policies\Computer Configuration\Administrative Templates\System\KDC\Domain Controller support for DAC and Kerberos armoring to enable claims support in the Default Domain Controllers GPO.
- If you want to choose either of the two most restrictive policy settings—Always provide claims orFail unarmored authentication requests—you must upgrade all the DCs in your domain to Server 2012 and increase the domain functional level. (See the “Functional Levels” section later in this article.)
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:
- DAC enabled and configured with more than one Server 2012 DC, so claims are present in the Kerberos token
- Compound ID (i.e., user + device claims) switched on for the AD FS service account
- Server 2012 AD FS
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.
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:
- At least one Server 2012 DC must reside in both front-end and back-end domains (and thus schema updates in each). The client’s domain doesn’t need to be upgraded.
- The front-end server hosting the service account must be running Server 2012.
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.
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.