We call them Dynasties
Smart Groups are a great way of managing the membership of an individual group in a dynamic fashion. But what if you wanted to create a series of separate groups whose memberships are defined on some common criteria (for example, manager, department, location, and so on), and that criteria has some sort of hierarchy related to it? That is where dynasties come in handy.
Creating dynamic nested AD groups, what we call dynasties, is an incredibly easy way to ensure your most used and most important Active Directory groups are accurate. The premise is simple: every organization needs Active Directory groups for each location, department, and manager. All the information is in Active Directory, so make them dynamic. In a few simple clicks you have accurate nested groups.
Read more: Managing Group Memberships Dynamically
Here’s an example: Jane Doe
If you add a new office location, it will automatically show up. Say, Jane Doe gets promoted and has 3 new direct reports, her mini organization gets its own distribution list. If you re-organize all your departments, the new structure is automatically created and accurate. It’s that simple, as illustrated in this image below:
But what if you want to make them security groups, that should come with a warning — two simple words, token bloat. Because there are a lot of groups that are created in any sized organization. And because they are nested. If you are in the Tacoma group, then you are also in the Washington group, and the Pacific Northwest group, and the United States group. So, you don’t want to just make all of them mail enabled security groups.
But you might want to make some of them mail enabled security groups. It is very unlikely that the top levels of these groups need to be security groups, so the parents can be distribution groups, but the children can be security groups. This is probably most prevalent in managerial dynasties (explained in the image above), where you might want to assign permissions to just the direct reports of Jane Doe but don’t need any permissions on higher level managers.
Nested AD Groups: The Risks involved
Nesting groups does come with risks when done manually. In many cases, membership in group nesting can lead to a condition in which tokens carried by an identity can cause performance issues. Along with performance issues, you also can have cracks in your security when membership in a group is inherited. These often-unforeseen problems come because of group nesting with inherited security.
In most cases, the membership in these groups comes because of a transient need to allow users to access resources. Also, membership in a group is needed only for a specific period or for only a small subset of people who 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 are buried within another group for which there may be no documentation or stated purpose. Removal is almost always certain to cause some pain for a percentage of these nested groups, however. 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.
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.
Enter GroupID: Imanami Group Dynasties
Imanami has a more proactive method of building nested AD 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.
With Imanami GroupID, when you are creating that dynasty, create it as a distribution group. It will create all those children with that group type, and then using either the GroupID management console, ADUC, or PowerShell, change the groups (that you want) to security groups. When the dynasty updates, it will not affect the group type, keeping that setting.
Caution: You may want to set GroupID Automate to not delete empty groups so that you don’t lose the permissions. You can easily run a report or filter the empty groups to manually see if you should keep those.
The best practice is to have as few security groups as you can to accomplish your permissions and entitlement goals, this technique goes a long way to ensuring that you can create and maintain these groups simply and reliably.
Create Dynamic Nested AD Groups with GroupID
When Active Directory becomes too significant a burden to bear, it’s time to make a change. Get started with GroupID today and see how much more you could be doing with your Active Directory Groups while improving productivity.
Get your free GroupID trial here.