(Editor's note: I've amended the article to show that you can promote a Windows Server 2012 R2 DC into a domain at Windows Server 2003 domain or forest functional level. Remember that when introducing a DC role for a new OS into an existing forest/domain, however, you must run forestprep/domainprep first.)
This is the second of two articles describing the updates Microsoft has made to Active Directory and identity management (IdM)-related components in Windows Server 2012 R2. In Part 1, I reviewed the major IdM scenario for R2, which is the ability to securely access web-based corporate resources from anywhere with an IOS or (soon) an Android mobile device. In addition, this scenario provides optional capabilities like multi-factor authentication and context-sensitive access control.
In this article I'm focusing more on IdM-related changes beyond Part 1's scenario (though I do throw a couple of minor scenario-supporting features in as well). All components of the Active Directory family - Domain Services (AD DS, the on-premises Active Directory you know and love), Federation Services (AD FS), Certificate Services (AD CS), and Rights Management Services (AD RMS) – have had major or minor updates. DNS has had some minor changes. Some old domain and forest functional levels are seeing the sun set on them. And last but not least, a service that AD has depended on since its very beginning has been moved to the deprecated (supported or bug fixed but no longer being developed, the last step before being removed) column. Be sure you check it out, because you'll eventually need to make an important change to your Active Directory!
New Active Directory Domain Services (AD DS) features
Schema update
The schema update for Windows Server 2012 R2 brings it to version 69 (objectVersion value of the schema naming context/object container). This update adds new object and attribute classes to support the "Connect to applications and services from anywhere with Web Application Proxy" scenario I described in Part 1, and the new Authentication Policy (below).
Domain and Forest Functional Levels
As you might expect, R2 has added new domain and forest functional levels, but your urgency to upgrade to them depends upon your need for the features that require them. Separate from any new functionality it enables, upgrading to a domain functional level (DFL) means that all DCs in the domain must be running at that level and servers running older OSs cannot be promoted to a DC. For example, you cannot raise the functional level of your domain to Windows Server 2012 R2 (msDS-Behavior-Version=6, if you're interested) until all your DCs are running Windows Server 2012 R2. And once you raise the DFL to Windows Server 2012 R2 you can't promote a Windows Server 2012 member server to a DC; you must upgrade it to R2 first. Forest functional level (FFL) follows the same general requirements and restrictions, only with a forest-wide scope. For more details on FFLs and DFLs, see Understanding Active Directory Functional Levels.
At the same time new DFLs and FFLs have been added, Windows Server 2003 DFLs and FFLs have been deprecated in this new release. When you create a new domain or forest, you have the option of using a functional level from Windows Server 2008 or newer.
The only new feature that requires a DFL or FFL upgrade is Authentication Policy and Silos (below), which requires a DFL (only) upgrade to R2.
Protected Users Security Group
Protected Users is a new global group designed for high-security identities (such as administrative accounts) that is highly secure by default.
Group members have restrictions that prevents the use of lower-security types of authentication. Specifically, members of this group can't authenticate using NTLM, digest authentication, or CredSSP (a security support provider introduced in Windows XP SP3). Group members must use Kerberos authentication – and it's also locked down for them. For example, the protocol won't use the weaker DES or RC4 encryption types in the preauthentication process, and TGT lifetimes are shorter. Logging in with cached credentials, a mainstay of offline mobile computing, is not allowed. Protected Users accounts are also not available for constrained delegation.
Finally, it's not a good idea to put service accounts or computer accounts into Protected Users. This is because the password or certificate for these accounts are always available on the host.
Protected Users requires the R2 schema update, a DFL of Windows Server 2012 R2 and at least the PDC emulator DC to be running Windows Server 2012 R2. Both client and DC must be upgraded to Windows 8.1 and Windows Server 2012 R2, respectively, to use these restrictions due to the new code required.
For more detail on Protected Users, see the TechNet article.
Authentication Policy and Silos
Authentication Policy and Silos allows you to control which computers a user can use to login to the domain. Working in conjunction with Protected Users, admins can apply access control conditions for authentication to the account. Authentication policies are enforced during the Kerberos AS or the TGS exchange. There isn't a lot of information available on this feature yet, so stay tuned.
Authentication Policy and Silos requires the R2 schema update, a DFL of Windows Server 2012 R2 and at least the PDC emulator DC to be running Windows Server 2012 R2. On the client side, enabling these protections requires the user to logon to clients running Windows 8.1.
You can read a little more about Authentication Policy and Silos in TechNet's Credentials Protection and Management article.
LSASS Memory Protection
The LSA (Local Security Authority), a protected subprocess inside LSASS (the LSA Security Subsystem), performs user authentication. LSA memory protection requires that any LSA plug-in driver (for example a smart card driver or password filter) must be digitally signed with a Microsoft signature. To get that signature, the plug-in must go through the WHQL (Windows Hardware Quality Labs) certification process. In addition, the plug-in must conform to the applicable Microsoft Security Development Lifecycle (SDL) process guidance. It's pretty clear that if you have a custom password filter enabled in your domain to enforce strong passwords, you must certify the filter before you turn this control on or the filter won't load.
LSASS memory protection requires a Windows Server 2012 R2 or Windows 8.1 OS. To enable this feature on domain controllers therefore requires a schema update to R2 in order to upgrade the DCs.
For more information on LSA memory protection, read the TechNet Configuring LSA Protection article.
Active Directory Federation Services (AD FS) changes
OAuth 2.0 Support
In Windows Server 2012 R2, AD FS has added much-needed support for the widely accepted OAuth 2.0 authorization framework. (For an overview of this standard, see my article "What are OAuth 2.0 and OpenID Connect?") The Windows Azure Authentication Library (AAL) has also been extended to support AD FS. You can read Uday Hegde's blog post for more information on these updates.
Extranet Soft Account Lockout
A piece of the mobile device access scenario I described in part 1, the idea behind this feature is to protect against brute force password attempts from valid user accounts against AD FS-protected applications. Rather than having password attempts go straight through AD FS to AD DS and hard locking out after the number of failed attempts defined by Group Policy, AD FS performs its own "soft" lockout and doesn't pass attempts back to AD Domain Services. The soft lockout threshold is set through PowerShell's Set-ADFSProperties. (Thanks to blog.auth360.net for this information.)
AD FS login pages now have mobile device versions, and are more customizable than in previous versions.
Finally, the AD FS v1 web agent has been removed from Windows Server 2012 R2.
Other Identity-related component changes
Active Directory Certificate Services (AD CS)
TPM Key Attestation: The certificate authority is able to attest to the fact that a private key has been created on the trusted platform module (TPM).
NDES enhancements for BYOD: Network Device Enrollment Service (NDES) will support certificate enrollment of all kinds from IOS and Windows consumer devices.
Active Directory Rights Management Services (AD RMS)
AD RMS has been updated to not use the (removed) AD FS v1 web agent.
The AD RMS SDK has been deprecated. To build applications for AD RMS, migrate to AD RMS SDK 2.0, which takes advantage of functionality exposed by the client in Msipc.dll.
The license revocation functionality in AD RMS has been deprecated. Use the protection policy to control the document lifecycle. To remove access to a particular document, set the validity time to “0” in the template, or select "Require a connection to verify a user’s permission in Microsoft Office". Be aware that both of these options require a connection to a Rights Management Server in order to open the files.
DNS
Enhanced zone level statistics: Zone level statistics are available for different resource record types, zone transfers, and dynamic updates.
Enhanced DNSSEC support:DNSSEC key management and support for signed file-backed zones is improved.
Enhanced Windows PowerShell support: New Windows PowerShell parameters are available for DNS Server.
Miscellaneous
Windows Identity Foundation 3.5 has been deprecated. Use version 4.5.
Windows Authorization Manager (AzMan) has been removed.
File Replication Services (FRS)
The File Replication Service (FRS; part of the Active Directory Domain Services role)has been deprecated. You should migrate any FRS-based SYSVOLs to use Distributed File System Replication (DFSR). This is important news: It means that all Active Directory domains using FRS for SYSVOL replication (which I'm guessing is about 98% of all AD installations) must convert this critical AD component from FRS to DFSR before they can move to the next Windows Server version beyond R2. FRS is still part of R2; you don't have to make any changes now to run this OS, but you will have to convert to DFSR to move forward. FRS is the AD-related component that synchronizes changes to the SYSVOL share between domain controllers. Without healthy SYSVOL replication, Group Policy, logon scripts, and domain controller availability and promotion is affected. I'll publish an article soon that details how to convert your SYSVOL from FRS to DFSR.
The Active Directory and identity management changes in Windows Server 2012 R2 can be grouped into two categories. The first group are changes to support BYOD access to corporate web resources, and affect AD FS the most. The second group are changes to increase identity protection against attack, and are focused mainly on AD DS. There's a lot to look at in this release, and the many changes to AD FS underscore this component's increasing importance in connecting Active Directory Domain Services to the wide world of mobile devices and cloud services.
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.
