Worldwide Locations
Dynamic Access Control (DAC) in Windows Server 2012 lets you manage access to documents in ways that go beyond classic NTFS (New Technology File System) permissions. For example, if you want to allow a set of users in an office across the country or across the globe read-only access to files relating to the Wind Turbine Project, DAC can do the job.
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.
DAC provides new flexibility by building on the File Classification Infrastructure (FCI) concept
- DAC uses FCI to control resource access, instead of just file management operations.
- DAC leverages Active Directory (AD) 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.
- Finally, 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.
Windows Version Requirements for DAC
I’ve seen contradictory information in the trade press regarding the Windows version requirements for DAC, so beware of overgeneralizations that you might read in MCSA test-prep books and even TechNet articles. The precise requirements depend on how you plan to use DAC. For example, you need:
- A Windows Server 2012+ file server with File Server Resource Manager installed
- A Windows Server 2012 schema (e., a domain with at least one Server 2012+ domain controller)
- At least one Server 2012+ domain controller per site, if you’re using device claims (Windows 8 clients must use Server 2012+ DCs)
- Windows 8+ clients, if you’re using device claims OR if you’re implementing “access-denied assistance”
You do not have to raise the Domain Functional Level (DFL) to Server 2012 or higher, contrary to multiple published references and blog posts! This scenario was done in a test domain running at the Server 2008 R2 DFL.