If you've ever found yourself jumping through a series of ever-smaller hoops in order to design security groups and folder hierarchies that let you control file system access the way you want, Dynamic Access Control could be an eminently useful feature. The built-in Active Directory attributes and resource properties are a great start, and eventually you can create your own and build access control rules that match your needs exactly. The promise of the File Classification Infrastructure that got our attention back in 2009 has evolved into a practical reality for building almost any access control scheme you can dream up.
Dynamic Access Control in Windows Server 2012 lets you manage access to documents in ways that go beyond classic NTFS file system permissions. For example, if you want to allow Engineering department users in your Denver office read-only access to files relating to the Wind Turbine Project, Dynamic Access Control can do the job.
I. Overview of Dynamic Access Control
Windows Server 2008 R2 introduced the concept of File Classification Infrastructure (FCI): a way to permit organizations to use (and create) file properties, file property rules, and file management operations based on those rules. Administrators gained access to FCI through a new node in the File Server Resource Manager (FSRM) titled "Classification Management." FCI offered a new way of backing up, securing, restoring, archiving, and reporting on files.
FCI intrigued me, and I wrote a few posts about it in my "Network World" blog back in 2009. However, it was one of those technologies that seemed to simmer on "low," and it was rarely a hot topic in the classes I taught for Global Knowledge, or in the trade press. FCI felt a little half-baked when introduced: interesting conceptually, but short on tools and limited in its application.
Today, however, Windows Server 2012 has taken classification management to a new level, focusing on the access control aspect and given it a new acronym in the process: Dynamic Access Control. DAC is a hot topic now-you really can't get your Server 2012 certification without understanding it-and in this paper I'm going to illustrate its "nuts and bolts" by walking through a sample scenario: engineers in the Denver office aren't working on my company's Wind Turbine project anymore, so I don't want them to be able to modify project documents, just read them. With DAC, I can accomplish this without using security groups at all!
A. Limitations of NTFS Permissions
NTFS permissions let you restrict access to files by two criteria: user identity (a capability rarely used in practice) and security group membership. As useful as group-based access control is, particularly given the administrative conveniences of nesting groups within other groups ("role groups" within "rule groups"), sometimes organizations would rather control file access on the basis of other criteria: department, location, project, and so forth. In the past, we have tried to fit such criteria into the security group architecture, with results ranging from partial success to epic awkwardness. Share-level permissions don't help much, as these, too, are based on user and group identities.
B. How DAC Provides New Flexibility
DAC provides new flexibility by building on the FCI concept:
- DAC uses FCI to control resource access, instead of just file management operations.
- DAC leverages Active Directory user and computer attributes, called "claims" in the context of DAC.
- DAC lets us create file attributes ("classification properties" in Server 2008 R2 lingo, "resource properties" in DAC-speak) of our own design, or use new built-in ones Microsoft has provided.
- DAC offers the ability to build custom rules, and it uses Group Policy to make those rules available throughout the domain.
- DAC provides a mechanism for providing helpful information to users who have been denied access based on one or more of those rules.
Note that DAC does not supersede NTFS permissions or share permissions; it just provides another type of access control. Think of DAC as another hurdle the user must jump over in order to access a file.
Also note that you can use DAC with Windows security groups without taking advantage of AD user and device attributes; you would simply create central access rules and policies that leverage file resource properties, ignoring user and device claims. This would not be a bad way to ease into using DAC in an organization before taking on the additional complexity of rules and policies that incorporate user and device claims as well as file resource properties. You may be able to reduce the number of security groups you need, or reduce the number of nesting levels.