Clean up unused Active Directory Domain Services groups in a single domain

One challenge many organizations face is the proliferation of groups in their Active Directory Domain Services (AD DS) domains, particularly security groups. An organization might create security groups for projects, but they're no longer needed over time. These groups can linger unmaintained in the domain.

Group cleanup reduces administration burden and risk, and it prevents sync of unused groups into Microsoft Entra. This article outlines how to analyze groups and use a scream test methodology to identify and remove unused groups from an AD DS domain. In a scream test, an administrator identifies a resource that might no longer be needed, temporarily makes that resource unavailable, and waits to see if anyone notifies the administrator that they were impacted. If there are no reports of anyone impacted, the admins proceed to clean up the resource.

First you determine whether each group needs to be managed with an AD DS-based management tool like Active Directory Users and Computers, or managed in the cloud with Microsoft Entra admin center or Exchange Online, or if it might not be needed. In some cases, the scream test indicates that a group is still required, and whether to manage it in Microsoft Entra ID or the AD DS domain. If the group might not be needed, you can run multiple scream tests to determine if it's active. If it's no longer active, you can delete it from the AD DS domain.

Types of groups in scope for cleanup

• Security and Distribution List (DL) groups in an AD DS topology, with a single forest, single domain. Multiforest or multidomain environments, workgroups, local groups on domain-joined computers, or other environments are outside the scope of this article.

• Groups with members who are users or other groups that are in scope for sync to Microsoft Entra. Groups that contain computers, contacts, or other objects as members are outside the scope of this article.

• Groups created in AD DS by using Active Directory Users and Computers, Microsoft Identity Manager (MIM), or other identity management tools. This article doesn't cover Built-in groups, or groups that get created by other products.

Prerequisites

These prerequisites must be completed before you start to remove unused groups with this approach:

• You need membership in the Domain Admins group, or similar permission to update, move, and delete groups.

• You need to be able to change the scope of Microsoft Entra Connect Sync or Cloud Sync to include or exclude groups.

• You need to create a Group Policy Object (GPO) for all writable domain controllers to enable logging of AD DS object modifications, and set up a central repository for collected logs. For more information, see:

  • Configure audit policies for Windows event logs
  • Event 5136: A directory service object was modified
  • Collect Windows events from virtual machine with Azure Monitor

• You need to enable the Active Directory Recycle Bin.

• You need to create two organizational units (OUs) in the domain – one for temporary Kerberos app scream test groups, and another for temporary Lightweight Directory Access Protocol (LDAP) app scream test groups.

Perform a group analysis for the domain

The goal for group analysis is to review and confirm which of the groups in a domain are:

• Needed for an AD DS-integrated application and managed by using an AD DS-integrated tool.

• Needed for an AD DS-integrated application and managed by using Microsoft Entra or Exchange Online, with the membership written back to Microsoft Entra.

• Potentially no longer needed in the AD DS domain, but is needed in services that are connected to Microsoft Entra, and could be maintained solely in Microsoft Entra.

• Not needed by any applications that are integrated with AD DS or Microsoft Entra.

The first step is to identify and categorize the groups in your domains that need triage. For large organizations with many thousands of groups, you need to choose an order to evaluate the groups. The order can be based on factors like:

• Group type (security group, mail-enabled security group, or distribution list)
• Group organizational unit (OU)
• Group size and membership
• Group nesting (the group is a member of another group in the AD DS domain)

Select a reasonable-size batch of untriaged groups for analysis. Based upon the type of each group, see the next sections for steps to analyze it for potential cleanup:

• Analysis for a Distribution List or Mail-enabled security group
• Analysis for a security group

After performing one of those analyses on that batch, then proceed with the next batch of untriaged groups. When all groups have been analyzed, then the scream test is complete.

Analysis for a Distribution List or Mail-enabled security group

1. See if an owner is set for the group in Exchange or Exchange Online. Contact the owner of the group to determine if the group is still needed.

2. See if the group has members. If there are no members, proceed to the cloud scream test.

3. Search the Exchange or Exchange Online logs to see if mail was sent to the group. You can use Get-MessageTrackingLog to search and analyze the logs. If mail was sent, then the group is likely still in use. Contact the senders of those mails to determine the purpose of the group.

4. See if the group members include any users, contacts, or groups that aren't synced to Microsoft Entra. If the group includes members that aren't synced, its group type isn't updated to a Microsoft 365 group or Exchange Online DL. Perform the scream test for Kerberos and the successor tests. After you finish:

   • If the group is still needed, maintain it in the domain by using Exchange on-premises, or replace it with an Exchange Online DL or Microsoft 365 group.

   • If the group isn't needed, remove it from the domain.

5. If the group is a DL, then even if the members of the group are in Microsoft Entra, the group Source of Authority (SOA) can't be converted to Microsoft Entra. You should perform a scream test for cloud usage and the successor tests. When complete, the options are:

   • If you still need the group, replace it with an Exchange Online DL or a Microsoft 365 group.
   • If the group isn't needed, remove it from the AD DS domain, and don't replace it.

   Contact your Exchange administrator to determine which option to proceed with.

6. If the group is a mail-enabled security group (MESG), then the group SOA can't be converted. Perform a scream test for cloud usage and the successor tests. When complete, the options are:

   • Replace with a Microsoft 365 group.
   • Create separate DL and security group, and process each one separately.
   • Update the group type so it's either a security group or a DL instead of a MESG.
   • Remove the group from the AD DS domain and don't replace it.

   Contact your Exchange administrator to determine if the group is still needed for Exchange purposes. If you still need the group for Exchange, replace it with a Microsoft 365 group, or create separate DL and security group, and process each one separately. Otherwise, assume that the group only needs to be a security group, or it's no longer needed, and proceed with the analysis for a security group.

Analysis for a security group

1. Review the group members. If the group has no members, proceed to scream test for cloud usage. Review the recommendations in the following table for other member object types.

   Member object type	Recommendations
   One or more Computers	Group is likely used for Group Policy or System Center administration. Contact Windows Server and System Center administrators to determine their plans for this group. You might replace it with a new approach with Azure or Intune.
   One or more Contacts	If the group is a MESG, then those contacts can't be used to authenticate to Microsoft Entra. Remove them from the group if you plan to convert the group to not be mail-enabled.
   One or more users or groups not synced to Microsoft Entra (excluded from sync scope)	The group shouldn't have its Source of Authority converted.
   Users and groups synced to Microsoft Entra	Plan to perform a scream test for cloud usage.

2. Find the change date of the group. If the group is recently modified, check the logs to determine who modified the group. The security identifier (SID) of the user who modified the group is included in the subject field of event 5136. Contact them to determine the purpose of the group, and whether it can be updated to a cloud security group.

3. Otherwise, if the group isn't recently modified, use Get-Acl to check if an access control list (ACL) on the group or its OU delegates ownership of the group. If an ACL delegates ownership, contact the owners to determine the purpose of the group.

4. Otherwise, check if another group has this group as a member, and that group has an identified owner. If so, contact the owners of that group.

5. If all group members are users and groups that are synced to Microsoft Entra, and the group has no recent changes, no clear owner, it's not a dependent of another group, then continue to the next section to perform a scream test for cloud usage.

6. Otherwise, if the group has user or group members that aren't Microsoft Entra accounts, and it's not a built-in group, then proceed with the scream test for Kerberos apps.

Once those scream tests are started for that group being analyzed, then continue with the next group in the batch.

Scream test for cloud usage

This test determines if there are users in groups that are used for cloud resources, including privileged roles in an Azure subscription.

1. First, check in Microsoft Entra if there's a reference to the group:

   • From an app role
   • From a Conditional Access policy
   • In another cloud group
   • In Privileged Identity Management
   • In lifecycle workflows, access reviews or entitlement management

   If so, then contact the administrators of that resource or service to determine how the group is used and if it can be replaced with a cloud security group.

2. See if there's a reference to the group from an Azure role in an Azure subscription, resource group, or resource. If so, contact the owners of that Azure subscription.

3. Speak with Exchange, SharePoint, Intune, Azure, and other administrators to determine if the group is needed for the administration of their services.

4. Speak with the admins of other applications in Microsoft Online Services to determine if they use the group.

5. After you determine there's no evident use of the group in Microsoft Online Services, there might be another service that wasn't evident. To detect if there's another service, proceed to the scream test steps below.

6. Change your Cloud sync or Connect sync configuration to exclude the group from being synced.

7. Wait for sync to finish and confirm the group is no longer visible in Microsoft Entra.

8. Wait several days to determine if any users complain that the group is unavailable. For example, see if anyone opens a support ticket with IT helpdesk.

9. If there are complaints, remove the group from exclusion. Identify the team that relies upon the group, and determine a plan to migrate the team to use a cloud-managed group in future.

10. If there are no complaints about the group no longer being available in Microsoft Entra, then proceed to the next section, the scream test for Kerberos apps.

Scream test for Kerberos apps

This test determines if there are apps that rely upon a user being a member of a security group, where AD DS provides to the app a Kerberos ticket that contains the group ID of this group or another group that contains it.

To perform a Kerberos scream test, follow these steps:

1. Move the group to the OU for groups in the Kerberos scream test.

2. Update the group type to a DL, so that the group is no longer included in Kerberos tokens. Alternatively, remove the members. For example, move the members to another new DL group temporarily.

3. Wait several days to determine if any users complain that the group is unavailable. For example, see if anyone opens a support ticket with IT helpdesk.

4. If there are complaints, change the group type back to a security group or add back the members. Then identify the team that relies upon the group.

5. If there are no complaints, proceed to the next section, the scream test for LDAP apps.

Scream test for LDAP apps

This test determines if there are LDAP apps that rely upon a user being a member of a security group.

1. Move the group to the OU for groups in the LDAP scream test.

2. Remove members from the group. For example, move the members to another new group temporarily.

3. Wait several days to determine if any users complain that the group is unavailable. For example, see if anyone opens a support ticket with IT helpdesk.

4. If there are complaints, restore the membership of the group, and move it back to its original OU. Identify the team that relies upon the group.

5. If there are no complaints, delete the group. The deleted group goes to the Active Directory Recycle Bin.

Related content

• Group SOA overview
• How to configure Group SOA