One of the tricks of Active Directory management is the fine balance between usability for end users and performance. A great example of this is the usability of security groups. Active Directory security groups are an excellent tool for granting access to network resources. You could be tempted to load up a user with security group membership for every possible resource they might need to use.
But this idea would come with side effects. Token bloat is a fairly serious issue affecting login performance. The token includes the SIDs of all AD security group memberships for a user, including nested groups. The token can hold a maximum of approximately 1,015 SIDs and as the number of security group memberships approaches that number, it can lead to significantly increased login times as AD tries to resolve all of those permissions.
And it is fairly easy to accumulate security group memberships. Remember that users will always tell IT what permissions they need but very rarely tell IT when they no longer need that access. I like to picture security group memberships as keys. On your first day on the job, you are given 5 keys for things you need to do your job. But then you get promoted and get 3 more keys. Move offices and get 2 more keys. Pretty soon you look like a New York super with a 10 pound keychain weighing down your belt.
So how do you solve this? Diligence? Don’t answer the phone when someone takes forever to log in? Ruthlessly delete security groups and memberships? That might work until the first time the CFO needs to get to that file that he only uses once per year.
But there are some best practices for security group management:
- Do not allow groups that have less than 5 members (or some other arbitrary number). This keeps the number of insignificant groups down.
- Dynamically manage security group membership. If a user moves from the Pensacola office to Tallahassee, you shouldn’t have to do anything manually; instead have group membership controlled by a dynamic query that will see that change in AD or some other accurate data source and automatically take the user out of the old group and put them in the new one.
- Expire and delete old unused groups. Since it is very difficult to track when security groups are being used on a large scale, have a process where group owners have to renew their groups every 6 months. If the group is still being used, renew it. If it is not, let it expire. Never go straight to a deleted state as you may need to renew the group and the permissions will be lost if deleted.
Reducing group glut and old group memberships will significantly reduce the effects of token bloat for all but your most access-hungry users. Using groups wisely will give you all the benefits of group management without the bloating and discomfort.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.
Hi Edward,
Nice post – thanks! Indeed, token bloat can be a serious issue and your advice is right on the money!
By the way, if you happen to know of any free AD Reporting Tools that can help enumerate nested group memberships, I’d appreciate you letting me know.
I run a blog on Free Active Directory Reporting Tools, and I would be happy to consider reviewing any tools you could suggest.
Thanks alot, and nice work!
Cheers,
– Marc
Great article. As a continuation to this article, the reader may find microsoft azman , can be used to circumvent the token bloat situation.