Avoiding Token Bloat in Your Active Directory Group Design... After I posted that article, a colleague asked me what I thought about a group design where users are added to role-based groups, role-based groups are added to resource groups, and the resource groups are added to the ACLs of the resources. This is called a nested group design.
|Nested Group Model|
Well, it is true that user-admin will be simple, and the ACLs will be simple, but token bloat? The nested group model will actually make it worse. Quite a bit worse.
You would think this wouldn't be the case. If you look at a user in Active Directory, and look at the memberOf tab, you'll only see the short list of role-based groups listed. You won't see the resource groups that those role groups are nested in. However, the user's Kerberos token will contain both. Thus making token bloat much worse.
Behind the scenes, Active Directory runs a background process every few minutes, to evaluate nested group memberships and groups based in other domains in the AD forest, to build a complete list of groups that the user belongs to either directly or via nested groups. Then it takes the security identifier (SID) from each of those groups and stores it in the tokenGroups attribute of the user object. It is this SID list that is used to create the Kerberos token (along with the user's own SID).
You can't see the tokenGroups attribute in AD Users and Computers. You can look at it using ADSIEDIT, or using a script, but unfortunately it's stored as binary byte-arrays. So, if you want to see the complete list of groups that the user is really in, you have to write code that gets the tokenGroups attribute, converts the binary to an array of SIDs, then resolve those SIDs to group names.
Happily, I slaved over this code already, so you don't have to look far for an example. Here are examples of how to read the tokenGroups list in PowerShell and Perl.
Reading the tokenGroups Attribute in PowerShell
Reading the tokenGroups Attribute in Perl
< Page 1