Windows Server 2012 Dynamic Access Control (DAC) is a new authorization model that greatly simplifies management of access to information resources. With DAC, Microsoft has introduced Attribute Based Access Control (ABAC) natively in the operating system, which gives companies the ability to define policies that control access to files based on their business value and risk, by considering the classification of the data and the properties of users and devices. This white paper will review the following: - Limitations of traditional Access Control List and Group Management approaches. - How ABAC is fundamentally different - Benefits of DAC and how it's features address the limitations of ACLs - Real world use case - how to use DAC to design controls that satisfy complex industry regulations for information access and usage.

1. Microsoft Dynamic
Access Control
for IT and Compliance:
An Example Use Case
Whitepaper

2. 1
Microsoft Server 2012 Dynamic Access Control (DAC) is a new authorization model that greatly simplifies
management of access to information resources. With DAC, Microsoft has introduced Attribute Based
Access Control (ABAC) natively in the operating system, which gives companies the ability to define
policies that control access to files based on their business value and risk, by considering the
classification of the data and the properties of users and devices.
The business benefit DAC can deliver is that access control can more easily align with core business
objectives articulated at the CIO and Compliance Officer level. While DAC introduces several new
capabilities, it is also the result of strategic enhancement of pre-existing NTFS utilities, services, and
infrastructure. Perhaps the best news (at least from the perspective of IT Administrators), is that, even
as DAC expands the scope of what access management means, new features automate and optimize the
administrative work it requires. In other words, DAC provides benefits to IT Administrators and
Information and Compliance Officers alike.
This white paper presents the potential benefits of DAC in practical terms. First, this paper describes
limitations of traditional Access Control List (ACL) and Group Management approaches, and explains
how ABAC is fundamentally different. Then, this paper explains how DAC features address limitations of
ACLs, especially when access control requirements are highly complex. Finally, this white paper gives
you an example from a real-world use case: how to use DAC to design controls that satisfy complex
industry regulations for information access and usage (such as export compliance).
Traditional ACLs and Group Management
The challenges of using ACLs and groups to address complex access control requirements are familiar to
most IT Administrators. These limitations may be less familiar to Compliance Officers; however, they
probably need to care about them. Controls that are difficult to implement, maintain, and troubleshoot
heighten the risk of non-compliance with corporate and industry information control requirements. This
section describes these challenges in detail, including:
• Limitations of Container-Based Controls
• Challenges to Group Management
• Lack of Central Management
Limitations of Container-Based Controls
Container-based controls expect a lot out of IT Administrators and end users. From an IT Administrator
perspective, traditional ACL and group management can be difficult to implement and maintain.
Because ACLs are generally applied on a container, such as a folder or server, and because data and
locations that require access control tend to proliferate, organizations amass huge numbers of
containers, ACLs, and groups. IT must manage containers for each security requirement; when
requirements are complex, and when locations number in the thousands, exceptions inevitably slip
through the cracks. From an end user perspective, properly securing data requires users to know exactly

3. 2
which folder to put it in. In this discretionary model, users have to be familiar with all pertinent
information storage and sharing policies, know which policies apply to the data under question, and
know which designated container is the one they should use.
Another set of challenges has to do with the difficulty of designing controls that clearly map to
organizational and business objectives. You cannot design ACLs directly around the relevant values of
data that warrant a control in the first place. Rather, that value is rendered indirectly as location (for
example, a directory named “private” or “sensitive,” where users should store certain kinds of data).
There are several problems with this approach. One is that, while the value of the data might be
captured by a directory name, the actual value is likely far more granular and specific than what the
directory name can signify. Similarly, even when folder names accurately represent the value of data
that should be driving access control, that value is not extractable. If a file is moved to a different
location, where the correct ACLs are not applied, protection can be lost.
Recognizing this problem, Microsoft introduced its File Classification Infrastructure (FCI) with its R2
release of Windows Server 2008, as a means to identify and classify files based on their value. However,
prior to DAC, there was no out-of-the-box method for integrating classification with access control
policies (more on this later).
Challenges to Group Management
Probably the biggest challenge of using ACLs is relying on groups to manage highly complex
authorization requirements. Increasingly, complex authorizations require rules to combine multiple
identity (security) groups (for example, department and citizenship). However, previously, group
management only supported Boolean OR relationship between groups. In order to achieve an
intersection between groups, you would need to enumerate a list of relevant groups and then create
another set of groups to represent pertinent intersections between them. This results in an explosion of
the number of groups that needed to be manually created and maintained.
For instance, consider an example where an organization has an access control requirement that
involves multiple user criteria, as well as values of data, such as restricting access to resources by user
citizenship and company, and by the control level of data (“proprietary”). With traditional group
management, the only way to overlap these categories to accomplish an intersection of all three
attributes is to create another set of groups with nested subgroups (one subgroup to include members
of US group within group Project A within group High Level Security; another subgroup to include
members of Canada group within Project A within group High Level Security…and so on). In this model,
if you have 50 countries, 20 companies, and just one data criteria (proprietary versus non-proprietary),
IT Administrators have 2000 groups to create and maintain.
Lack of Central Management
Especially when access control requirements are complex, and when servers number in the dozens (or
hundreds, or even thousands), significant gaps exist between the intent of information security policies
and boots-on-the-ground implementation. IT Administrators previously lacked a centralized way to audit
all permissions deployed across file servers and/or applied locally to identify potential gaps and conflicts.

4. 3
The result was hours of troubleshooting work for IT Administrators, as well as an increase in the threat
of non-compliance with information access and usage policies.
Attribute Based Access Control: What’s the Difference?
DAC is able to address these challenges because it enhances traditional ACL and group management
with Attribute Based Access Control (ABAC). ABAC is a well-understood and documented approach for
simplifying access management, but up until now, it has not yet been broadly available in commercial
systems. ABAC is fundamentally different than other approaches to access management because access
control decisions are structured around attributes of users and resources, and these attributes are
exposed and managed explicitly.
As is discussed above, ACLs work by applying permissions to resources based on container. The concept
of location (directory name), is used to represent the actual value of data that warrants the access
control. ABAC instead evaluates the attributes of files themselves that warrant a control. One of these
attributes could be location, but other relevant and more precise attributes would be content or content
type, classification, file attribute (file type, creator, date last modified), or even a combination of these
attributes. The same is true for users: rather than managing access based only on user ID or group,
access can be managed by other pertinent attributes. Again, user ID and group could be attributes you
care about. However, ABAC allows you to also evaluate citizenship, department, project, or a
combination of these attributes. As will be explained in detail below, the result is that policy can be
highly accurate, as well as easier to manage, because you need to create and administer far fewer
Groups and access control rules.
The DAC Approach to Attribute Based Access Control
DAC can be understood a collection of features that, working together, optimize how you define and
apply information control policies to data. These features include:
• Support for Logical ANDs between Groups
• Support for User and Device Claims
• Automated Classification with File Classification Infrastructure
• Expression-Based Policies Referencing Claims and Properties
• Central Management and Deployment with Central Access Policies (CAP)
• File Management Tasks for Classification-Based Automation (such as Integration with Rights
Management Server)
Support for Logical ANDs between Groups
Using DAC policies, you can create Boolean AND relationships between multiple user and device claims
to more easily capture the intersections between them. It is no longer necessary to express this
relationship through the nesting of pre-defined groups. While this capability seems minor, its impact is
significant: IT administrators can drastically reduce the number of groups that must be managed to
satisfy complex access control requirements.

5. 4
Thank You!
Thank you for viewing a preview of our White Paper - Microsoft Dynamic
Access Control for IT and Compliance: An Example Use Case.
Request the full version of this White Paper to see:
- How Dynamic Access Control (DAC) features address the limitations
of Access Control Lists (ACLs)
- An example from a real-world use case: how to use DAC to design
controls that satisfy complex industry regulations for information
access and usage (such as export compliance).
CLICK HERE to request a copy of the full version of this White Paper.
-NextLabs
www.nextlabs.com