Dynamic Access Control is a set of features for Windows Server 2012 to manage authentication and authorization beyond Active Directory Groups. Dynamic Access Control focuses on four scenarios:
- Data Classification
- Expression Based Access Conditions
- Expression Based Auditing
- Encryption
There are five key components in Dynamic Access Control that work together to address the scenarios.
- Expression-Based Access Control Lists
- User and Device Claims
- File Classification Infrastructure
- Central Access and Audit Policies
- Access Denied Assistance
User and Device Claims
User claims are properties about the user such as what department they work in. Likewise the physical device can have claims associated with it. This can be used to prevent sensitive information from being exposed to an untrusted machine even if the user would otherwise be allowed to access the file.
Claims support a variety of data types including strings, Booleans, and integers.
Expression-Based Access Control Lists
Expression based ACLs operate on user claims, device claims, and resource properties.
The expression has two part, applicability and permission. The applicability check would usually be against the resource properties, such as “Resource.SecurityLevel = Secret”. If this returns true, then the permission expression is evaluated to see if the user/device pair can access the resource. Continuing the example, we would use “(User.SecurityClearance = TopSecret or User.SecurityClearance = Secret) and (Device.Location = SecureLab)”.
Expression-based Access Control Lists also extend existing group-based policies. Previously there was no concept of an “and” operator for groups. If a user needed to be in two or more groups in order to access a resource then a new group that represented both would need to be created. This “group bloat” is a leading problem among many large companies with dozens or hundreds of sites. Now an expression that translates to “user is in GroupA and Group B” can be written.
Users and developers can manage expression based ACLs using many different ways including APIs such as AddConditionalAce, PowerShell, or LDAP.
File Classification Infrastructure
The File Classification Infrastructure is used to assign resource properties to files. FCI supports both built-in and third party classifiers. In Windows Server 2008 R2, the file classifiers were run on a timer, usually late at night. With Windows Server 2012 they are run in near-real time. There is still going to be a small delay between creating a file and classifying it, making local permissions also important.
Another change to FCI is where the classifications are stored. Previously this was placed in a secondary file stream. This meant that it could be edited by anyone with write access to the file. With Server 2012 this has been moved into the file’s ACL. The list of possible file classifications is stored in ActiveDirectory.
Central Access and Audit Policies
Central Access Policy combines file classification with Expression-Based Access Control. This allows the IT department to setup high level rules such as financial documents (as classified by the FCI) can only be accessed if the user is in the finance department and in the project’s group. These rules are pushed onto the file servers using group policies.
Central Access Policies are checked after the share ACL is checked. If the CAP rules are also passed, then the files NTFS-based local file ACL is checked.
In order to reduce problems caused by misconfigured security settings, Central Access Policies can be staged. This allows the InfoSec manager to see who will lose access to a file and what rules are causing the problem.
Kerberos and the New Token
Kerberos is still the way claims are flowed across machines in an Active Directory. If the client is using Windows 8, the token now contains user claims, device groups, and device claims.
If the user is using Windows 7, OS X, or another operating system that doesn’t support this extension to Kerberos then extra steps are required for authorization. When enabled, the file server can query the Active Directory server for the missing claim data. This can be somewhat expensive in terms of latency and network bandwidth.
Another feature of the new Kerberos Token is the idea of a compound identity. This supports scenarios where a single user account does not alone have enough permission to access all the necessary files. The compound token may also include SAML information for accessing a cloud-based server.
Care must be taken to avoid “ticket bloat”, a condition that is caused by having too many groups and claims in the user’s Kerberos ticket. In order to reduce the impact of ticket bloat the claims and groups are compressed. Furthermore, the maximum size of the token has been increased to 48K.
Access Denied Assistance
In a nut shell, Access Denied Assistance helps users figure out why they were denied access to a given resource. It can do things like remind them to insert a physical passkey or tell them what access violation rule they at this time. It can also be configured to send an email to the resource owner so that their access request can be reviewed and potentially granted.
Deployment
Adding resource properties just requires an update to Active Directory and a Windows Server 2012 file server. User Claims and Central Access Policies requires a Windows Server 2012 Domain Controller. For device claims your clients need to be running Windows 8 as well.
