Original text by JEREMY SAUNDERS
This PowerShell script is one of the most comprehensive you will find that provides a thorough overview and full report of all group objects in a domain. It is the culmination of many Active Directory audit and reviews and therefore contains valuable input from many customers.
A lot of thought has been put into the logic within this script to help an organisation understand:
- A breakdown of each group type (category and scope) that have been created
- Groups with no members
- Groups that are flagged as critical system objects
- Groups that are protected objects (AdminSDHolder) where their adminCount attribute is set to 1
- Groups that are conflicting/duplicate objects (name contains CNF: and/or sAMAccountName contains $Duplicate)
- Groups that are mail-enabled
- Distribution groups that are mail-disabled
- Groups that are Unix-enabled
- Groups that have expired
- Groups with SID history
- Groups with no Manager (managedBy)
- The non-“Microsoft” default groups that have been left in the default Users container
- Mail-enabled groups are derived from the proxyAddresses, legacyExchangeDN, mailNickName, and reportToOriginator attributes, where reportToOriginator must be set to TRUE. This is not well documented.
- Unix-enabled groups are derived from the gidNumber, msSFU30Name, and msSFU30NisDomain attributes.
Open the full CSV report in Excel and add a column filter and freeze the top row. This will help you to filter the data and move through the spreadsheet with ease.
Review the value of groups that contain no members, are not critical system objects, protected objects (AdminSDHolder), and not excluded objects. Delete them if they are no longer serving their purpose. Alternatively, move them into an OU and add the OU to the $ExclusionOUs array in the script to ensure they are correctly flagged in the next run.
- Security groups can be disabled by converting them to a distribution group.
- Distribution groups can be disabled by mail-disabling them.
You should always clearly document situations where groups have been disabled. i.e. Are they being kept for a reason, or should they be deleted. Delete them if they no longer serve a purpose.
Review the groups that have been marked as protected objects (AdminSDHolder) that may now fall out of scope. If these groups are not going to be deleted, they should be restored to their original state by reactivating the inheritance rights on the object itself and clearing the adminCount attribute. I recommend using a script written by Tony Murray to clean up the AdminSDHolder: Cleaning up AdminSDHolder orphans
Further information about the AdminSDHolder can be found here:
- AdminSDHolder, Protected Groups and Security Descriptor Propagator
- AdminSDHolder, Protected Groups and SDPROP
- AD Permissions : The AdminSDHolder Mechanism
- Five common questions about AdminSdHolder and SDProp
Groups whose name contains CNF: and/or sAMAccountName contains $Duplicate means that it’s a duplicate account caused by conflicting/duplicate objects. This typically occurs when objects are created on different Read Write Domain Controllers at nearly the same time. After replication kicks in and those conflicting/duplicate objects replicate to other Read Write Domain Controllers, Active Directory replication applies a conflict resolution mechanism to ensure every object is and remains unique. You can’t just delete the conflicting/duplicate objects, as these may often be in use. You need to merge the group membership and ensure the valid group is correctly applied to the resource. Then you can confidently delete the conflicting/duplicate group.
You should never delete groups marked as Critical System Objects.
There should be no groups with an unrecognised group type. But if there are any, they must be investigated and remediated immediately as they could be the result of more serious issues.
Some groups may simply be placeholders for certain tasks, scripts and policies, and therefore may purposely not contain any members. Simply move these groups into an OU and add the OU to the $ExclusionOUs array to flag and exclude them from the final no members count.
In general add groups and OUs to the ‘Exclusion’ arrays to flag and exclude groups with no members from the final no members count.
From here you can start to implement some good policies and processes around the usage and management of the groups.
At the end of the day a nice way to manage groups is to set their expirationTime attribute. This will give us the ability to implement a nice life cycle management process. You can go one step further and add a user or mail-enabled security group to the managedBy attribute. This will give us the ability to implement some workflow when the group is x days before expiring.
The following screen shot is from a recent health check and audit I completed. This customer has about 137,000 group objects in their domain. The script took about 2 and a half hours to complete. PowerShell consumed almost 8 GB of RAM. The full CSV report was about 55.5 MB.
What sticks out here like a sore thumb is the fact that over 23% of the groups have no members!
The following screen shot is the full report from the same health check. Whilst I’ve had to blur our some of the data you can get an idea from the column headings that it’s fairly extensive. There are a further 6 columns that I was unable to capture in the screen shot due to screen resolution.
IMPORTANT: As of version 1.8 this script now works in non Microsoft Exchange environments.
Here is the Get-GroupReport.ps1 (1578 downloads) script