In reading the article “Token Bloat Troubleshooting by Analyzing Group Nesting in AD” by M. Ali, it is pointed out that membership in the nesting of groups can in many cases lead to a condition where tokens carried by an identity can cause performance issues. Along with performance issues are cracks in your security when membership in a group is inherited.

These often unforeseen problems comes as a result of nesting of groups with inherited security. In most cases, the membership in these groups comes as a result of a very transient need for access to resources. In most cases, membership in a group is only needed for a specific period of time or for only a small subset of people that have a specific purpose. Those needs change and as a result, the membership should change with it.

Those responsible for managing directory services are slow to make changes, even small changes, for fear of breaking a critical business process. This becomes an even more complex matter of discovery when group membership and the existence of a group itself is buried within another group for which there may be no documentation or stated purpose.  Removal however is almost always certain to cause some pain for a percentage of these nested groups.  Nesting of groups is also for many, a hidden security risk or performance obstacle.

Nested groups do serve an important role when delegating access. Architecturally, the hierarchal nature of a nested group makes sense. It certainly solves the problem where groups of directory objects (people typically) have a shared need for specific access. Within those groups of people, it is easy to define sub-roles through other groups that gain access through inheritance.  What happens over time however, is that the clean layout of your nested groups quickly becomes messy because your business needs change and certainly, the people change in job function/role and the people themselves change.  The more complex your needs, the more challenging it can be to manage those scenarios.  Having to troubleshoot these groups is a very reactive approach.

Rather than analyzing recursive group membership in order to troubleshoot many problem scenarios that may come up, for Token Bloat troubleshooting and monitoring, misdirected distribution group memberships etc., it is best to consider a more automated method for the construction of parent groups and their children.

Imanami has a more proactive method of building nested groups.  With some added intelligence based on your business needs, you can build groups based on the dynamic changes in your organization.  The fluidity and nimbleness of your organization will not be hamstrung by your corporate directory services.

Imanami’s GroupID Automate does this through the concept of “Dynasties”.  A Dynasty is based on the nesting or grouping of groups dependent on the hierarchal nature of your business.  This could be a top-down look from a departmental point of view, managerial point of view, physical location point of view, or any other method of hierarchy that makes sense to you.  It is certainly an excellent way to resolve the accidental hijacking of a security group or distribution list. Membership of a group is based on rules you set forth. The nesting of one group within another is further defined by the hierarchal grouping as defined by business need. As your organization changes, your nested groups along with their membership dynamically change to match.

Get a free demonstration from one of our group management consultants….

get a demo