- 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
Our DAC scenario ^
The following figure graphically illustrates the simple, real-world scenario upon which we base our study of DAC:
Our Dynamic Access Control scenario
Our test network consists of three computers:
- DCNUGGET: Windows Server 2012 domain controller
- MEMNUGGET: Windows Server 2012 file server that will host DAC-protected shared resources
- CLINUGGET: Windows 8 client computer
We’re going to apply a DAC access policy to a shared folder named CORPDOCS that is hosted on MEMNUGGET. We’ll then create user claims
Configuring the File Share ^
It’s important to remember that when shared folder permissions are combined with NTFS permissions, the more restrictive permission becomes the effective permission. Therefore, as you can see in the following figure, we’ve set the Share Permissions on MEMNUGGET’s CORPDOCS shared folder to Everyone > Full Control.
Setting proper permissions for our CORPDOCS folder
We also need to recall that Dynamic Access Control works in conjunction with NTFS/share effective permissions; DAC does not replace these permissions. Thus, I set the NTFS permissions to Domain Users > Modify so we set a “high bar” for user access permissions for the CORPDOCS folder.
Creating the User Claim ^
Dynamic Access Control is a default component in Windows Server 2012, and is accessible though the Active Directory Administrative Center console. Thus, we’ll configure most aspects of DAC from DCNUGGET, our Active Directory Domain Services (AD DS) domain controller. A fast way to launch the ADAC console is to type dsac from a PowerShell prompt.
DAC in the Active Directory Administrative Center
Navigate to the Dynamic Access Control node in ADAC; you’ll find the following containers:
- Claim Types: These are user and/or computer property assertions (called claims, obviously enough)
- Resource Properties: These are metadata tags that we apply to shared folders in our infrastructure
- Resource Property Lists: These consist of one or more Resource Properties and are the deployable unit to your file servers
- Central Access Rules: These are conditional statements that allow or deny access to a shared resource (the access is based upon claims)
- Central Access Policies: These consist of one or more Central Access Rules and are the deployable unit to your file servers
Remember that user and computer (device) claims are based on Active Directory schema attributes. In our case, we need two user attributes:
- Location = Nashville
- Department = RD
The biggest trick here is figuring out which schema attribute corresponds to which target claim property. I suggest you bookmark the Windows Dev Center article User Object User Interface Mapping; this will help.
By studying that Web page, we see that we need the following claim > schema mappings:
- Location = localeID (exposed in the interface as “City”)
- Department = department (that’s easy enough)
In the following graphic, you can see a user named Jeff Gibson I created who works from the Nashville campus in the RD department.
User account properties in the ADAC console
In the Dynamic Access Control section in ADAC, right click the Claim Types node and select New > Claim Type.
The DAC user interface is pretty daunting at first glance. Study the following annotated graphic and I’ll walk you through the claim configuration.
Creating a user claim
- Type a keyword to filter the AD schema attribute list. In this case, I typed locale to bring up the appropriate localeID schema property.
- Type a friendly name to refer to the claim. I used Location.
- You can define claims for users or computers. In this example, we know that this is a user claim.
- You can pre-populate the claim with suggested values. In this case, leave this set at the default and click OK to complete the claim configuration.
Now perform the same steps to create the user claim for department. The finished configuration is shown in the following screen capture:
Our completed user claims
If you’ve worked through the exercises in this blog post, then you are well ahead of the game in terms of understanding how DAC works. In the next installment of this series, we will create Resource Properties and Resource Property Lists, and then deploy our Resource Property List to our file server.