First Look at Dynamic Access Control in Windows Server 2012


Back in October, I put a blurb in the Windows Security blog regarding the coming of new security controls in Windows Server 2012, and specifically the Dynamic Access Control (DAC) feature that helps administrators create a more centralized security model for accessing files and folders. DAC is a key component of Active Directory 8. What’s different about it is that it automates the tagging of sensitive data.

We all know that automating security helps to eliminate the human error factor that can lead to unexpected security breaches, and the sheer volume of data that resides on today’s corporate servers makes it almost impossible to manually identify the sensitivity of each individual file and the level of protection that it requires. However, automated processes may not always catch every sensitive file, either. That’s why Dynamic Access Control allows for a combination of manual and automated tagging, as well as application-based tagging of sensitive data.

DAC is especially useful for managing data that’s distributed across many file servers and locations, a situation that is becoming increasingly common with the advent of cloud computing. With DAC, you can establish policies for controlling file access that are applied across the entire domain to all file servers. This is in addition to the traditional NTFS permissions and share permissions that we’ve used for years, with the centralized policies taking precedence. It adds one more layer of security for data.

How it works

DAC leverages Windows Server 2012’s improved file-level auditing and authentication to tag files based on criteria such as content and creator. Specific types of data can be identified; for example, social security numbers, bank account numbers or credit card numbers would be tagged as sensitive. Administrators could also designate that files of a certain type/extension all be tagged, or only documents that contain specific keywords might be tagged. Tagging and categorizing data is already familiar from Windows Server 2008, but Windows Server 2012 takes it to the next level.

The identification and tagging of the data is the first step. You could specify that all the data related to personnel be tagged with the Personnel tag, that financial data be tagged with the Finance tag, and so forth. Once that’s accomplished, central policies can restrict access to those files based on different criteria. Specific users can be restricted, or all users within a particular group or department can be restricted. You can, for example, specify that only users who belong to the Finance group – and who have the appropriate NTFS and share permissions – will be able to access the Finance tagged files. Access can also be restricted based on devices instead of users.

Claims based access controls can also work in conjunction with other Microsoft technologies such as Rights Management Services (RMS). Tagged Office documents can be protected by RMS so that after they’ve been shared with others, you still maintain control over what those others can do with them. DAC protects the documents while they’re on the Windows 8 server, and RMS protects them when they’ve been sent outside the organization.

Finally, audit policies can likewise be applied across all the servers in your organization, which work with the file tags and with user and device claims.

Staking your claims

DAC is based on the new (to Microsoft’s core server authentication model) concept of claims-based access controls, introduced by Samuel Devasahayam and Nir Ben Zvi at BUILD 2011. You might already be familiar with claims-based authentication, which has been used in Internet security for quite some time and was implemented a few years ago in SharePoint 2010, built on the Windows Identity Foundation (WIF) and Active Directory Federation Services.

Claims-based authentication relies on a trusted identity provider. The identity provider authenticates the user, rather than every application doing so. The identity provider issues a token to the user, which the user then presents to the application as proof of identity. Identity is based on a set of information that, taken together, identifies a particular entity (such as a user or computer). Each piece of information is referred to as a claim. These claims are contained in the token. The token as a whole has the digital signature of the identity provider to verify the authenticity of the information it contains.

Windows Server 2012 turns claims into Active Directory attributes. These claims can be assigned to users or devices, using the Active Directory Administrative Center (ADAC). The identity provider is the Security Token Service (STS). The claims are stored inside the Kerberos ticket along with the user’s security identifier (SID) and group memberships.

Once the data has been identified and tagged – either automatically, manually or by the application – and the claims tokens have been issued, the centralized policies that you’ve created come into play.

Central Access Policies

A big advantage of DAC’s central access policies is the flexibility that you have to define conditions in a much more granular manner. You can create policies to apply to each of the classifications into which your files are divided. These policies can be based on user and device claims and file tags. You can use regular expressions to greatly simplify the process of, for example, specifying that users must belong to two specific groups in order to access the file, using the AND expression. NTFS in Windows Server 2012 had to be modified to make this work with the file system ACLs. This is a huge change to the Windows file system and the access control model. It should alleviate some of the problems that come from having too many security groups and the confusion that results from having users in multiple groups.

The down side is that, because of the changes to the code that were necessary to make this work, this means the central access policies can only be applied to files that reside on Windows 8 servers. The access control tags are still preserved when files are on non-Windows 8 servers, but the policy is no longer applied.

DAC and PowerShell

We all know that Microsoft has emphasized PowerShell as the method of choice for managing Windows Server going into the future, and consequently the number of PowerShell cmdlets have been increased. Many of the new cmdlets relate to Dynamic Access Control. Some of these include:












Along with Remove- and Set- cmdlets.


Dynamic Access Control is potentially one of the most powerful new tools that Windows Server 2012 administrators and security professionals will be able to leverage in Windows based networks – both in traditional datacenters and in the public and private cloud – to take security closer to the data that it aims to protect. As the importance of perimeters begins to fade and the focus shifts to protecting specific assets, more security at the file level will become an essential component in the overall security strategy for organizations that must keep sensitive data confidential. While doing so makes business sense for all organizations, for many it’s no longer optional due to the increase in government and industry regulatory requirements that mandate the ability to show that you’ve implemented high levels of security on client information, certain types of records (such as medical or financial records) and other specified types of data.

The claims-based model as implemented through DAC adds yet another layer of protection that, instead of adding complexity to the IT administrator’s job, actually makes it easier to close the loopholes and understand who has access to what, and make corrections where needed.

To find out more about how claims-based access controls can be used in the “real world” to enhance compliance and tighten information governance, be sure to check out the BUILD 2011 presentation on this subject that you’ll find here.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top