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.
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.
The account, global, domain local, permission (AGDLP) model uses the following workflow:
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.
Role-based access control (RBAC) grants access to groups based on job role. For example, consider network printer access:
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.
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.
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.
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:
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.
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.
13 Jun 2018