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.
Complex User-Admin - High Token Bloat
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.
Complex Resource-Admin - Less Token Bloat
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 >