How to manage permissions with Active Directory (the right way)

How do most people use Active Directory groups to manage permissions?  You probably already know the answer: Global security groups. For example, if there is a directory on the file server specifically for “Payroll,” then we normally see folks creating a Global security group that corresponds to “Payroll,” populating that group with the users who make up that department or function, and then assigning permissions from there.

But this can get confusing, because in some circumstances, another person from some other department, or the President or CFO say, may require access to certain resources in this folder. So now, the Payroll Global group contains all the usual Payroll members, as well as that other guy (or gal).

To avoid these situations, and for other reasons that will become apparent shortly, there is another way to organize permissions, which is much more efficient. And that way is:

• Global groups = sets of people/individuals (e.g. Finance Department, Human Resources)
• Domain local groups = resources on the Domain (e.g. file shares, data access)

I’ll give you a practical example of this. In many organizations, there may be some subsets of data that are considered particularly sensitive, because they contain ePHI (electronic Protected Health Information), or PII (Personally Identifiable Information), etc. This might include Social Security numbers, medical information and history, and other personal data.

If you have a directory like “Finance” (which probably contains a fair amount this type of data) then you might feel tempted to put the members of your Finance department into this group, and grant them access to the folder using that group. But instead, you should do this:

Create three Domain local / resource groups to manage access to this resource:

• Finance Share Read-Only (Domain local group)
• Finance Share Read-Write (Domain local group)
• Finance Share Deny (Domain local group)

Then, you can populate each of the above groups with other groups (of individuals), such as:

• The Finance Department (Global group) goes into Finance Share Read-Write
• Certain other users (individuals from the Management team) might also be included in the Read-Write membership for the Finance Share
• Board of Directors / Governors might have membership in Finance Share Read-Only, or maybe an auditor occaisionally joins this group, for instance
• Other departments such as Admin, Operations, HR and so forth might be included in the Finance Share Deny group

Why do it this way?

Well, one of the main benefits is: Active Directory becomes a “one-stop shop” for managing permissions and for reporting–it is quick and easy to determine who has what access, simply by browsing the Domain local groups. Furthermore, when someone temporary comes in (e.g. an auditor), you have more flexibility in granting & restricting permissions. A typical Finance user might have more access than you’d like to see the auditor have–including certain directories that you may even want to Deny to the auditor. But you can still give them temporary read access to the Finance share on your file server, simply by using that Domain local group.

Another benefit is that you never have to go onto a file server or other network location and manage permissions/Access Control Lists (ACL’s) on the items themselves. All such resources would be setup exactly once with corresponding groups for Read-Only, Read-Write and Deny. After that, all your management takes place through Active Directory Users & Computers.

In order for this to work correctly, you need to ensure that every resource on the domain has its corresponding Domain local groups. I would furthermore add that all other memberships on the ACL’s of local resources be removed. They can be added back to the Domain local group easily enough.

And that’s it.

You probably thought this post was going to be about something more advanced like claims-based authentication. Sorry to disappoint. It’s true: claims add a powerful abstraction layer, wherein a subject can make a certain set of statements (claims) about itself, and is issued a token based on said claims. So for example: Jim signs in on his corporate-issued laptop and is granted full network access, but when he signs in using the same credentials from his personal iPad, that access is more restricted. Why? Because the statements / claims being made during the authentication process include not only identity (username) but also device type.

This capability of providing a claims-based authentication is indeed available in Windows Server (one of its lesser-known features), but it is important to remember that claims aren’t for everyone, and they aren’t always necessary. And since I don’t even see the traditional tools being used well yet, let’s not get ahead of ourselves! Maybe we’ll revisit this topic another day.