Dynamic Access Control: Introduction to the Technology and Components
Dynamic Access Control (DAC) is a new capability in Windows Server 2012 that is the result of various infrastructure improvements, which allow claims-based authorization to file server resources.
Dynamic Access Control (DAC): What and Why
While not intended to completely replace Access Control Lists (ACLs), anyone who’s managed file servers in a large environment will know how controlling access to files can quickly become a challenge. Setting NTFS permissions on files and folders and managing Active Directory (AD) groups and membership doesn’t scale well for file server management.
Dynamic Access Control adds authorization capabilities to the File Classification Infrastructure (FCI), which was first introduced in Windows Server 2008 R2. It, along with other developments in Active Directory and security management in Windows Server 2012, provides administrators with an centralized mechanism to automatically classify files and authorize users based on claims made by a trusted source.
Compliance and Security Challenges
If the contents of a file changes – for instance, the addition of classified information or if users move from one department to another – access to resources can automatically be reevaluated without an administrator manually changing ACLs, AD group membership, or the classification of files. This automation greatly reduces the administrative effort required to secure important data. FCI can also be used to perform file management tasks according to how files are classified, such as moving expired data to an alternate location.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
DAC access policies are centrally managed, and they don’t require administrators to secure each object using an ACL. Conditional expressions, i.e. logic that contains AND/OR operators, determine access to files, enabling access decisions to be made in situations that ACLs alone can’t provide for. For example, you might grant users read-write access to a file when accessed from a company-owned device, but read-only access when accessed from a personal device.
The combination of DAC and FCI enables organizations to meet compliance requirements faster and with greater confidence that sensitive information is appropriately protected at all times. New auditing features in Windows Server 2012 also makes it easier for organizations to produce audit reports for compliance analysis.
Reducing Group and Token Bloat
If you want to grant only users who are members of both the finance and HR departments access to a file using the ACL model, they will likely be members of three AD groups: HR, Finance, and a third group called HR and Finance. Using Dynamic Access Control, AND operators can be used to write an expression that requires a user be a member of both the HR AND Finance groups – without the need for a third group – before access is granted. In large organizations, using conditional expressions like this can dramatically reduce the number of groups required and the size of Kerberos security tokens.
Understanding DAC Terminology and Components
Before trying to configure DAC, you’ll need to understand what claims and resource properties are, how conditional expressions can be used to authorize access to files, and how DAC integrates with the existing File Classification Infrastructure in Windows Server 2008 R2 SP1 and Windows Server 2012.
Device and User Claims
Windows Server 2012 domain controllers act as trusted authorities in the access control process, where Active Directory presents information about a user or device, such as which department the employee works in or their physical location. This information is known as a claim, and is used in addition to Security Identifiers (SIDs) to control access to file server resources. Most Active Directory user attributes can be used as claims, and the same applies for computer objects and relevant AD attributes for device claims.
A claim type is a mapping between a source Active Directory object attribute and a claim that can be used for DAC. So for example, if you want to use the Country and Department user object attributes in Active Directory as claims, you will need to set up a Country and a Department claim type in DAC. Active Directory object attributes cannot be used as claims without an appropriately configured claim type in the DAC configuration. When creating a claim type, you also specify suggested values to make it easier for administrators to configure file access.
Resource properties were first introduced in the File Classification Infrastructure in Windows Server 2008 R2. Administrators can add resource properties to the DAC configuration, which are distributed to file servers so that files can be classified. For instance, you might define a resource property that allows files to be tagged with a department name. This information in the file metadata can then be compared against a user claim that contains the AD Department attribute.
A file might be marked as containing personally identifiable information (PII) or only accessible to users working in a particular department. The combination of claim and resource property information allows for conditional expressions to be created that can be used to make complex authorization decisions. A simple conditional expression might be:
If resource.department = user.department, then ACCESS = TRUE
Consequently if a user has the Department attribute in Active Directory set to Finance, then any files where the Department resource property is also set to Finance will be accessible to the user. While the example I’ve given here is very simple, more complex expressions can be created using operators and parenthesis, allowing greater flexibility than controlling access via the ACL model.
Resource properties are organized into lists in the DAC configuration. The Global Resource Property List is created by default and is downloaded to all file servers. Resource properties must be added to at least one list. You can create your own Resource Property Lists and use Group Policy to distribute them to specific file servers.
Central Access Rules and Policies
Central Access Rules are similar to ACLs in that they determine whether a user can access a resource. A rule can contain a conditional expression to determine if access to a file resource will be granted. As an example, you could create a condition that files with the Department attribute set to Finance can only be accessed by users with a matching Department attribute value in Active Directory.
Central Access Rules are added to Central Access Policies, which are in turn distributed to file servers using Group Policy. Only one Central Access Policy can be applied to a file or folder.
Claims-based authorization and auditing requires at least one Windows Server 2012 (or later) domain controller and one Windows Server 2012 (or later) file server. If you intend to use device claims, Windows 8 on the client will also be required.
Claims can be used in Active Directory forests where there are also Windows Server 2008 and Server 2008 R2 domain controllers, and there is no requirement for the forest or domain to be set at a particular functional level. However, you should make sure that you have sufficient Windows Server 2012 domain controllers to process authentication requests that incorporate claim information.
How Do I Configure Dynamic Access Control?
Basic configuration tasks can be carried out in the Active Directory Administrative Center (ADAC). For larger DAC deployments, Microsoft also offers the Data Classification Toolkit, which has been updated to support Windows Server 2012 DAC and is free to download.
In the next part of this series, I’ll show you how to enable Kerberos armoring so that security tokens can include claim information for DAC, and how to perform basic DAC configuration, including configuring claim types, resource properties and central access policies.