- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
- Understanding Azure service accounts - Fri, Mar 31 2023
Prior to Windows Server 2012, Windows systems administrators relied only upon shared folder and NTFS permissions to secure file server resources. Even in the presence of AGDLP access authorization best practices, this security scheme is far from flexible.
Dynamic Access Control (DAC) is a brand-new feature in Windows Server 2012 that uses claims and resource properties to empower domain administrators to set authorization rules based upon condition logic.
A simple example
Consider this fictional but nonetheless real-world scenario:
Your company’s IT department is subject to various industry and governmental regulations that require you to track file server resource access as closely as possible.
For instance, you have a file server named XERXES that hosts a shared folder named CORP_DOCS. The confidential files in that folder should be accessible only to Nashville campus employees who possess a level 1 security clearance and are accessing the files from Nashville-based computers.
How in the world could you attain this goal by using shared folder and NTFS permissions? The short answer is that we can’t: traditional access methods in Windows are not flexible enough.
The good news is that DAC was built to address scenarios precisely like this one. We can even leverage the advanced auditing capabilities built into Windows Server 2012 to track the access per our compliance requirements.
How does DAC actually work? Let’s discuss that now.
The “Bird’s eye” perspective of DAC operation
DAC operates on user/device claims and resource properties. Claims are user or computer attributes that are (a) based upon Active Directory schema attributes; and (b) extensions to a user or computer’s Kerberos security token. A new-ish technology called Kerbero Armoring is responsible for these account token extensions.
Thus, in our fictional example, we could create the following DAC claims:
- User: Location
- User: Security clearance
- Computer: Location
If the Active Directory schema doesn’t contain the property you need, remember that you can always extend the schema to accommodate the new property.
On the file server side of the fence, we create and deploy resource properties to add semantic meaning to our shared folders and files. Think of a resource property as a metadata tag that will eventually be associated with a user or computer property.
In our current example, we could define a resource property called Confidentiality that contains the following values: Low, Medium, High. We can then classify our folders (as well as individual files) by marking their confidentiality level.
In Windows Server 2012 file services, you can automatically classify file server resources by using the updated File Server Resource Manager (FSRM) console. For instance, you can schedule a scan of target folders that parses file contents for the presence of a string such as “Company Confidential.” Files that are picked up by the classification scan can be tagged and even encrypted with Active Directory Rights Management Services (RMS)> The FRSM console is shown in the following screenshot.
File Server Resource Manager - Classification Properties
We use PowerShell to deploy resource properties to your domain’s file servers.
The third side of the DAC pyramid is the Central Access Policy (CAP). A CAP consists of one or more Central Access Rules (CARs) that define resource access based upon conditional statements. These “If/then” arguments effectively link user/device claims with resource properties.
We use Group Policy to deploy our CAPs to the domain.
Of course, DAC setup requires several steps in addition to what I’ve defined here. Here is a Visio diagram that I whipped up to show you the relationship between claims, resource properties, and central access policies.
Dynamic Access Control schematic
How do I configure Dynamic Access Control ?
In the next four posts I will present a full clickthrough procedure for DAC configuration. However, allow me to give you the heavily abridged version today:
- Install and configure your Windows Server 2012 file servers
- Use Active Directory Administrative Center (ADAC) to define claims, resource properties, resource property lists, central access rules, and central access properties
- Use PowerShell to deploy the resource property lists
- Use a GPO to deploy the CAPs
- Use manual or automatic classification on your file server resources; use the FSRM console to perform automatic classification
Dynamic Access Control setup page in ADAC
No doubt about it: Dynamic Access Control is a beast of a topic. Regardless of your prior Windows systems administration experience, all of us have a learning curve to burn through when learning this new technology. In my opinion, however, DAC is a fantastic feature that truly makes it easier for us administrators to maintain compliance and ensure “least privilege” access to our organization’s file system resources.
In my next post I will have explain how to configure DAC claims.
Want to write for 4sysops? We are looking for new authors.
what a great explanation! thanks! what is the required functional level to add DAC !
Forest functional level should be 2012, however with additional setup it is possible to set this up on an 08 R2 domain. Obviously, at least one Server 2012 Domain Controller is necessary.
The confidential files in that folder should be accessible only to Nashville campus employees who possess a level 1 security clearance and are accessing the files from Nashville-based computers.
How in the world could you attain this goal by using shared folder and NTFS permissions?
Why all the timeconsuming configuration in DAC
put those employees in a group Nashvillecampuslevel1 and give them RW to that folder
no harm done with ntfs