Administrators tasked with cleaning up the Active Directory user group structure need not search any further. Use these tips to avoid Active Directory maintenance headaches.
It's a familiar refrain for many in the IT field: You start a new job and have to clean up the previous administrator's handiwork, such as their Active Directory group configuration.
You might inherit an Active Directory group strategy from an admin who didn't think the process through, leaving you with a setup that doesn't reflect the usage patterns of your users. Administrators who take the time to organize Active Directory organizational units and groups in a more coherent fashion will simplify their workload by making it easier to audit Active Directory identities and minimize the Active Directory attack surface.
Here are some practical tips and tricks to streamline your Active Directory (AD) administrator work and support your security compliance officers.
The traditional Active Directory design pattern
To start, always organize individual user accounts into groups. Avoid giving access permissions to individual user accounts because that approach does not scale.
Figure 1 shows Microsoft's recommendation to organize Active Directory user accounts for resource access.
Figure 1. Microsoft recommends the account, global, domain local, permission security model to organize Active Directory user accounts.
The account, global, domain local, permission (AGDLP) model uses the following workflow:
Organize users into global groups based on business criteria, such as department and location.
Place the appropriate global groups into domain local groups on resource servers based on similar resource access requirements.
Grant resource permissions to domain local groups only.
Note how this model uses two different scopes. Global groups organize AD users at the domain level, and domain local groups organize global groups at the access server level, such as a file server or a print server.
Employ role-based access control principles
Role-based access control (RBAC) grants access to groups based on job role. For example, consider network printer access:
Most users need only the ability to submit and manage their own print jobs.
Some users have delegated privileges to manage the entire print queue.
Select users have full administrative access to the printer's hardware and software.
Microsoft helps with some of the planning work by prepopulating RBAC roles in Active Directory. For instance, installing the Domain Name Service role creates several sub-administrative groups in Active Directory.
Instead of relying on prebuilt groups, think about the user population and how to design global and domain local groups. Try to organize Active Directory global groups according to business rules and domain local groups based on access roles.
You might have global groups defined for each business unit at your organization, including IT, accounting, legal, manufacturing and human resources. You might also have domain local groups based on specific job tasks: print queue managers, print users, file access managers, file readers, database reporters and database developers.
When you organize Active Directory, the goals are to describe both the user population and their resource access requirements completely and accurately while you keep the number of global and domain local groups as small as possible to reduce the management workload.
Keep group nesting to a minimum if possible
You should keep group nesting to a minimum because it increases your administrative overhead and makes it more difficult to troubleshoot effective access. You should only populate global groups with individual Active Directory user accounts and only populate domain local groups with global groups.
Figure 2. The effective access tab displays the effective permissions for groups, users and device accounts.
The Windows Server and client operating systems have a feature called effective access, found in the advanced security settings dialog box in a file or folder's properties sheet. You model effective access for a particular user, group or computer account from this location. But analyzing multiple folders with this feature doesn't scale. You have to run it multiple times to analyze permissions.
In a multi-domain environment, nesting is unavoidable. Stick to single domain topologies when possible.
Figure 3. A cross-domain resource access configuration in Active Directory offers more flexibility to the administrator.
I recommend the topology in Figure 3 because while global groups can contain Active Directory user accounts from their own domain only, you can add global groups to discretionary access control lists in any forest domain.
Here's what's happening in the topology in Figure 3:
A: Global groups represent marketing department employees in the contoso.com and corp.contoso.com domains.
B: We create a domain local group on our app server named Mktg App Access and populate it with both global groups.
C: We assign permissions on our line-of-business marketing app to the Mktg App Access domain local group.
When you need to organize Active Directory groups, develop a naming convention that makes sense to everyone on your team and stick to it.
You might wonder why there is no mention of universal groups. I avoid them because they slow down user logon times due to global catalog universal group membership lookups. Universal groups also make it easy to be sloppy during group creation and with resource access strategy.
How to design for the hybrid cloud
Microsoft offers Azure Active Directory for cloud identity services that you can synchronize with on-premises Active Directory user and group accounts, but Azure AD does not support organizational units. Azure AD uses a flat list of user and group accounts that works well for identity purposes.
With this structure in mind, proper user and group naming is paramount. You should also sufficiently populate Active Directory properties to make it easier to manage these accounts in the Azure cloud.
When you need to organize Active Directory groups, develop a naming convention that makes sense to everyone on your team and stick to it.
One common group naming pattern involves prefixes. For example, you might start all your global group names with GL_ and your domain local group names with DL_. If you use Exchange Server, then you will have distribution groups in addition to the AD security groups. In that instance, you could use the DI_ prefix.
Dig Deeper on Microsoft messaging and collaboration
