Creating dynamic nested Active Directory 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 AD groups for each location, department, and manager; all the information is in Active Directory so make them dynamic. A few simple clicks and BOOM! you have accurate nested groups.
If you add a new office location, it will automatically show up. If Jane Doe gets promoted and has 3 new direct reports, her mini-organization gets its own distribution list. If you re-organize all of your departments, the new structure is automatically created and accurate. It’s that simple, as illustrated in this video demonstration.
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, 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.
With Imanami GroupID, when you are creating that dynasty, create it as a distribution group. It will create all of 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.
One note of 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.