Without question, the one major new capability that you will have to
get to know at some time or another—and no matter how big or small the
infrastructure—is Dynamic Access Control (DAC).
DAC provides rich, centralized control over data and user permissions through various mechanisms,
including expression-based access conditions (i.e., if
x condition is met, then access is granted),
centralized access policies, and centralized auditing.
The reason DAC is so significant is because it reduces many of the
pain points that arise when you’re trying to deploy, manage, and keep the
reins on permissions throughout a Windows forest or domain. Managing Windows
permissions, as many of us know, can easily spiral out of control.
Permissions, in general, have been managed through NTFS, Active Directory, and the use of groups. In many cases,
a user who is not a member of a particular group needs access to a file in a
shared folder belonging to that group. What often ends up happening in such
cases is that unnecessary groups are created. NTFS permissions get sloppy in
parent and child folders, and keeping track of which users have access to
what data becomes an auditing nightmare. Not only do you face group
membership bloat when access permission management gets out of control, but
you also encounter the issue of security token overload. As a company grows
and more users (employees) are added, very often the number of groups
increases. Group and user increases invariably lead to an increase in
Kerberos security tokens. These tokens are created for users
and contain all the groups to which a user belongs. With Kerberos bloat,
users can experience a slow login process and myriad login errors. Inherent
properties of DAC help to reduce both group complexity and token
bloat.
Being able to audit user access and changes to data is a good practice
in any infrastructure, but it becomes crucial in organizations that are
mandated to follow compliance regulations such as Sarbanes-Oxley
(SOX) and the Health Insurance Portability and Accountability Act (HIPAA).
These are federal regulations that dictate a set of requirements for digital
data in the finance and healthcare industries, respectively. These
requirements include robust auditing and accountability mandates for IT
staff, executives, and privacy officers so they know who is accessing what
data and are able to supply reports on such activity.
Access policies and auditing aren’t new features in Windows Server,
but Dynamic Access Control is. DAC allows for complex, natural-language
statements on which to base access and auditing policies.
In addition, DAC introduces enhanced data classification. Documents
can be automatically classified based on their content. This means, as a
server administrator, you can create a rule that will classify any file that
contains parameters you specify—for instance, any file containing the words
“company confidential” can be classified as “sensitive” and automatically
encrypted using RMS (Rights Management Services).
Even with the new and improved permissions management DAC delivers,
there are still times when users may need access to a file or folder share
for which they do not have explicit permissions. There also may be issues
when existing NTFS permissions do not align with the newly deployed DAC. For
these scenarios, Microsoft has included a feature in DAC called Access
Denied Remediation. Users can request access to data that they don’t have
permissions for from the data content owner or IT department. While not
truly automated remediation (because the user has to send a request via
email, and then IT staff or the data content owner has to configure the data
appropriately), Access Denied Remediation can help reduce calls to the IT
helpdesk from users seeking access to restricted content.
The Building Blocks of DAC
There are two fundamental components of Dynamic Access Control: claims and
resource properties.
If I state, “I live in New York,” I am making a
claim. Claims have been integrated into Kerberos authentication in Server 2012. With claims, you can
identify and configure permissions for users and devices based not only on
the security groups to which they belong, but also on claims you
configure, such as, “This user’s security clearance is High.”
A resource property is a customizable label that you can apply to data to classify
it. You can create resource properties that identify a file or folder as
Sensitive, Confidential, Human Resources Group Only, or any other
properties you may need to keep data safe in your organization.
Claims and resource properties are the building blocks of DAC and
the components upon which central access policies and auditing are built. You can get
very complex and detailed with DAC, but keep in mind that successfully
deploying it begins with proper setup of claims and resource properties.
In the next sections, I’ll detail the step-by-step configuration of DAC to
get you up and running with this major new capability in Server
2012.
Requirements and Predeployment Pointers
Before testing and deploying DAC, you need to keep a few pointers in mind.
While Microsoft touts DAC as the saving grace for many IT woes, there are
problems that can still crop up with deploying DAC.
The biggest caveat is that DAC works only on Server 2012, Windows 8, and Windows RT (the tablet OEM version of Windows 8) clients. Of
course, most Windows shops already have servers, Active Directory, NTFS
permissions, and their entire Windows ecosystem in place. So what to
do?
The expectation is that most infrastructures will add in perhaps a
Windows Server 2012 domain controller and some Server 2012 file servers.
This will enable use of user claims and other components of DAC within a
current Windows environment. These server boxes don’t even have to be
physical servers; DAC can be deployed on virtual machines.
Microsoft is also offering the Data
Classification Toolkit to help deploy DAC across multiple servers
in an organization. The toolkit can implement some aspects of DAC to
Server 2008 R2.
Your biggest concern as a server administrator might be potential
conflicts between existing NTFS permissions and DAC. Even if you bring over data from,
let’s say, a Server 2008 R2 file server onto a new Server 2012 box, that
data is inheriting NTFS permissions already in place. So which takes
precedence: NTFS or the DAC controls?
There is one good rule of thumb to remember when you’re deploying
DAC into existing Windows networks: NTFS permissions won’t give more
access than a claims-based rule allows, and a claims-based rule won’t give
more permission than NTFS allows. That may look convoluted on paper, but
when DAC is deployed and configured with NTFS permissions, it becomes
easier to see that rule in action.
I would also recommend deploying DAC in a test environment with a
replication of your file servers. Again, these can be virtualized
machines. Allow time for testing how and if DAC impacts your current
security settings. When the time comes to deploy DAC, start with less
critical data. The idea of DAC is to incorporate it gradually into
existing infrastructures.
Finally, DAC can be complicated to set up. There are lots of steps
and new concepts for legacy Windows server administrators to get used to.
The following setup instructions detail fairly simple DAC deployments, but
the idea is to get you familiarized with terms and the deployment process.
Keep in mind that DAC can be used for very complex and sophisticated
access control expressions and configurations.
