Active Directory does an excellent job of allowing administrators to arrange their security identities in a hierarchal fashion. In a previous blog post , we discussed nested security groups which can be used to implement inherited security permissions.
Active Directory also allows you to structure your Active Directory Organizational Units (OU for short) to reflect administrative entities. OUs are purposefully designed to establish administrative delegation. An OU may be structured to reflect departmental, geographical, service type or other entities in an orderly and logical fashion. Of course, the division of objects within organizational units is dependent on the business needs of the organization that leverages them. An OU however, does not confer any security principles and users contained within an OU therefore, do not automatically inherit any permissions based on being included.
In many instances, an administrator will want to confer or design access based on the same structural principles as they have done with their organizational units. Creating “Shadow Groups” is an excellent way to accomplish this goal. A Shadow Group is a security group which carries with it, a security descriptor with an access control list (ACL). This would be a global security group that is logically mapped to an OU meaning that users in an OU would be members of the security group.
In applying this approach, you must remember that if you move a user from one OU to another, you must also update the membership of the corresponding Shadow Group.
One way to accomplish this is by developing and then using complex scripts (VBscript or PowerShell cmdlets) to build out the membership of such groups based on the users in a specific OU. These scripts can be very complex and difficult to maintain especially with ever changing business needs. To specifically include or exclude users from group membership beyond inclusion in an OU further complicates the scripts being used. In organizations where multiple Shadow Groups may be deployed, the complexity of such implementation methods makes for very problematic maintenance. Without any form of automation it gets increasingly difficult to manage over time and growth of a business.
Imanami GroupID can accomplish the goal of maintaining the membership of Shadow Groups using the same logic used to assign the user to an OU. When a user is moved from one OU to another, GroupID Automate will remove them from the membership of the old Shadow Group and add them as a member of the new Shadow Group.
To get a first-hand experience on how this works, ask to see a demonstration.
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.