The example we gave when designing the group hijacking feature for GroupID was absurd. Say you owned an Exchange distribution list designed to discuss cookbooks and somebody else owned a distribution group designed to discuss the Anarchist Cookbook…very different sets of users with most likely a very different set of discussions.
If the owner of the second group decides to add the first group into his group, he has created a nested group with the benign set of cookbook-lovers held captive to discussions that they have absolutely no interest in.
While the above example would never actually happen, it gives light to how seemingly related group names do not go together and the problems that can be caused if one group owner nests another group into his. One of our customers had this as a very real worry (the hijacking not the cookbook groups) and wanted a simple way to solve it.
Having the customer craft a complicated workflow would solve it but we realized that you don’t always need to give the customer so many tools so we did a system workflow. Simply check the box that says “workflow to nest a group” and the group owner being nested will have to approve that nesting for it to take effect, effectively ending group hijacking.
Someday I will find the customer with the “exact” cookbook problem I described above when I give that example; until then I’ll just be satisfied that every single one nods their head in agreement when I use my “bad words filter” example!
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.