Enable Claims Support in Windows Server 2012 Active Directory

One new, lesser-known feature in Windows Server 2012 Active Directory Domain Services (AD DS) is support for claims-based authentication. This lack of prominence belies the feature's significance to the future of Active Directory (AD) and AD's interaction with the enormous world of web services.

Claims aren't new; they've been around in one form or another almost as long as computers. In its simplest form, a claim is a statement made by a party. That's all. It's a bit more complicated than that, of course, but that's the core concept. The power of claims-based identity is that a party (also known as the identity provider; for example, a company) makes an assertion that its user Jim Bob is a member of the engineering department. The web service (also known as the relying party or service provider, such as a Software as a Service—SaaS—application) that wants to use this bit of identity data trusts the digitally signed information coming from the company.

And—this is important—the process doesn't need Jim Bob's password to accept the assertion. You can stop practically anyone on the street today, and that person would tell you in so many words that password-based authentication has outlived its usefulness. It's critical that companies move to authentication and authorization methods that don't require passwords. Claims-based authentication is at the core of federated identity, and through federation you can securely extend your corporate identity to access web services for which you'd otherwise have to create a user ID and password.

Claims made their first foray into Windows with Active Directory Federation Services (ADFS), a connector to the external web services world. Before Server 2012, ADFS created claims from AD security groups and LDAP queries that it made to AD. In Server 2012, ADFS 2.1 consumes claims directly from AD. Early in the life of ADFS I described it as a technology without a business need because there was little need for claims-based authentication in the Windows world. The rise of cloud services, and SaaS in particular, however, has changed that. Federation services, whether on premises like ADFS or hosted in the cloud as an identity management as a service solution, provide a gateway between the Kerberos-based world of AD and the claims-based world of web services.

Claims have made their entrance into AD specifically to support Dynamic Access Control and conditional expressions in file services ACLs. And as I said, claims also are consumed by ADFS 2.1. So if you're interested in implementing Dynamic Access Control, ADFS 2.1, or conditional expressions to control access to data on Windows file servers, you need to implement AD claims. Server 2012 AD supports both user claims and device claims.

Understand Active Directory Claims Architecture

The schema update for Active Directory in Server 2012 introduces several new class objects:

The central access policies (and their constituent rules) that Dynamic Access Control uses are supported by the following class objects:

Claims created in AD are stored in the Configuration partition, under CN=Services,CN=Claims Configuration (Figure 1).

Figure 1: Claims Created in Active Directory Are Stored in the Configuration Partition

How do these claims make it from AD to the client? The answer is Kerberos, the standard authentication and authorization protocol used by Windows. Kerberos is by far the most logical place to insert claims; otherwise, a second security protocol would have to be designed within the Windows security system—no small task.

If you're familiar with the Kerberos protocol, you recognize that the only place you can put such data (i.e., claims) is in the Privilege Account Certificate. The PAC is an extension element of the authorization-data field contained in the client's Kerberos ticket-granting ticket (TGT). The PAC structure conveys authorization data provided by domain controllers (DCs) to Windows clients. Before Server 2012, the PAC contained information such as SIDs, group membership (also in a SID format), user profile information, and password credentials.

In Server 2012, the Kerberos PAC contains the previously mentioned security information plus user and device claims. If you've been concerned about Kerberos token bloat in your environment, then you're probably thinking, "Microsoft is cramming more data into the PAC while large companies are already running into PAC storage limitations?" Microsoft has addressed this concern in several ways, which supposedly mitigate the problem. First, MaxTokenSize (the amount of buffer allocated to store authorization information) has been bumped from 12KB in previous versions to 48KB in Server 2012, which helps eliminate authorization failures in applications such as Microsoft IIS. There's also a Group Policy setting that warns of large Kerberos tickets.

Finally, Server 2012 has introduced SID compression, a BFO (blinding flash of the obvious) enhancement that saves PAC space. I'll describe SID compression in more detail in an upcoming article.

Why aren't all AD attributes automatically representable by claims? The simplest explanation is that making every populated attribute of the user or device object available as a claim would include these claims in the Kerberos PAC no matter whether they are used. And most won't be used, so it would be a massive and unnecessary increase in data overhead in an area that doesn't have a lot of it to spare. It's a much cleaner solution to determine which attributes you need to make available as claims based on your conditional expressions and Dynamic Access Control requirements and then create claim types for them.

Windows Server 2012 File and Storage Services is the only server role that uses claims-based access control in this first implementation of the technology, although I'm sure other roles will pick up claims-based access control in future versions of the OS. Though of less interest to server administrators, Windows 8 also takes advantage of claims-based access control (which I discuss in the following section).

Implement Claims

You must perform several steps to enable claims in Server 2012 AD. First, you must upgrade the forest schema to Server 2012. You can do so manually through Adprep, but Microsoft strongly recommends that you add the AD DS role to a new Server 2012 server or upgrade an existing DC to Server 2012. This process automatically performs all required Adprep operations (see "Windows Server 2012 Simplifies Active Directory Upgrades and Deployments").

Once AD can support claims, you must enable them through Group Policy:

Figure 2: Enabling Claims Through Active Directory Group Policy

Note that there are four settings for this policy, in order of increasing control: Not Supported, Supported, Always Provide Claims, and Fail unarmored authentication requests. I recommend that you study "Dynamic Access Control: Scenario Overview" before configuring this policy.

Once the policy is enabled and has replicated to all Server 2012 DCs in the domain, you must create claim types. To do this, launch Active Directory Administrative Center, which you can see in Figure 3.

Figure 3: Active Directory Administrative Center

Although it's similar to Active Directory Users and Computers, the Active Directory Administrative Center also has an item for Dynamic Access Control (in addition to the deuby domain) on the left side of the navigation pane. Select Dynamic Access Control and then Claim Types to bring up AD claim types. Figure 4 shows two claim types that I created previously.

Figure 4: Active Directory Claim Types

Selecting New from the task pane on the right brings up the Create Claim Type dialog box, which you can see in Figure 5.

Figure 5: Create Claim Type Dialog Box

The Source Attribute section displays a list of attributes that can be represented by claims. Windows creates the list of attributes from the following schema class objects:

By default, the Create Claim Type dialog box shows the accountExpires attribute because it's the first attribute on the list. Note that Display name and Description are displayed on the right; this is where you can change these fields to something more descriptive.

As an example, I can create a third claim type associated with the user's last name. The AD attribute ID for one's last name is surname, with a display name of sn. Entering surname in the filter field brings up this attribute (Figure 6). For this example I changed the display name of the claim type to something more useful: Last Name.

Figure 6: Creating a Claim Type Associated with the User's Last Name

Finally, I select OK, which brings up the Active Directory Administrative Center dialog box showing the newly created claim type (Figure 7).

Figure 7: Active Directory Administrative Center Showing Claim Type Last Name

As I alluded to, you can use conditional expressions with claims in both Server 2012 and Windows 8 to provide a fine degree of access control to file folders.

Figure 8: Using Claim Types to Control Access to Files and Folders

Figure 8 shows how the claim types I created can be used in an advanced security dialog box to modify access to config.bgi based on company, department, or last name (in addition to group membership). This demonstrates how Server 2012 can control access to files and folders based directly on AD attributes.

Use Claims-Based Authentication

Claims are an unheralded AD DS feature in Server 2012. They're an integral component of Dynamic Access Control, but you can take advantage of them to simplify Windows file server access control without implementing Dynamic Access Control at all. I'll demonstrate the basics of this claims-based access control in an upcoming article.

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.