Empty Group

While an empty group may not always constitute "bad practice", its usefulness depends on the specific use case and organizational requirements. However, there are several reasons to exercise caution or avoid empty groups:

Teams may struggle to determine the purpose of an empty group, leading to wasted time and inefficiencies.
Security implications: If permissions are assigned to the group, users added later may inadvertently inherit forgotten or unintended access.
Policy compliance: Empty groups may trigger alerts or flag issues during compliance audits.
Unused resources: Unused groups contribute to clutter, making cleanup essential to maintain efficiency.

Certain scenarios may justify the existence of empty groups, such as serving as placeholders for future use or as part of a broader role-based access control (RBAC) strategy, where groups are pre-defined for scalability.

Single Member Group

Having a group with only one member is generally considered bad practice. Creating a group for a single user adds unnecessary complexity and redundancy. Groups simplify access management by consolidating users with similar permissions. A single-member group fails this purpose, leading to administrative inefficiency. Instead, grouping similar users enhances efficiency and streamlines management.
In certain scenarios, a group with only one user may be necessary, particularly when it serves a specific purpose within a broader role-based access control (RBAC) strategy.

Security Profile Customization

Active Directory or other products create certain groups during deployment. Do not delete these groups, even if they appear unused. To reduce false positives, this Indicator of Exposure automatically ignores the following groups from common products:

Built-in groups: Groups with an objectSID attribute starting with "S-1-5-32-".
AD specific groups: Groups with an objectSID attribute starting with "S-1-5-21-" and ending with a RID greater or equal to 1000, with the additional groups "DnsAdmins" and "DnsUpdateProxy".
Exchange groups: Groups named "Compliance Management", "Delegated Setup", "Discovery Management", "Exchange Install Domain Servers", "Exchange Trusted Subsystem", "Exchange Windows Permissions", "ExchangeLegacyInterop", "Help Desk", "Hygiene Management", "Organization Management", "Public Folder Management", "Recipient Management", "Records Management", "Security Administrator", "Security Reader", "Security Reader", "Server Management", "System Managed Accounts Group", "UM Management", and "View-Only Organization Management".
Entra ID Connect groups: "ADSyncAdmins", "ADSyncOperators", "ADSyncBrowse", and "ADSyncPasswordSet".

You can ignore additional groups using the dedicated option "Whitelist of groups". Conversely, you can also enable the option "Force analysis of groups ignored by default" to force the analysis of a group that the IoE ignores by default.
By default, disabled users in a group are included in the member count. However, you can filter them out using the option "Keep disabled accounts". For example, if MyGroup has two disabled users:

By default, the IoE detects no deviance.
If you disable the "Keep disabled accounts" option, the IoE flags the group as an "Empty Group" deviance.
Limitation:
This IoE does not not count users that belong to groups via their Primary Group (PGID). Microsoft Entra Connect has a similar limitation. Either assign these users as explicit member of the groups, and restore their default PGID (e.g. "Domain Users"), or whitelist them if impossible.

Detections

Analytics

Non-Essential Group

low

Description

Solution

Indicator Details