Dynamic Access Control – ACL evaluation

So – here’s another rambing about Dynamic Access Control. It looks like this is becoming one of my favorite topics these days. Or it’s just that  I think it needs the attention. You decide yourself.

Today, I’d like to introduce the process of ACL evaluation on files and folders when DAC is used with them. Things change a little and I thought it’s worth writing about it so you know what to expect when designing your access control with DAC.

So how are ACLs evaluated when DAC is enabled? Essentially, an Access Control List comprises of a number of Access Control Entries (ACEs). An ACE describes the kind of access a security principal gets on a particular object, in our case on File Resources, like in these two examples:

ALLOW READ ACCESS for members of security group CONTOSO\finance [for this folder and all subfolders]

ALLOW READ, WRITE ACCESS for members of security group CONTOSO\finance-admins [for subfolders only]

Based on these ACEs, the ACL is created upon which access is controlled. Once a user comes along, trying to access our object, their access token with all SIDs of all groups they are member of is inspected. What happens is, if there is a match with one of the user’s groups (or the user itself) and an ACE, the specific access is granted and the rest of the ACL is inspected. All matching ACEs are cummulated and access is constructed of the cummulated matching ACEs:


That’s pretty much how I guess you know things were working. With Dynamic Access Control, the evaluation of access changes slightly. In addition to the static ACL, there is a portion of ACEs that are evaluated during access – and based on criteria that the user brings, access is allowed or not. This “access is allowed or not” decision is based on conditional ACEs, that are added to the ACL or not – on the fly, while a given user accesses a file share.

These conditional ACEs are created with Dynamic Access Control and can be based on criteria like Active Directory attributes, group membership, target resource attributes and the like. You’ll have to dig into Dynamic Access Control to find out more. There are excellent resources about DAC, see http://technet.microsoft.com/en-us/library/hh831717.aspx, http://blogs.technet.com/b/windowsserver/archive/2012/05/22/introduction-to-windows-server-2012-dynamic-access-control.aspx and http://www.frickelsoft.net/blog/?p=295. In the following example, the condition is "Does the user’s employeeType attribute contain any of ‘FTE’, ‘Full Time’ or ‘Full Time Employee’?”


Based on these conditions, one or more conditional ACLs can be added to the ACL. Sounds easy? Yeah – but there’s a catch. Once Dynamic Access Control is used and a “Central Policy” is deployed to a file share, not the cummulation of static ACEs and dynamic ACEs counts, but the combination of them. Only when static and dynamic ACEs allow certain access, access is granted. Here’s another example. The dynamic DAC-components from Group Policy on the right:


So this means that, the static ACL is evaluated and in a next step, the dynamic ACL is evaluated. The resulting set of access is NOT a combination of the two (whatever “static” says PLUS whatever “dynamic” says), but a logical AND of the minimum set of permissions that both ACLs grant. Permissions that are only granted by one of the lists aren’t authoritative. Both static and dynamic Access Control Lists must reflect and allow an access right such that a security principal can access it.

So this is the main change that we see with Dynamic Access Control there. This understand is enforced when you use the “Effective Access” tab. The “Effective Access” tab will outline what kind of access a user has and what their access is limited by. It will show you if its the Static ACL (“File Permissions”) or the Dynamic ACL (in the picture below, the Access Rule is “Lock Down Policy”) or both:


No Comment