Today I want to talk a little about access tokens, because there’s a lot of confusion about access tokens out there. When are they generated? What are they for? What problems are related with access tokens? What is a bloated access token?
Okay, first things first. An access token is created whenever a security principal (e.g. user or computer) is authenticated, when, for instance, a user logs on to a computer or attempts to access a resource. This is a little cryptic, but just realize that an access token is created upon any authentication attempt.
Let’s say that you need to open a file in a public folder. Access to this public folder has been restricted (by you or another admin) to a specific group of people. So, when you try to access this folder, a check must be performed whether or not you belong to this specific group of people, or rather, whether or not you are member of the Active Directory group that has been granted access to the folder.
This check is done by evaluating the access token that was generated when you logged on to your computer. And so, in order to perform this check, your access token must contain information about your group memberships, and not only that, but about your effective, or transitive, group memberships, because access to a resource can be granted by way of group nestling.
And so an access token contains the security identifiers (SIDs) of all groups the user or computer is effectively member of (well, not all of them, but more about that later).
In case you’re wondering why I’m saying ‘user or computer’: access tokens are also generated for computers. Microsoft is not very straightforward about this, but given that the Computer SchemaClass object inherits from the User SchemaClass, and that both use the same auxiliary securityPrincipal SchemaClass to generate a security principal, the access token build up and limitations for computer and user objects are identical.
The problem with access tokens is that they can only reach a certain size. An access token can only contain 1,024 SIDs (or, for the nitpickers amongst you, +/- 1,024 SIDs, because not all SIDs are the same size in bits, and a bloated token actually constitutes a buffer overflow problem). So, if a user or computer is effectively member of more than 1,024 groups, the access token becomes bloated, it’s creation fails, and consequently, authentication fails. If you’re lucky and are trying to log on interactively (i.e. logging on to a computer), you’ll see the following popup:
ERROR MESSAGE: The system cannot log you on due to the following error: During a logon attempt, the user’s security context accumulated too many security IDs.
If you’re not so lucky, and are NOT logging on interactively, but are instead trying to read your webmail for instance, you don’t see a popup. Authentication simply fails, and you are left to your own devices…
So, +/- 1024 SIDs, that’s the absolute limit? No. Actually, it gets worse. When logging on to Kerberos enabled IIS websites, or certain VMware platforms that use Active Directory Authentication, token encoding and HTTP header limitations come into play, leaving less room for SIDs, and so token bloat can occur beyond 200 SIDs (!!!).
Now’s the time to list which SIDs are actually included in an access token:
Note that computer local groups are included in an access token, which is why someone might be able to log on to one computer, but not to the one standing next to it.
Given which SIDs are added to the access token, there are three common ways in which the access token limit is exceeded:
It is our impression that access token problems are increasing. That shouldn’t be a surprise. Back in the NT 4 days, being effectively member of more than 1024 groups was quite an accomplishment. But nowadays, so much is integrated and handled by Active Directory, and forests can become so large that the accumulative number of memberships is, on average, gradually rising.
We have integrated access token calculation into ADUC AdminPlus. You can calculate the access token of individual users and computers, in which case you can see the origin of each SID in the access token, or you can calculate the access tokens of any set of users and computers via ‘ViewAdd/Remove Columns’… We have included the following, generated attributes:
Basically, this functionality allows you to scan your AD for users or computers that are on the verge of authentication failure due to bloated access token problems.
Vision It has been developing custom software solutions since 2009 and launched aducADMIN+ in 2010 to help us save time and money managing our own networks.
Developing software out of amsterdam, The Netherlands with installations in over 50 countries around the globe.