• 
• Microsys
• SysNews
• NC State Help Desk
• ITD Services A-Z

Groups & Permissions

Overview

This page describes how groups and permissions are designed in the Unity domain.  The guidelines described here are used by ITD.  Other departments that use the domain are encouraged to follow these guidelines for their own resources but are not required to do so.

The goals of these guidelines are:

• Keep things simple.  Active Directory groups can be confusing at first.  There are several different types.  It takes a while to memorize which type of group can contain which type of members and so on.  For simplicity, ITD only uses domain local security and global security groups.
• Keep things manageable.  The Unity domain already has over 90,000 user accounts.  It will ultimately have 100's of OUs and groups, and 1,000's of computer accounts.  Add to these domain objects the number of directories and shares that need to be accessed and manageability can get out of hand in a hurry.  These guidelines are intended to help everyone organize accounts and permissions in a logical way from the start so that it is very easy to manage the environment as it grows.
• Keep the number of access control list entries small.  Over time, more and more accounts need access to domain and filesystem resources.  The easy way is to just go to the resource and grant permissions to the account.  As we have seen in the old environment, this results in many accounts and groups being added to the ACLs.  Different administrators do things different ways and it is common to discover a permission that really shouldn't have been applied.  It is difficult to keep track of these because they are set on objects and directories all over the place.  These guidlines suggest that narrowly focused domain local groups be used as the only type of object that is added to ACLs.  You then grant access to the resource by adding members to the domain local groups.

Accounts > Global > Local > Permissions ("AGLP")

Accounts are members of global groups.

Global groups are members of local groups.

Permissions are assigned to local groups.

Groups

• The only types of groups used are domain local and global security groups
• Universal groups are not used
• Distribution groups are not used
• Accounts should only be members of global groups
• Accounts should not be members of local groups
• Local groups should only contain global groups and other local groups
• Local groups should be named after the resource access assigned to the group
• Global groups should only contain accounts and other global groups
• Global groups should be named after the collection of accounts that are members of the group
• Groups should not contain more than 5,000 members

Permissions

• Should only be assigned to domain local groups
• Should not be assigned directly to accounts
• Should not be assigned to global groups

Domain versus Machine Local Groups

Groups exist as objects in the domain as well as in the local SAM database on member servers and workstations.  These guidelines are concerned with domain groups.  Local groups should be avoided if you can accomplish the same result with domain groups.

Security versus Distribution Groups

Security groups can be granted permissions and used to filter GPOs.  They are used extensively in our environment.

Distribution groups are only used to create e-mail distribution lists for products such as Exchange.  They cannot be granted permissions.  They cannot be used to filter GPOs.  As such, distribution groups have no practical purpose in our current environment and there is no reason to create any.

 

Group Scope

A group's scope determines the extent to which it can be nested in other groups or granted permissions to resources on a local computer or in a domain or forest.  There is one type of scope for groups created locally on computers: machine local.  There are three types of scopes for domain groups: domain local, global,  and universal.

Domain Local Security Groups

Domain local groups should only be used to assign permissions to resouces.  Permissions should only be assigned to domain local groups. Local groups should be named after the resource access assigned to the group.  For example, "ITD_Unity Computers OUFull Control".

The design and control of resource access in the domain is soley based on domain local groups.  A domain local group should be created for every type of resource access you need to assign.  Domain local groups should be created so that the access they assign is very granular. 

For example, assume a set of users needs need full control to the helpdesk OU and locker.  Do not assign permissions to the separate resources directly to a single group:

Instead, create two domain local groups and assign permissions to the separate resources:

Domain local groups can be nested in other domain local groups if a set of resource access permissions is necessary.  This is useful to designate roles.  In this example, a third domain local group should be created to designate the role of helpdesk resource admins:

 

This means a lot of domain local groups will be created but it will result in a more manageable resource access architecture.  If another group of users needs the same access to the helpdesk OU but not the locker, you simply make that group a member of the "Helpdesk OU Full Control" group.  This results in a shorter and simpler access control list for the OU.

Domain local groups can contain members from any trusted domain in any forest.  A domain local group is the only type of group that can contain members from other forests.

Domain local groups should only contain other domain local and global groups.  It is possible for domain local groups to also contain accounts and universal groups.  Do not put accounts directly into local groups.  Accounts get put into global groups.

Domain local group membership is controlled by the administrators who are responsible for the resources to which access is granted.

Global Security Groups

Global groups are used as a means to organize accounts within the domain. Global groups can only contain accounts and other global groups from the domain where the global group resides.  Global groups should be named after the collection of accounts the group contains.  For example, "ITD_Publications FT Staff".

Accounts (users and computers) are put into global groups.  Accounts are only put into global groups.

Global groups can be nested in other global groups.  This is useful if you want to do something like reflect your organizational chart in the domain.  For example, you would create individual global groups for each set of employees in your department down to the smallest division.  User accounts would get put into these global groups.  You would also create global groups for each of the larger sets of employees in your department, all the way up to a global group that encompasses your entire department:

Any of these global groups can be made a member of a domain local group in order to assign access to resources.  This makes it easy to assign access to a set of users as small or as large as necessary.  This also reduces the number of entries in the access control lists of the resources.

Global groups can be made members of domain local groups in other domains in any forest.  This is useful if one domain contains accounts for everyone and a completely separate domain contains a department's resources.

Universal Security Groups

Universal groups are similar to global groups in that they are used to organize accounts and not used to assign permissions to resources.  Universal groups can contain accounts, global groups, and other universal groups.

The main difference between universal and global groups is that universal gropus can contain members from any domain within a forest whereas global groups can only contain members from within the group's domain.  Since the Unity domain is the only domain in the forest and will remain that way, this feature provides no advantage in our environment.

There can also be replication and performance drawbacks if universal groups are used.  Universal groups and all of their members are listed in the global catalog.  As a result, replication traffic will occur whenever the members of a universal group change.  Global groups are listed in the global catalog but their members are not.  As a result, replication traffic will not occur when the members of a global group change

 

Group Scope Comparison

Scope	Can Contain	Can Be A Member Of	Can grant permissions	Scope conversion
Domain Local	Accounts from any domain.	Other domain local groups in the same domain. (To create sets of access permissions, roles)	Within the same domain.	Can be converted to universal scope as long as the group does not contain any other domain local groups.
	Global groups from any domain.	Local groups on machines in the same domain, excluding built-in groups that have well-known SIDs.
	Universal groups from any domain.
	Other domain local groups from the same domain.
Global	Accounts from the same domain.	Domain local groups in any domain.	In any domain .	Can be converted to universal scope as long as the group is not a member of any other global group.
	Other global groups from the same domain.	Other global groups in the same domain.
	Cannot contain members from other domains.	Universal groups in any domain in the same forest.
Universal	Accounts from any domain in the same forest.	Other universal groups in the same forest.	In any domain.	Can be converted to domain local scope.
	Global groups from any domain in the same forest.	Domain local groups in any domain.		Can be converted to global scope as long as the group does not contain any other universal groups.
	Other universal groups from any domain in the same forest.	Local groups on any machine.
	Cannot contain members from outside the forest.	Cannot be a member of global groups

Andy Kurth
2/15/2007

About Microsys | Accessibility in our Services | Feedback | Microsys RSS Feeds | February 16, 2007