Active Directory security groups play a vital role in most organizations today, but there is a lot of confusion about them. Today, I am going to explain exactly what Active Directory security groups are, how they work and how they can be used to improve Active Directory security.
What are Active Directory security groups?
The concept of a security group has been with us for nearly as long as the multi-user computer. Fundamentally, the purpose of a security group is to collect user accounts into a single object in order to simplify permissions management: Instead of having to maintain a separate set of rights for each individual user, IT admins grant a certain set of rights to a single object — the security group — and those rights flow through to all the users who are members of the security group. As a result, provisioning of new users is much easier; simply add the user to the appropriate security groups and they are well on their way to productivity. Similarly, users who change roles can be reprovisioned quickly and accurately simply by adjusting their group memberships.
Active Directory security groups are simply Microsoft’s implementation of security groups in Active Directory.
That’s all pretty straightforward, so what about security groups could possibly merit a whole blog post?
Well, over time, IT infrastructures have become considerably more complex, and security groups are no exception. To secure your Active Directory environment and provide a solid user experience, it’s important to have a deeper understanding of Active Directory security groups. Let’s dive in.
Caveat: Azure Active Directory security groups, while often “integrated” via Azure AD Connect, work and behave quite differently than Active Directory security groups, so the information in this post is not necessarily applicable to them.
Types of Active Directory groups
Let’s start with at a high level and then zoom in. There are two basic types of groups in Active Directory: security groups and distribution groups. We’ve already seen that security groups are used to assign permissions. Distribution groups, in contrast, are usually created to expedite sending email messages to sets of users (though mail routing attributes are not required for distribution groups).
Structurally, however, security groups and distribution groups are actually the same class of object. Indeed, it is possible to change a group from a security group to a distribution group (or vice versa) simply by modifying it in Active Directory Users and Computers (ADUC).
The basics of Active Directory security groups
Now let’s dive into Active Directory security groups. Active Directory security groups are objects that live in a container in Active Directory. These objects have an attribute called member, which lists the distinguished names of other objects, such as users accounts, computer accounts, service accounts and other groups. (Remember that last one, as it will be important later).
Note: In the rest of this post, I will be referencing users primarily for brevity, but the information is just as valid for a computer or service account that is a member of an Active Directory security group.
When a user authenticates with an Active Directory domain controller, its membership in all groups (and all groups that are members of those groups) is calculated and written to its security token. When it later attempts to access a resource, that security token is referenced to see whether access should be allowed.
Security group subtypes
Every security and distribution group is sub-classified as Global, Universal or Domain Local. For security groups, the differences between these subtypes have to do with how the groups function in multi-domain forests. The easiest way to show the differences is in a table:
You might be wondering, why do these different subtypes exist, since the Universal group type has pretty much all the capabilities of the other two?
The answer has to do with the fact that Active Directory is old enough to drink alcohol, having been released with Windows 2000. There were two constraints that were an issue back then, though they are much less of an issue now:
- Replication bandwidth — Universal groups are replicated to all Global Catalogs, which increases replication traffic (though not enough to matter for modern networks).
- Token size — There is a limited amount of space in a user’s Kerberos token, and bad things happen when that limit is exceeded. Universal and Domain Local groups take up to 40 bytes of token space, while Global groups take just 8 bytes. However, with the advent of Windows Server 2012 and Windows 8, Microsoft increased the default token size to 48,000 bytes and added SID compression, which largely solved the so-called “token bloat” problems.
How security groups are used to improve security
We have already briefly touched on this, but it’s time to tackle it head on: How do Active Directory security groups work to actually secure things? This is a good question, and the answer to it also answers some of the most common questions about how security groups work in practice:
- Can I determine whether a security group is used and, if so, by what?
- If I am removed from a group, why do I still have access to the resources it secured? If I am added to a group, why don’t I immediately get access to the resources it secures?
The somewhat simplified answer to all of these questions is this: A user’s security token is used for all security evaluations. When a user makes an authentication request, that user’s membership in security groups and nested security groups (but not distribution groups) is calculated, and those values at that time are written to the user’s Kerberos security token.
Then, when a user attempts to access a secured resource (say, a folder in a file system), the operating system checks the security token against the Access Control List (ACL) that is written on the folder. If the user has an entry in their token that corresponds to the ACL, they get whatever level of access is defined in the ACL. If they don’t, they are denied access.
Notice that at no time during this process does the file server query the group itself. It doesn’t need to — the group was queried by the user’s authentication process. This is why it simply isn’t possible to see whether a group is being “used” to provide access to anything from the perspective of Active Directory. If the group has members, it is being “used” every time that member logs on to the network. Whether any resource is actually looking for that group’s security identifier in the user’s token is something Active Directory has no visibility into.
Second, note that the enumeration of security groups happens during user authentication. This is why it isn’t uncommon for users to be able to access resources after they have been removed from a group, at least for a while — the user still has a valid ticket that says they are a member of that group, and unless their authentication is revisited, they can continue to use the group’s security token. The default lifetime for a Kerberos ticket in Active Directory is 10 hours.
This is also the reason for the “Please log off and log back on” (or “lock and unlock”) directives when granting new access; both of those activities cause the Kerberos token to be refreshed.
Reduce your AD attack surface.
Something new in Active Directory security groups
Active Directory security groups haven’t changed much over the years. However, with the privileged access management (PAM) features in Windows Server 2016, Microsoft enhanced its security groups with an interesting and valuable new capability: time-based group membership.
When this feature is enabled within an Active Directory forest, it is possible to add a member to a security group with an additional property: Time-To-Live (TTL). In that case, the user account is a member of the group only until the time specified in the TTL property expires; then it will be removed. This approach is ideal for privileged access that is granted through security groups — since the privileged access is short-lived, the powerful account is a less tempting target for attackers.
The TTL feature also offers another benefit. As we have seen, a user can retain access even after they have been removed from a group because their Kerberos ticket might still be valid. But when a user is assigned membership in a group with a TTL, the expiration of their Kerberos token is synchronized with their expiration from the group. This means that as soon as Active Directory no longer considers them a group member, their token will be forced to refresh, which updates it with the new list of groups.
Parting words
As you can see, Active Directory security groups play a critical role in controlling access to your vital systems and data. Therefore, understanding how they work is essential to strengthening Active Directory security. In particular, using the TTL property can help you reduce the risk associated with long-term privileged access, which is a top attack vector today.
