A lot of organizations run Active Directory Domain Services as their Identity and Access Management (IAM) solutions. Their Domain Controllers unlock access to the simplified view on the organization’s processes, structure and systems, so people can perform the jobs they were hired to do.

Now, not every organization acknowledges the importance of an up to date and lean Active Directory environment. In this series, I will show you four of the key challenges involved with managing Active Directory for any organization and how to solve them. This series will focus most on the data inside the Active Directory database, instead of the actual technical implementation of Domain Controllers and such. My first post in this series addressed stale objects and their security risks.

The challenge

Today, we’ll dive deeper into unnecessary complexity within the Active Directory database on your Domain Controllers. When I talk about unnecessary complexity, I’m mostly referring to a group structure in Active Directory where groups, organizational units (OUs) and access control lists (ACLs) were once used to mimic the structure of the organization and its systems, but where this structure has been circumvented, misunderstood and/or neglected, resulting in duplicate group memberships and improper nesting.

This type of misconfiguration leads to:

• Inability to audit (see who has access where, why and since when)
• More time needed to resolve common issues like granting or revoking access
• More time needed to get acquainted with the environment for new admins
• Deviance of Microsoft’s best practices, resulting in a higher risk of data and productivity loss
• Token bloat

Of these consequences, token bloat is the most serious.

Token bloat

Active Directory uses Kerberos v5 as one of its authentication protocols, based on RFC 1510. As part of the Kerberos authentication process, a Kerberos token is generated. This access token is created for the user containing all security groups to which they belong. These memberships will be enumerated. The group memberships are used for authorization purposes.

The amount of groups a user belongs to and sIDHistory determine the size of the access token. Since this token has to be transferred over the network and cached in memory, size matters. A smaller access token results in faster logon times and improved system responsiveness. Large access tokens will result in unreliable logon experiences.

As Microsoft has set a maximum to the size of the access token, eventually, users with many group memberships will be unable to log on. The MaxTokenSize is set to 8,00 bytes in Windows 2000 Server pre-SP2 and 12,000 bytes in Windows 2000 Server SP2+, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 and Windows Server 2008 R2, by default. In Windows Server 2012, the default value is set to 48,000 bytes to accommodate for Dynamic Access Control.

(Part of) The solution

In the case of unnecessary complexity, Active Directory should be cleaned up. However, it’s idealistic to think you and your organization can start over, design a new view of your organization and be done with it.

Optimizing communication

First of all, the root of the problem is not the unnecessary complexity, but the way this complexity was (unnecessarily) introduced by admins who were not clear with the procedures to manage objects, grant access and revoke access. Another cause might be an overhaul of the business without Active Directory ever getting remodeled to the new situation.

Before you can go and perform a meaningful and long lasting spring cleanup of the data in Active Directory, you will need to have a plan of what the information in Active Directory should look like and how to keep the information up to date. This should be captured in a design and corresponding policies with accompanying management procedures and auditing.

Tip!
Needless to say, this design, the policies and procedures should be kept up to date and thus reviewed regularly.

Mitigating factors

If you’re running into Token Bloat situations, you can opt to increase the MaxTokenSize, on all your servers and workstations, but this will only fix this problem in the short run. Communication, processes and cleanup will fix your environment in the long run. It might, however, be helpful to perform the following actions:

• Upgrade or migrate Domain Controllers running versions of Windows Server before Windows Server 2012. The improved Resource SID Compression feature in Windows Server 2012 helps reduce the size of the access token.
• Clear sIDHistory. sIDHistory is a method of retaining old SIDs and thus group memberships for access in Active Directory migration scenarios. As a result, when a user with sIDHistory logs on, the access token will contain both the information for the new Active Directory environment and the old environment.
• Limit the number of users that are configured to use trusted for delegation. For accounts that are configured to use "trusted for delegation" the buffer requirements for each SID may double.

Cleanup

With the policy in hand, you can now dig into your Active Directory and clean things up. Naming conventions for groups and accounts can be executed upon and kinks in group memberships can be ironed out.

A couple of solutions exist today to help you with Active Directory inventory and cleanup.

When it comes to group inventory, and especially the effective rights on a NTFS folder gained by group membership, the amount of available tools diminishes fast. STEALTHbits offers a free StealthAUDIT Active Directory Assessment aiming at the above issues, able to report on:

• Circular, improper and deep nesting
  In Microsoft’s best practices for Active Directory, the AGULP (Account, Global Groups, Universal Groups, Local Groups, Permissions ) principle is used to nest groups into groups. However, when fully anticipating for all Active Directory use cases, token bloat is easily encountered.
• Empty groups
  A group without members might indicate an unnecessary group.
• Direct and effective duplicate group membership
  Groups with direct of effective duplicate membership are prime targets to be consolidated. One or more groups can be consolidated based on the outcome to minimize token size and to minimize the possibility of admin adding a group or user to the wrong group.
• Stale groups
  When a group has a large percentage of members that have been inactive for a period of time, the group may be stale and thus ready for consolidation.
• Groups without a description or manager
  Documentation within Active Directory to indicate the use of a group is stronger than documentation in an (offline) manual or procedure. Descriptions can be used to identify the right group membership for the right purpose. The Managed by attribute has many uses, both inside and outside Active Directory.
   
• Groups with a large percentage of users
  Active Directory comes with built-in groups. These groups can be used to govern access within the environment. Groups with a large percentage of users might indicate the group might better be replaced with one of the built-in groups, like Authenticated Users.

The graphical output looks like this:
(only a portion of the Toxic Group Conditions report is shown below)

Unfortunately, the free StealthAUDIT Active Directory Assessment does not offer the much coveted effective rights report, showing who has access where (on File Servers, in Exchange) based on Active Directory group memberships and Dynamic Access Control. When you want this functionality, StealthAUDIT Data & Access Governance is the suite you might want. The free StealthAUDIT Active Directory Assessment, however, will give you a fair preview of what you might expect from the full platform.

An alternative solution

As an alternative to using group memberships as your access management strategy, you might opt to implement Dynamic Access Control (DAC). This new feature in Active Directory Domain Services in Windows Server 2012 offers a way to manage access to files and folders, based on attributes in Active Directory (fields like location, manager and department) and (optionally) file classification. No longer will you need to create thousands of groups to build a granular access solution. As a bonus, you can create far more robust access rules.

In contrast to group memberships, in Dynamic Access Control scenarios, access is granted based on attribute values. These attribute values result in claims. These claims are then used for authorization purposes, where filtering is done based on the combination of claims.

To migrate to an environment where authorization is based on claims instead of group memberships, the two authorization methods, most likely, need to coexist for a while. To remediate Token Bloat in this situation, increasing the MaxTokenSize throughout your environment is a good temporary fix.

Concluding

Only after you’ve created a policy and processes within the organization will you, your admins and your auditors, be able to model your Active Directory environment to your organization and enjoy easy Identity and Access Management…

Related blogposts

Common Challenges when Managing Active Directory Domain Services, Part 1: Security
New features in AD DS in Windows Server 2012, Part 20: Dynamic Access Control (DAC)
New features in AD DS in Windows Server 2012, Part 21: Resource SID Compression

Further reading

MaxTokenSize and Kerberos Token Bloat
Avoiding Token Bloat in Your Active Directory Group Design – Part 1
Avoiding Token Bloat in Your Active Directory Group Design – Part 2
Active Directory token bloat & group glut
Strategies for minimising 'Token Bloat'
Kerberos Explained