Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for the creation and use of security groups within Active Directory.

First of all, let’s recap on the various group scopes.

Account groups are used to group users and computers. There are two types:

• Global groups may contain members from their own domain (only).
• Universal groups may contain members from any domain in the same forest and their membership is included in the global catalog in order to support mail-enabled groups.

Permissions may be assigned to either type of group (as long as they are in the same or a trusted domain).

Resource groups are used to assign rights and permissions and, again, there are two types:

• Domain Local groups may contain members from any trusted domain in any forest (so are required if there is to be a cross-forest group membership).
• Built-in local groups.

Permissions may be assigned to either type of group but only in their own domain.

Some organisations will ignore the differences in group scope if they are using a single domain environment, as the various types of group will function in a similar manner; however it’s worth considering that the forest/domain design may change over time (e.g. as a result of business changes) and so it is always good practice to use the appropriate group type.

The recommended approach is to add users to account groups, then add account groups to resource groups and use the resource groups to assign permissions on objects.

One consideration is nesting – whilst nested groups help to keep the size of the kerberos token down (Microsoft knowledge base article 263693 is old now, but explains why this this may be an issue), it can also make auditing difficult. Nesting is not to be totally avoided; however the complexity of the nested groups should be carefully considered. In particular, nesting groups into the built-in Administrator group should be avoided as it creates a potential “back door” into a system – anyone with the ability to add users to one of the nested groups can effectively make themself an administrator!

Adding users directly to a domain local group is not good practice but there are situations where it can be useful. For example, if there are two forests with a trust relationship, adding user accounts from one forest into a domain local group in the other may be preferable to adding a global group from the trusted domain to the domain local group, which effectively delegates control over the domain local group to the administrator in the trusted forest – almost certainly undesirable.

Basically, add users to account groups, account groups to resource groups and assign permissions to resource groups where possible but sometimes a little flexibility may be required.

In the next post in this series, I’ll take a look at the design considerations for domain controller placement and the associated site links.