Introduction
A wise man once taught me how to properly configure access control lists (ACLs), which I still preach today. However, I find that after so many years of network administration being so straightforward, that many don’t follow this easy to follow and best security practice. If users and groups are not handled correctly when granting access to resources, via ACLs, disaster is just waiting to occur on your networks. Think about it this way, if you just casually give out keys to your house without keeping track of them, how will you know in a year or two who has a key to your house? The answer is you won’t. The same sort of issue occurs on your networks. If you grant the wrong permissions to the wrong objects, you are going to end up not knowing who has access to what in a year or two. The damage that can come of this to your corporate data is nearly as bad as not knowing who has a key to your house.
First Things First
We need to understand what I mean by Access Control List (ACL). An ACL is a list of “who” has “what” access to a resource. We also need to understand what a definition of resource in a Windows environment is. Let’s assume that we have an Active Directory domain, which will expand our definition of resource. First, a resource is anything with an ACL. I know, you are to never define one term with another that is unknown. However, in this case there is not much other option. Here is a full list of objects in a Windows Active Directory enterprise with an ACL:
- Files
- Folders
- Printers
- Registry Keys
- Services
- Active Directory objects
Now, what is an ACL? An ACL is a list of users, groups, and computers with some level of access permission to the object. In order to access the ACL for an object, you need to first get to the object properties. This is typically a right-click away. Just right-click on the object, then select Properties from the menu. For example, an ACL for the System32 folder on my laptop is shown in Figure 1.
Figure 1: ACL for the System32 folder.
Note:
There are also permissions associated with Shared Folders, which are on the Sharing tab, which is next to the Security tab of the Properties dialog box for an object. These permissions related to shared folders are not in any way similar to the permissions on the Security tab. They might seem similar, but they are dramatically different.
Next, Scope of Users
There are two different types of user accounts in an Active Directory domain. There are local user accounts, which reside in the local security accounts manager (SAM) of every desktop and server (non-domain controller) in the entire domain. These users can only be located on ACLs on resources that are on the computer where the user is stored.
There are also domain user accounts, which are located on the domain controllers for the domain. The domain controllers house the Active Directory database, which is where these users are defined and stored. These user accounts can be placed on any ACL on any resource on any computer in the entire domain.
Next, Scope of Groups
There are two different types of group accounts in an Active Directory domain. There are local group accounts, which reside in the local security accounts manager (SAM) of every desktop and server (non-domain controller) in the entire domain. These groups can only be located on ACLs on resources that are on the computer where the group is stored.
There are also domain group accounts, which are located on the domain controllers for the domain. The domain controllers house the Active Directory database, which is where these groups are defined and stored. These group accounts can be placed on any ACL on any resource on any computer in the entire domain.
There are six different groups that can be created in Active Directory. The groups are defined as follows:
- Universal Distribution Group –
- Universal Security Group –
- Global Distribution Group –
- Global Security Group –
- Domain Local Distribution Group –
- Domain Local Security Group –
Any and all of the security groups that can be defined in Active Directory might show up on an ACL for a resource in the domain.
Correct User, Group, and ACL Usage
Now, we go back to my mentor who called the use of user accounts, group accounts, and ACLs a “mantra”. He was pretty clear about his use of the users, groups, and ACLs, as his main goals were ease of administration and security.
For a single domain, the ideal way to organize users, groups and ACLs is as follows:
- Domain user accounts should be placed in global security groups
- Global security groups should be placed into domain local groups (or local groups)
- Domain local groups (or local groups) should be located on the ACL
Global security groups should be defined and used to organize users based on who they are. For example, you might have groups named Managers, Engineers, Accounts Payable, etc. Domain local groups (or local groups) should be defined and used to organize the global groups based on access to the resource. These groups might be named Full Control to DB, Read access to Intranet, Modify of Documents, etc.
The reason for the mantra is that I can determine who has access to any resource by looking at the resource, then enumerating the groups that are listed on the ACL and stored in AD.
Where Things Can Go Awry
First, if users are placed directly on an ACL, you might as well be giving your house keys to strangers on the street. Imagine a typical corporation, with hundreds, if not thousands, of servers. These servers have thousands of ACLs for the resources on them. Now, you have hundreds of servers multiplied by thousands of resource ACLs… that is millions of ACLs. Now, find every instance where Joe Smith is located on each ACL! Won’t happen! Can’t happen!
Next, if you place users into local groups and then place the local groups on the ACL… again, you have an issue with documentation and referencing. If all AD groups were used for the membership of users, then you can go to any user and know exactly every group they belong to. If you place domain user accounts into local groups, you have no record of where the user has membership.
Finally, the user of local user accounts should be limited. There are certain reasons to use them, but these are few and far between and are the exception to the rule. These users are hard to manage and control, so try to use domain user accounts when possible.
Summary
The correct use of user accounts, group accounts, and ACLs is essential for a well maintained and secure enterprise. If the “mantra” of user and group nesting is broken, there is little that can be done to manage and track which resource a user has access to. However, with the proper use of users in global groups, global groups into local groups and local groups on the ACL… your life will be easier to manage, as will your Active Directory enterprise.
