Use Active Directory Claims for Windows Server 2012 File Service Access Control

Windows Server 2012 Active Directory Domain Services (AD DS) added support for claims as part of the new Dynamic Access Control feature. Dynamic Access Control is a large and complex technology that lets you apply centralized governance, classification, and information protection on Server 2012 file servers. What has been largely overlooked, however, is that you can use claims right away on these file servers to give you new flexibility without waiting for a Dynamic Access Control implementation.

Security Groups

Using security groups to control access to files and folders is as old as the Windows NT Server file system. By adding groups to an ACL, then controlling group membership, this form of "crowd control" has enabled administrators to dynamically manage access to their resources without constantly manipulating the ACLs. Add the capability to nest these groups (e.g., to provide worldwide access to a folder, you might add NA_Sales, SA_Sales, EUR_Sales, and APAC_Sales global groups to the Sales domain local group), and you have a powerful and flexible access control model.

It's not without its problems, however. First, security group lifecycle management is one of the most neglected areas of Active Directory (AD) hygiene. Everyone wants you to create groups in a hurry, but no one (except AD admins) seems to care about when it's time to eliminate them. As a result, most large AD domains have tens of thousands of security groups—many of them empty—with no plan to clean them up.

Second, you can run into trouble when you build a universal/global/domain local group access control architecture and don't account for the possibility of acquisitions or divestitures that may require multi-forest access.

Finally, group nesting, when combined with poor group lifecycle management, can lead to extremely complicated access control architectures. I think all admins would be surprised and dismayed to learn how many circular group references (a set of nested groups that refers to one of the groups in the set) they have in their environment.

Much of this complexity is reflected in a user's access token. The AD access token, stored in the Privilege Attribute Certificate (PAC) field of the user's Kerberos ticket-granting ticket (TGT), contains the user's SID and the SIDs of the security groups of which the user is a member. If, due to complex nested groups, the user is a member of many groups, that person will have large tokens that can lead to resource access problems.

One of the main reasons nested groups are used in this model is because they are the only architectural way to provide an AND operation. For example, consider a US-based program, classified secret, in a multinational corporation. One requirement is that only the HR people on the project have access to the folder that contains program employees' salary information. Further, because it's classified secret by the corporation, only full-time, US, HR employees can have access. Using only security groups, the access control configuration might look something like the diagram in Figure 1. This scenario calls for the creation of 12 groups to AND three conditions together to provide access. Multiply this situation hundreds of times in an international corporation, and you see the problem.

Claims and Conditional Expressions

The access control model in Figure 1 uses only security groups, but it doesn't use an important repository of up-to-date corporation information: Active Directory itself.

Figure 1: Nested Groups to Enable "AND" Access Conditions

In most companies, AD receives much of its user attribute information directly from HR databases, so you know its data is up-to-date. But unless you're using an external engine like a metadirectory service, these changes won't be reflected in security group membership.

As I describe in my article "Enable Claims Support in Windows Server 2012 Active Directory," Server 2012 AD DS supports exposing user and device attributes to File Services as claims. With this capability configured, you can add attribute values (such as department name or number) to a file or folder's ACL to control access to it. While I don't ever see it supplanting security groups for access control—AD attribute classes are tightly defined and not easily created or modified—using AD attributes in the form of claims to supplement and potentially simplify group-based access control can be a great benefit to administrators. Next I explain how you would use the hybrid model for this example.

Two of the three conditions in this example, Full Time Employees_US and HR Department_US, can be replaced by claims. Look at Full Time Employees_US. I can break it down into two AD attributes. First, an employee's country can be represented by the two-digit attribute countryCode (00 would be a typical choice for the United States). And second, the attribute that best represents employee status would be employeeType. The latter attribute is string-based, so you can define it how you'd like. This is both good and bad; you'll want to keep it as simple as possible and (in my opinion) humanly readable. In other words, values of 0, 1, 2, and 3 are all good, but no one looking at the attribute can tell what the values represent. Instead, consider representing the values simply but with some clue as to their meaning: "F" or "FTE" for full-time employee, "T" for temp or "C" for contract, and "V" for vendor. Of course, this is English-centric, but I'm describing a US-based company.

You could describe the condition like this:

          user.countryCode=00 AND user.employeeType=FTE

For HR Department_US, I can simplify things a little more. If I make the assumption that if the expression evaluates true (i.e., they are US and full-time employees), then if they are members of the HR department they will be members of the US HR department. To represent this with an AD claim, I can use the department attribute:

          user.department=HR

The resulting representation of this hybrid access control architecture would look like the diagram in Figure 2.

Figure 2: Hybrid-Groups Claims Access Control

You could even argue that the Secret US Program Employee Bonuses domain local group is redundant (though standardized access practices might dictate it should remain). Using conditional expressions, I reduced the number of groups necessary to represent this access condition by two thirds.

Example of How to Set Hybrid Permissions

The following is a step-by-step example of how you would implement this hybrid set of permissions in a fictitious Fly By Night Software domain, flybynightsoftware.com. First, create the Secret US Program Employee Bonuses domain local group, and then the Secret Project Members_US global group. Add Secret Project Members_US into Secret US Program Employee Bonuses, and add this group into the Program Bonuses folder ACL. Next, build the claims-based controls.

Before you create claim types, you must enable claims for your domain via the process I outlined in "Enable Claims Support in Windows Server 2012 Active Directory." Then you must create claim types for the following user attributes:

To do this, launch Active Directory Administrative Center (Figure 3).

Figure 3: Active Directory Administrative Center

There are at least three ways to launch ADAC, but if you have a command prompt open, just type DSAC.

In the left content pane, choose the arrow next to Dynamic Access Control and then select Claim Types (Figure 4).

Figure 4: Selecting Claim Types

The Tasks pane appears on the right; it gives you the ability to create new claim types. Claim types also appears under Dynamic Access Control in the left content pane.

Select New, Claim Type from the Tasks pane. This launches the Create Claim Type dialog box (Figure 5).

Figure 5: Creating a Claim Type

Enter employee in the Source Attribute filter field, as Figure 5 shows. This automatically narrows down the available attributes to three; choose employeeType from the list. Note that the display name defaults to the display name of the attribute. If you want to make it a bit friendlier, change the display name to "Employee Type." You also can update the description to include the different possible values of this attribute.

Don't use line breaks in the Description field; using Return or hitting the Enter key will simply create the claim type before you're ready. When you're ready, click OK to create the claim type. Repeat this process for countryCode and department (see Figure 6 for an example).

Figure 6: All Claims Types Created

Now you're ready to configure the Program Bonuses folder with this mix of security groups and claims. Look at the folder's properties, then the Security tab, then advanced permissions, and choose Add. Four layers deep into the File Explorer dialog boxes, you've arrived at the Permission Entry dialog box (Figure 7), which creates an access control entry (ACE) that you can add to the folder's discretionary ACL (DACL).

Figure 7: Adding Conditional Expressions to the Access Control Entry

There are three main sections in this dialog box. The first section lets you select a security principal (in this case, Secret US Program Employee Bonuses) to add to the ACE. Next is the type of access to be granted. The third section is new. It lets you add conditions to limit access to the resources. (If you've worked with Apple's iTunes, this section looks familiar to how you build a smart playlist based on the attributes of your music files.) In Figure 7, I've added the three claims-based conditions necessary to meet the example's access requirements. You can see how simple configuring conditional access is once you've made the appropriate claims available in this dialog box.

Once you click OK, these conditions are displayed in the Conditions column of the Advanced Security Settings dialog box, which Figure 8 shows.

Figure 8: ACL Showing Conditional Expression Access Control Entry

Claims-Based Access Control Caveats

Claims-based access control does have some management and governance concerns you should consider. In a group model, you're careful about who has rights to three of the four CRUD operations (create, read, update, delete) that change membership in a group. The same concerns exist for claims—you must pay attention to who has rights to populate, update, and remove AD attribute values. But because until now there has been little need for it, AD attribute governance in most companies isn't nearly as mature as group governance. If you want to use claims-based access control, you need to pay attention. Is this attribute populated by a "convenience" feed from another system versus a secured feed? Who in the HR department has the rights to populate the employeeType, countryCode, and department attributes? What if a user with this access should change the format of one of these attributes? Would it break some of your claims-based access control configurations in production? Would you receive advance warning about it?

You also need to be certain your AD data is clean and consistent within a domain and across domains if you have a multi-domain forest. You can't count on a claim working consistently if the data it relies on isn't consistent. You also must be careful regarding the impact claims have on the Kerberos ticket-granting ticket (TGT). If you enable a claim type for a broadly populated attribute such as employeeType, that claim value will go into the security token of every user in the company. It isn't much in and of itself, but don't go crazy making populated AD attributes in claims without thinking through the ramifications. (If an attribute is only populated for some users, however, only those users will have it added to their security token.)

If you want to use claims-based access control for a special application or group, you'll run into an available attributes problem: Most attributes are already defined for a specific use. Unless you want to repurpose existing attributes (e.g., telexNumber: anyone remember a telex?) so that you can have a batch of unused, general purpose attributes, then you'll have to add your own attribute classes to AD by performing a schema extension.

Still, none of these caveats are insurmountable; you simply need to take your time and think through the situations in which claims-based access control will benefit your directory and business.

Experience in Claims

Implementing this sort of conditional access scenario is a good way to gain experience in the area before you begin something like a full-blown Dynamic Access Control test or pilot. It's worth repeating that claims-based access control isn't intended to replace the well-used group model. Rather, claims-based access control is a good addition to groups in situations where achieving the required access with groups alone would be too complicated.

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.