Every spring, without fail, I perform the same ritual of cleaning out the garage. I always begin the same way by taking everything out and organizing it in my driveway. I spread boxes, bikes, toys, tools, and several other odd shaped, non stackable items across my driveway to make sense of it all.
I usually start by grouping things based on what they are: Boxes of kid’s clothes go on the left, while toys and bikes end up on the right. Of course, tools, fishing gear, and camping supplies claim a prominent place in the center. And then there are boxes of Christmas decorations that somehow never quite made it back up to the attic.
As I survey everything I pulled out, I find myself asking the same questions: “Where did this come from?” “What was this used for?” “Why did I keep this?” Or if I’m lucky, “Hey, there’s that thing I was looking for three months ago.”
If I do my job well, everything falls into one of three piles: trash, donation, or items that go back onto the shelves to be inventoried again next year. It’s a difficult process, but in the end, I gain cleanliness, better organization, and precious space.
Active Directory Environments Are Like Garages
Active Directory (AD) environments can be a lot like garages. Year after year they become cluttered with groups that were once needed to grant users access to resources or send a collective email. Over the years some groups were quietly abandoned or forgotten about. Many remain simply because they were created as part of a process that no longer exists. Other groups continue to be used even though the reason for their existence has long been forgotten.
Without clear ownership and documented purpose, it’s impossible to accurately determine which groups are truly needed, and which groups can be deleted. The result is an AD environment that is harder to manage and even harder to secure, much like a cluttered garage with forgotten items and hidden tripping hazards.
Why You Need to Clean Up Active Directory Groups
It’s easy to be overwhelmed when trying to identify and clean up AD groups. One of the most common methods admins use to clean up AD is the “Scream Test” where you delete something and wait to see who screams. Alternatively, admins may be paralyzed with the fear of, “I don’t know what this is for, I might shut down a critical service if I delete it.” There are reasonable concerns that often lead to inaction.
And so, the clutter remains.
The short answer is, cleaning up old unused groups is as much about security and operability, not about tidiness.
Obsolete groups often carry shadow permissions inherited through nested memberships or old delegation settings that aren’t immediately visible. Treat security groups as a potential access point for an attacker to exploit. Obsolete groups may still be granting access to sensitive resources without anyone even realizing it. When organizations have hundreds or even thousands of unused or poorly understood groups, securing the environment becomes significantly more difficult. Obsolete groups introduce several other big problems:
- They expand the attack surface
- The clutter of unnecessary groups can obscure visibility to valid ones
- Obsolete groups can also increase the likelihood that a security incident or operational failure will have broader impact than necessary.
Additionally, AD has Kerberos token size limits. Every group a user belongs to adds data to their Kerberos authentication token. Token Bloat is the term used to describe when a user’s Kerberos authentication token exceeds the size limit because it contains too many security groups, leading to authentication failures and downtime.
Cleaning up AD groups is not just about making Active Directory (AD) tidy; it is about operational stability and enforcing security controls that ensure access decisions are intentional, understood, and aligned with the principle-of-least-privilege.
Why Group Cleanup Is Difficult
A core challenge in cleaning up AD groups is that AD was never designed to track how groups are actually used. AD lacks the telemetry required to make informed, risk-based decisions about group removal.
At its core, a group is simply an identity container. It does not authenticate, execute actions, or enforce access on its own. Access decisions occur outside of AD on servers or within applications where group membership is evaluated at runtime. While an AD group may be used to grant permissions to multiple accounts, it is always the user or service identity that authenticates and performs the action, not the group itself.
What Active Directory Knows and What It Doesn’t
AD can provide some useful details about groups. It knows that a group exists, its name, who its members are, its owner (if populated), whether it is a security or distribution group, and when it was created or last modified. These attributes can help signal when further investigation is needed, but they represent only part of the picture.
The other side of the coin is what AD does not know. AD has no awareness of which applications rely on a group, which file shares or databases reference it, or whether the group is used quarterly, annually, or as part of another process. AD has no insight into whether a group is opportunistically used by other unrelated systems across the environment.
The bottom line is that AD alone cannot provide a complete view of how its groups are used across the organization. Determining whether a group can be safely removed requires a combination of technology coupled with collaboration with server admins and application owners. Ultimately, it boils down to an informed, risk-based human decision on whether a group can be deleted.
Where To Start
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Since AD data alone is insufficient, organizations must collect relevant information from multiple sources, including:
- AD – Group inventories and metadata.
- Identity governance systems – Lifecycle events, approval history, and ownership information.
- SIEM platforms – Audit trails of group administrative activity.
- Third-party tools – Discovery of group usage across servers and applications, e.g., Quest Enterprise Reporter, Netwrix Enterprise Auditor, etc.
Even with this data, technical evidence alone is insufficient. Application owners and server administrators act as the fifth data point and are essential for identifying ongoing dependencies and processes hidden from technical tools.
Recommended Approach
A practical approach to AD group cleanup focuses on gathering evidence over time, often from multiple data sources, then consolidating the findings into a centralized view, then making progress in small, controlled steps. I recommend as a first step using PowerShell to query all groups in AD for valuable information to assist in the process. Below is a script that I used to gather initial information about the AD groups in my lab. It queries all groups and returns properties for each group that helped me determine where to start and get easy wins.
[CmdletBinding()]
param([string]$OutputCsv = ".\AD_Group_Inventory.csv")
Import-Module ActiveDirectory -ErrorAction Stop
function Resolve-ADName([string]$Identity) {
if (-not $Identity) { return $null }
$obj = Get-ADObject $Identity -Properties displayName,sAMAccountName -ErrorAction SilentlyContinue
($obj.displayName, $obj.sAMAccountName, $obj.Name, $Identity | Where-Object { $_ } | Select-Object -First 1)
}
Get-ADGroup -Filter * -Properties GroupCategory,GroupScope,ManagedBy,member,mail,description,ntSecurityDescriptor |
Sort-Object Name |
Select-Object `
@{n = 'GroupName'; e = { $_.Name }},
@{n = 'GroupType'; e = { "$($_.GroupCategory) ($($_.GroupScope))" }},
@{n = 'Owner'; e = {
$sid = "$($_.ntSecurityDescriptor.Owner)"
$owner = Get-ADObject -Filter "objectSid -eq '$sid'" -Properties displayName,sAMAccountName -ErrorAction SilentlyContinue
($owner.displayName, $owner.sAMAccountName, $owner.Name, $sid | Where-Object { $_ } | Select-Object -First 1)
}},
@{n = 'ManagedBy'; e = { Resolve-ADName $_.ManagedBy }},
@{n = 'Members'; e = { @($_.member).Count }},
@{n = 'MailEnabled'; e = { [bool]$_.mail }},
Description |
Export-Csv -Path $OutputCsv -NoTypeInformation -Encoding UTF8
Write-Host "Exported groups to $OutputCsv"
Below is a sample output from my lab:
- Start with empty groups that have no changes within a defined timespan. Those may provide quick wins. If a group has not been modified for several years and remains empty, it’s a safe bet that it is unused.
- Review groups with a clear owner and collaborate with them to determine whether the group is still required.
- For groups without a clear owner or where the owner is unsure, analyze membership patterns to identify likely departmental or technical contacts.
- Mail enabled or distribution groups can be assessed using message tracing data, keeping in mind retention limits (up to 90 days in Exchange Online; 30 days on-premises [configurable]).
- The most difficult groups, those with no owner, no description, and mixed departmental membership, require correlation across various systems including provisioning systems, SIEM data, and may require third‑party discovery tools such as Quest Enterprise Reporter, Netwrix Auditor, or Cayosoft Guardian to identify where AD groups are being used across servers in the organization.
Moving Forward
Cleaning up AD groups is only part of the solution. Without an ongoing governance model, organizations will find themselves repeating the same cleanup effort every few years. At a minimum, require the following:
- Require that all AD groups follow a clear naming convention for help with identification and usage.
- Mandate that all groups have a defined owner. Owner changes are required when the previous owner changes roles or leaves the organization.
- Require that all groups must have a description.
- Conduct periodic certification campaigns with group owners. For privileged groups, the cycle should be monthly or quarterly. Standard groups may be performed semiannually or annually.
When starting out working with group owners or potential owners, don’t ask to authorize retention or deletion of a group, thereby making the owner accept the responsibility for potential outages. Instead, ask a safer and more effective question, “To the best of your knowledge, is this group still required for your application or business process?” This encourages the owner to answer honestly, without the fear of making the wrong decision.
Owners should be allowed to say, “I don’t know.” Too often, people hesitate to admit uncertainty for fear of being blamed for making the wrong decision. This fear drives rubber-stamping during cyclical certification campaigns where they approve access or group viability not because they are confident, but because approving feels safer.
Treat certification results as input signals, not approvals for automatic action. Groups that are repeatedly marked as “unsure” should be flagged for deeper investigation. When reviewers understand that their responses lead to analysis, not an immediate deletion, they engage more thoughtfully and provide better input.
A strong AD group governance program should be about enabling safer decisions, not about forcing faster ones. By creating a process that rewards honesty, tolerates uncertainty, and separates the review process from remediations, organizations can dramatically reduce both risk and fatigue.
Summary
Cleaning up obsolete and unused AD groups is not about tidiness; it’s about security. No single tool can reliably determine whether a group is safe to delete, therefore organizations must take an evidence-based approach that combines directory information, audit logs, third-party discovery tools, and collaboration with application and server owners, culminating with informed human judgment as the final decision point. Just as important, organizations should establish a governance model that replaces fear driven rubberstamping with attestations of knowledge, where reviewers are encouraged to say “I don’t know” without consequence.
Results must be treated as risk signals rather than deletion approvals. This posture reduces fatigue, improves accuracy, and creates a safer path forward. The goal is not to delete groups quickly, but to ensure that every group has a clear purpose, ownership, and a defensible reason to exist. Third-party discovery tools, in addition to collaboration with application and server owners, replace rubber-stamping with attestations of knowledge, where reviewers are encouraged to say “I don’t know” without consequence.
If you need help with your enterprise AD environment, contact the professionals at Ravenswood Technology Group, LLC. We are here to help.
