- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
The scenario ^
The following figure graphically illustrates the simple, real-world scenario upon which we base our study of DAC:
Our Dynamic Access Control scenario
We have three computers in our test network:
- DCNUGGET: Windows Server 2012 domain controller
- MEMNUGGET: Windows Server 2012 file server that will host DAC-protected shared resources
- CLINUGGET: Windows 8 client computer
In Part 2 of this series, we configured the CORPDOCS shared folder on MEMNUGGET that holds the target resources in question. We also created the two user claims for user location and department.
In Part 3 we created classification tags, deployed them to our file server, and attached the necessary metadata tags to the CORPDOCS folder.
In this article, we will combine user claims and file resource properties into a Central Access Policy, or CAP.
But first, a tweak to our configuration
Before we create our Central Access Policy, I’d like to briefly revisit our configured claim types. In my experience using DAC, I find that the technology works better when you pre-populate your claims with valid values.
As you can see in the following screenshots, I created suggested values for both the Location and Department claims.
Pre-populating values for our Location claim type
Pre-populating values for our Department claim type
Just for good measure, make sure to run the Update-FSRMClassificationPropertyDefinition PowerShell cmdlet on your file server and verify that the CORPDOCS shared folder is correctly classified.
With that cleanup out of the way, let’s go ahead and create our Central Access Rule.
Creating a Central Access Rule ^
The Central Access Rule, which we’ll abbreviate to CAR henceforth, serves two important functions:
- Scopes an access control list to specifically classified (tagged) resources
- Authorizes users based upon their claim types
Open the Active Directory Administrative Center, expand the Dynamic Access Control node, click Central Access Rules and select New > Central Access Rule. I show you my completed CAR in the next screenshot.
A completed Central Access Rule
First, provide a meaningful name (annotated as 1 in the screenshot above). Second, go to Target Resources and click Edit (annotated 2 in the screenshot).
In the Central Access Rule dialog box, click Add a Condition to open up the expression editor. If you see what I did in the screenshot above, you know that I’m scoping this CAR to apply to resources that are tagged with Campus=Nashville and Classification = Confidential.
CARs are expression-based
Next, scroll to the Permissions are and select Use following permissions as current permissions. The proposed permissions option allows you to stage and test permissions before releasing the CAR to production.
Click Edit to open the Advanced Security Settings dialog box. Here, click Add. Click Select a Principal and add the Authenticated Users special group (it’s Microsoft’s best practice suggestion to target Authenticated Users here, although you can do what you want).
Check out the next screenshot to see the conditional expressions I used for our test environment. What my permissions entry says is “Grant Modify permission to any authenticated users who reside in the Nashville office and work in the RD department.”
What’s awesome about this conditional expression is that any new employees who meet those criteria will automatically get picked up by this access control list.
Expression-based access control list
Creating a Central Access Policy ^
The Central Access Policy, or CAP, is the deployable unit for DAC access control, and consists of one or more CARs. Back in the Active Directory Administrative Center, navigate to the Dynamic Access Control Node, double click Central Access Policies, and then click New > Central Access Policy.
Give the CAP a name, and click Add next to Member Central Access Rules to associate your CAR with this CAP. I show this interface in the screenshot below.
Building our Central Access Policy
Deploying the Central Access Policy ^
We use Group Policy to make the CAP available to our domain file server(s). Whether you create a new GPO or edit an existing one is completely up to you. In a nutshell, we need to configure the following Group Policy elements:
- Computer Configuration/Policies/Windows Settings/Security Settings/File System/Central Access Policy. Right-click, select Manage Central Access Policies, and add in the CAP you created earlier. This interface is shown in the screenshot below.
- Computer Configuration/Policies/Windows Settings/Security Settings/Advanced Audit Policy Configuration/Audit Policies/Object Access. Enable Success and Failure auditing for the Audit Central Access Policy Staging and Audit File System policies.
Configuring DAC with Group Policy
Make sure to adjust the security filtering of your GPO such that it applies to your file server computer accounts.
Next, edit the Default Domain Controllers GPO and navigate to Computer Configuration/Policies/Administrative Templates/System/KDC. Enable the KDC support for claims, compound authentication and Kerberos armoring policy, and set it to Supported.
Close out of everything, fire up an administrative command prompt, and issue gpudate /force to propagate your new GPO settings.
Assigning the Central Access Policy to Your File Server
Connect to your target file server, locate your shared folder, and examine its properties. Verify that the resource properties are set correctly, as shown in the next screenshot.
Verifying resource property tagging
Next, navigate to the Security tab in the folder’s Properties window and click Advanced. In the Advanced Security Settings dialog box, switch to the Central Policy tab. As shown below, we can assign our new CAP to the folder.
Assigning a CAP to a shared folder
If you followed the steps I provided in this series, then we have all the Dynamic Access Control infrastructure in place. The only thing that is left to be done is to test access to the CORPDOCS folder. We’ll do that in Part 4.