Inside Kerberos – 7: Wrap up
Alright, we’ve covered a lot of ground, but let’s wrap up by grabbing our original questions and answering the
1. Why is there a problem with SIDHistory and Domain Local Groups, and exactly what is the problem?
We’ve seen that Domain Local groups can have sid-history applied from one domain to another, this allows for any resources that have been moved from the source domain to the target domain to continue to be accessed without re-ACLing the data. It also allows migrated users to continue to get the source Domain Local groups added to their PAC by the trusting domain due to the user’s or their Global/Universal group’s sid-history.
The big thing to remember is that the addition of Domain Local Groups to the PAC is done by the KDC in the same domain as the service, therefore it can only use the user’s SID or SIDs from global/universal groups to try to find Domain Local Groups or permissions in the resource domain.
The two things it does NOT allow are:
- Migrate the source data (permissioned with Domain Local Groups) to a different trusting forest without also copying the Domain Local Groups, and expecting access to still be maintained
- Adding new users to the target domain, adding them directly into Domain Local Groups and expecting sid-history to grant them access to the source data that are permissioned with Domain Local Groups
2. Why is there a 64 KB limit on tokens, and exactly what is it counting towards that size?
The Kerberos structures themselves have no such limit on the size of a ticket or underlying structures. The only place where I can assume that this limit applies is the size of the PAC which forms part of the tickets. 64 KB happens to match a single data page within a 16-bit OS… of course this could be purely coincidence…
3. Why is there a limit of 1024 groups in an Access Token and where does it become a problem?
This is again a disappointing answer, as I can find no authoritative reason for a limit of 1024 groups. The data structures do not seem to limit the Access Token in this way, so I can only assume some hard-coded limit within the LSA itself that hasn’t been changed for fear of breaking backward compatibility.
Avoiding this 1024 group limit is critical as there are few ways around it. If you have a particular resource like a file server that is causing a massive number of Domain Local Groups, then perhaps you can move that File Server to a resource domain which may give you a bit more breathing space since those Domain Local Groups are only added when traversing the trust, and it will drop any Domain Local Groups from the user’s forest in the process.
Of course the most likely culprit is sid-history, so cleaning up sid-history is not just an option, it should be a pretty urgent goal and part of every migration.
Ultimately once you hit this limit then you won’t be able to log on (unless you’re the Administrator account and are in Safe Mode) and you will get an error saying ‘too many context ids’
I hope you’ve enjoyed this multipart series on Kerberos! Let me know if you find any errors, omissions or want to chew the fat 🙂
