The use of standardized group names is a simple yet crucial step towards easier management. Reducing the number of AD groups will make it simpler to manage and allow new staff to figure out what's what faster.
You can save yourself countless confused conversations by standardizing AD Group Names.
Warning: Be very careful if you are renaming groups - permissions can break, especially if the group is sync'd to Entra ID (formerly Azure AD).
For example, this is a list of AD groups associated with products:
SSWSugarLearningAlerts
Alerts CodeAuditor
SEC_SSW-LinkAuditor-Devs
timepro-devs
Figure: Bad Example – With no consistency, it is difficult to know the correct name for an AD group
SSWSugarLearningAlerts
SSWCodeAuditorAlerts
SECSSWLinkAuditorDevs
SECSSWTimeProDevs
Figure: Good Example – By standardizing the names of AD groups it saves confusion
Note: For large organizations, a better way is to use a type of group (eg. Local or Global)... then the entity it is associated to… then the resource (or service).
Examples:
- L-LocalGroupName-SYD-EntityName-SP-Sharepoint- becomes L-SYD-SP-SSW-Users
- G-GlobalGroupName-SYD-EntityName-SP-Sharepoint- becomes G-SYD-SP-SSW-Users
Types of groups
It is also important to differentiate between Distribution groups (or other groups with mail enabled), and Security groups. Distribution groups should have names that are clear, that work well for an email address - for example, SSWRulesDevs. Security groups should have the prefix It is SEC_, so that it is clear they are security groups (and cannot receive email), e.g. SEC_VPNUsers.
