If you were to ask what’s the most difficult part of managing Active Directory groups, we’d probably get a few different answers. Probably very few of you (if any at all) would focus on the actual creation and maintenance of the groups, while most (again, if not all) would focus on the issue of where that group has permissions.

Think about even simple permissions with Active Directory itself. You can use the Delegation Wizard to assign intricate permissions easily. But it’s after you press the Finish button in the wizard that you realize, “Wait a second…. What were the permissions I just assigned again?”
And there’s no easy way to go back and see the assignment you just made. So, when it really comes down to it, unless you documented what you were assigning, you probably have only a vague idea of what was assigned.
If you go outside of Active Directory into the file, database, email, collaboration and other servers where you can easily select an Active Directory group and give the group some application-specific permissions, you’ll quickly realize that if you were pressed to tell senior management exactly where a group had permissions, you wouldn’t be able to answer the inquiry without a ton of work. In fact, in a recent Imanami survey, 32% of IT pros stated they’ve actually never validated group permissions… ever.
So, what’s the real issue here? Is it permissions gone wild? Or is it something more fundamental?
Getting to Know Your AD Group Security
We all know there isn’t an IT pro anywhere who’s actually eager to assign permissions. So, it’s got to be something more about how permissions get assigned than when they do.
The problem revolves around ownership. In some ways, you can think of ownership as the account found in a group’s Managed By value. But in reality, ownership is really about how IT looks at managing groups over the life of a given group.
In a true Group Management Lifecycle, Active Directory groups require 3 ownership roles be fulfilled:
- An owner of the group itself
- An owner of the group’s members
- An owner of the group’s permissions
These can be the same person, different people within the organization, or something in between. In most cases, the three owners are different people. The owner of the group is a line of business owner who attests to the groups necessity. The owner of the membership is someone close to the application or resource the group will provide access to. And the owner of the permissions is someone a bit more technical who can verify what permissions to which applications and data are necessary.
It’s important to state that simply having owners won’t solve the “you don’t even know” problem. After all, anyone can still select the group from a list within an application and give it additional rights. But by having owners, the IT organization as a whole elevates its thinking about groups and the impact they can have on security, lowering the likelihood that someone within IT will assign new permissions without going through the proper channels.
True owners will want some level of process and approvals to ensure the aspect(s) of the group they are responsible for are as they’ve deemed appropriate. This gets you far closer to the right way to manage Active Directory groups.
So, don’t settle for the shrugging of shoulders when you ask about the state of security and your Active Directory groups. Take control through establishing owners and begin the journey of progressing from simple group management to group lifecycle management.
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.