Avoiding Token Bloat in Your Active Directory Group Design - Part 1

Token Bloat occurs when you are a member of too many groups in Active Directory.  At somewhere around 125 groups, your Kerberos token size reaches 64kb in size.  That's the limit for a lot of things that use Kerberos authentication.  For example, if you've got VMware ESX/ESXi 4.x, and you've configured it to use Active Directory authentication, you may find that you can't log onto the vSphere client.  You may not be able to connect to Kerberos-enabled IIS web sites.  You may not be able to join a computer to a Windows 2003 domain.



That's an extreme result of token bloat.  Whether or not you've reached this limit, the more groups you have, the more data you're transferring to every Kerberos-enabled server or service that you connect to all day long.  Being a member of too many groups is just bad for performance if not the direct cause for failures in accessing services on the network.

You may think, "who is in 125 groups?!", well I'm in 320, and I saw a user recently who was in over 500.  In a large environment, things can get out of hand quickly if the wrong people are setting the standards.

Resource-Based Groups
Complex User-Admin - High Token Bloat

In my opinion, there are two fundamental types of groups: groups that are associated with a resource, and groups that are associated with a role.  Resource groups are created specifically for a resource, that is, a file share, a folder, an application, a server, or a printer to name a few.  This is the type of group that many administrators tend to create a lot of, and they eventually lead to token bloat (if your environment is large enough). 

Think about it, every time you create a file share or a secure folder, you probably create a group for that folder, perhaps more than one (one for read/write access, and another for read-only access).  You may create a group for administrators of a given server, to give the application owners admin access to their server.  

These seem like a good idea, until you have hundreds of shared folders and thousands of servers.  Before you know it, you've been added to hundreds of groups to grant you access to all the stuff you need access to, and they guy next to you that does the same job, they've added him to all those groups too.

From the perspective of your IT organization, you probably have user admin personnel who's job is to create users and add them to groups.  If you're a smaller company, these same people probably grant those groups access to shares and folders.  If you're a larger company, you may have a separate team who sets the permissions on the folders.  Perhaps the server guys do that part.  In that case, your user admin team may be made up of lesser-skilled people while your server crew is more highly skilled.  Yet, with resource-based groups, you're leaving it up to your lesser-skilled people to map users to the myriad groups you've set up.  The user to role mapping work is left in the hands of your lesser-skilled crew.


Role-Based Groups
Complex Resource-Admin - Less Token Bloat

By contrast, with role-based groups, you create a much smaller number of groups, per organizational role.  Let's say you create a group called HR Managers.  You then grant this group the appropriate rights to every share, folder and application that they need access to.  Then, when user admin sets up a new HR manager, they add the new user to the HR Managers group, and their done.  The low-skilled user admin job becomes easy.  What's difficult in this scenario is that this one group must be granted access to many resources.  This requires a lot of work and skill, and presumably your skilled people who understand permissions and server are responsible for this work.

There is of course, a drawback to this design.  If multiple roles need access to the same resource, you need to add all of the role-based groups to the access control list (ACL) of that resource.  This can lead to some lengthy and complicated ACLs.  This in itself is not good for performance.

So, a less extreme version of the single role model is advisable.  The reality is that users have more than one role.  The user may be an HR Manager (giving them privileged access to folders and applications containing sensitive payroll information), but they are also an HR Team member giving them access to additional, less sensitive HR information, and they are also a member of US Employees, giving them access to various folders and applications related to US data and services, and so on.  Each role-based group created for the purpose of granting access to a number of resources closely related to that role.

In this less extreme model, the user has a number of roles, each mapped to a number of resources.  In this scenario, the number of groups that the user belongs to is kept to a reasonable few, while the number of groups added to the ACL of each resource is also kept to a reasonable few.  You may end up creating roles that grant access to only one resource, but your should loath to do it.

Each role-based group should ideally grant access to data and applications that are largely specific to that role (e.g. HR data and apps for HR users, US data and apps for US users).  In this way, you end up with a good balance of the fewest number of groups and the fewest entries in the ACLs.  Many I wish they did this where I work.

Page 2 >