The process for implementing the new Dynamic Access Control feature will be a timely endeavor for enterprises. Here's how you get started.
- By Gary Olsen
- 08/01/2013
Microsoft has identified Dynamic Access Control (DAC) as one of the most important new features in Windows Server 2012 because it's designed to provide better security, risk-management, and auditing policies in Active Directory by enabling more granular methods of authorization and authentication. DAC does this by providing more flexibility in how files are classified, secured, accessed, and governed, based on various attributes and conditions applied within Active Directory.
Despite these major improvements in how the new Windows Server can let you implement policies, DAC requires extensive changes, as noted in Redmond Editor Jeffrey Schwartz's January 2013 cover story, "Group Control". As a result, it will take time before many enterprises implement DAC widely due to the complexity and planning it requires.
However, DAC will become an important part of any Windows enterprise in the future for a number of reasons. The most obvious benefit to Active Directory admins is that it implements security without using security groups. As a result, I've spent a great amount of time exploring DAC, and I'll explain what you need to know to start implementing it.
Many organizations have a complex web of groups and nested groups, many of which they've forgotten about or ignored. I recall one company I worked with that said its proliferation of security groups became so difficult to manage that it didn't know who had domain admin rights -- and it was afraid to fix the situation because the whole infrastructure might come unraveled.
Authorization Enhancements
Microsoft identifies several feature enhancements in Windows Server 2012 to improve authorization management. Among them is new Kerberos support for user claims and device authorization, implemented through Group Policy, which I'll discuss later on. Windows Server 2012 also supports conditional expressions, which enhance permissions management and auditing.
DAC uses enhanced security descriptors introduced in Windows Server 2008 R2 and Windows 7 to allow conditional expressions in user and device claims and resource properties. This allows a file resource, for example, to be limited to members of the sales department who reside in Canada. The various attributes in User properties are used for these expressions such as the Department attribute (see Figure 1). DAC also uses conditional expressions via Global Object Access Auditing. (Note: Security Groups still work just fine in Windows Server 2012 and with DAC implemented.)
[Click on image for larger view.] Figure 1. Define basic attributes of an employee such as job title and department.Central Access Policies (CAPs) now allow common management of all access policies via Active Directory and can be implemented across forests. File Classification Infrastructure (FCI), introduced in Windows Server 2008 R2 and Windows 7, allowed classification of data but without access control. DAC adds that missing component, making it "claims-aware."
Other additions to Windows Server 2012 include automatic Rights Management Services (RMS) extensibility to encrypt non-Microsoft files and access-denied assistance: When access to a remote file is denied, Windows Server 2012 provides additional information to the user to assist in problem resolution and reduce calls to the IT help desk.
Based on my research and work in my lab to try to figure this out, it's pretty clear that there isn't a lot of documentation, and DAC is a multi-headed beast that's somewhat difficult to understand. Even with virtual labs and demos, it's easy to run into trouble spots. Of course, I raised the difficulty level a couple of notches by implementing DAC in a multi-domain forest, where the root domain is a Windows 2003 forest functional-level domain but has Windows Server 2008, Windows Server 2003 and Windows Server 2008 R2 domain controllers, only one of which is physical.
I'll walk you through the process of implementing CAPs, including notes about important things to remember and some troubleshooting. I used the Microsoft virtual lab (go to the very last link, "Using Dynamic Access Control to Automatically and Centrally Secure Data"). I recommend doing the lab just to become familiar with everything, but also using the procedure here to set it up in your own lab.
First off, I need to define what a "claim" is. Microsoft defines it as "information a trusted source makes about an entity." Claims may include the user or computer Security Identifier Definition (SID), department classification of a file and other attributes of a file, user or computer. Claims can be used to grant access to resources. While Windows authorization was heretofore based on the SID of a security principal, Windows Server 2012 extends that authorization to be based on these claims, thus providing greater granularity in security and reducing the need for using groups for authorization to resources.
There are three types of claims: user, device and transformation. The example in this article uses the user claim.
Active Directory provides a way to have access policies in a central location that allow access to date on domain members and have that access centrally defined and managed. In the following example, I'll demonstrate how to configure DAC policies in Active Directory, including defining claims and policies. In a subsequent article, I'll illustrate the procedure to define file attributes to make this all work together.
Infrastructure Pieces
DAC requires you to configure certain infrastructure components. The infrastructure required to implement claims-based authorization in Active Directory includes at least one Windows Server 2012 DC in the domain where the user resides that will use this feature, one or more Windows Server 2012 DCs in each domain that will implement claims to another forest, and a Windows 8 client (for device claims). There's no requirement for forest functional level -- that is, no need to raise the forest functional level to Windows Server 2012.
DAC is managed via the Active Directory Administrative Center (ADAC), which requires the Active Directory Web Services (ADWS) provided in Windows Server 2008 R2 and later versions. In this instance, you can see the DAC tree node in the ADAC console (Figure 2). Note that DAC doesn't require any specific forest functional mode, and only requires one Windows Server 2012 DC in the domain.
[Click on image for larger view.] Figure 2. Access Dynamic Access Control via the Active Directory Administrative Center.If you have a test environment and want to add a Windows Server 2012 domain to an existing forest, there are additional prerequisites if the root domain doesn't have a Windows Server 2012 or Windows Server 2008 R2 DC.
The DAC for claims-based authentication in Active Directory requires the ADAC, which requires the ADWS. In a multi-domain forest where the root domain doesn't have a Windows Server 2012 or Windows Server 2008 R2 DC, the Active Directory Management Gateway Service will need to be implemented. This allows the ADAC to communicate with that domain. In my lab forest (see Figure 3), the WTEC root domain has only Windows Server 2008 and Windows Server 2003 DCs. The W2k12 and W2k8R2 domains can be managed from the ADAC, and problems such as a WTEC root domain with a red flag (error) are displayed.
[Click on image for larger view.] Figure 3. Configuration of the lab forest.Note that even with the Kerberos setting enabled, the DAC node doesn't show up in ADAC. This makes sense because ADAC can't see the WTEC domain (no ADWS), which holds the Configuration container.
I installed the Active Directory Management Gateway Service and the DAC node appeared in ADAC. This installation required some prerequisite hotfixes, so make sure to read the Knowledge Base details.
To successfully run forestprep for Windows Server 2012, the Claims Configuration container should be present. Open ADSI Edit, then browse the Claims Configuration container, as shown in Figure 4.