I mentioned last week that organizations are moving toward using single-purpose security groups, where each shared folder has a read group and a write group on its ACL, and these groups are not used to permission other folders or resources. DataPrivilege® automatically creates and helps data owners maintain these single-purpose security groups, so the additional groups don’t have to introduce administrative overhead.
However, new groups do add new relationships to Active Directory, and this ties into the topic I mentioned last week called “token bloat,” referring to growing access tokens. In a nutshell, when a user’s access token gets too big, sometimes they can’t log in to their workstations. This is a high-priority help desk call when it happens to any user—when this happens to your CEO it is definitely sub-optimal.
Why does it happen? Access tokens are created when users authenticate with Active Directory, and they store a lot of SIDs, or Security Identifiers. Each group you’re in adds a SID to your token. Each group those groups are in adds a SID to your token, and so on. SID history also adds SIDS to your token. By default, the number of SIDs your Active Directory access token can contain is 1024—if your token contains more than 1,024 SIDs, you may not be able to log in.
In addition to the obvious security benefits, this token limitation is another good reason to remove users from unneeded groups, identify and remediate deeply nested/looped nested groups, eliminate security groups that aren’t used to access any resources, and to clean up SID history. Automated recommendations and reports about these and other issues are included in Varonis DatAdvantage.
Another piece of news is that there is a registry setting that increases the size of the token, described here. We have tested this successfully and we’re curious to see how it’s working for other folks. Please email me at firstname.lastname@example.org if you have feedback.
Thanks to Sundar Ramakrishnan, who wrote a very helpful write-up, here.