Bruce Sanderson's Domain and Active Directory Stuff

Generic Rules for User Accounts, Groups, Permissions and Group Policy Objects in a Windows Domain

The rules here are essentially guidelines to help keep the Active Directory organised and simplify administration. From time to time, there will be good and valid reasons to deviate from the rules. Your organisation may develop different rules. The important thing is to have some rules and guidelines and stick to them.

If a situation arises that deviating from the rules would be expedient, I suggest reviewing the objective of the rule(s) in question and determine whether there is a good, sound, business reason for deviating. If there isn’t, then don’t deviate, even if it appears to mean more work.

Any set of rules and guidelines needs to be reviewed and adapted to changing needs and organisational procedures; just make sure you understand why the rule needs to be changed and evaluate the impact on future administrative overheads or difficulties – rules and guidelines are in place to avoid chaos and keep administrative overheads down; they also guide staff in how to do day to day administration tasks consistently and usefully.

1. User Accounts

1.1. User accounts for people

1.1.1. Each person that is to have access to any domain resources must have at least one user account that is specifically for them.

1.1.2. User accounts must not be shared by multiple people.

1.1.3. When adding user accounts to groups, the principle of “least privilege” should be used. That is only grant the user account those rights and permissions the person requires to do their work. For example, people don’t need to be members (directly or indirectly) of the local Administrators group on the workstations (or servers – e.g. Terminal Services) that they use for normal day to day work.

1.1.4. For people that have administrative roles, create at least one additional user account specifically for that person to use while doing administrative tasks.

1.1.5. Passwords must be set to expire, preferably within 90 days or less.

1.2. User accounts for services

The word “services” here means any process that runs in the background and not initiated by a logged on user to run in their Windows Session. This may be a true Windows “service” or may be any application that runs in the background, e.g. as a Scheduled Task or by some other “job scheduling” system. Often, such services required access to resources across the network, which the local computer’s built-in accounts (e.g. Administrator, Local System) do not have. Domain user accounts are useful, if not essential for such services.

1.2.1. Each service or, when appropriate, group of closely related services must have its own user account that can be used to grant the rights and permissions required by that service.

1.2.2. Passwords for service accounts are usually set to never expire.

1.2.3. Establish a routine operational procedure to change the service account passwords according to a defined schedule (e.g. once a year) depending on the nature of the service and associated business needs.

1.2.4. Administration procedures for service user accounts is usually quite different than those of user accounts for people – for example, GPOs applied user accounts for people will usually be inappropriate for user accounts for services. Keep service user accounts in a separate OU hierarchy than that for user accounts for people.

1.3. Never grant a user account a permission or right on a resource (see 2.1.3 below); always use a Resource group. Among other things, the only way to determine which resources a user account has specifically been granted a permission or right to is to examine each and every possible resource. In a domain of any size, this is a practical impossibility.

2. Groups

2.1. Although this concept is not built in to Active Directory, it is essential to clearly distinguish between “Resource” and “Role” groups:

2.1.1. Resource groups are those groups used exclusively for granting specific rights and permissions to a particular, specific resource.

2.1.2. Role groups are those groups that have a set of user accounts (or less commonly, computer accounts) that share the same business role. This could be as general as, for example, all the people in a particular department. It could also be more specific, e.g. those people that administer or support (e.g. image, install software, fix problems etc.) workstation computers, perhaps in a specific location.

2.1.3. Examples of resources are:

2.1.3.1. A specific Organizational Unit sub-tree and the objects contained therein

2.1.3.2. A set of computers

2.1.3.3. A specific folder sub-tree on a specific server

2.1.3.4. A printer object on a server

2.1.4. Examples of specific rights and permissions are:

2.1.4.1. Permission to read the folders and files in a folder hierarchy

2.1.4.2. Permission to modify the folders and files in a folder hierarchy

2.1.4.3. The right to logon remotely to a computer

2.1.4.4. Permission to join a computer to the domain

2.1.4.5. Permission to create or modify a user account in an OU hierarchy

2.1.4.6. Permission to create or delete OUs in an OU hierarchy

2.1.4.7. Permissions and rights needed to fully administer a computer (server or workstation)

2.1.4.8. Permission to create, modify, delete Group Policy Objects

2.1.4.9. Permission to link Group Policy Objects to OUs

2.2. Never use a Role group to specifically grant a right or permission to a resource; always use a Resource group for this purpose. The reason for this rule is similar to the corresponding rule for user accounts – finding out what resources a group is applied to requires enumeration of all the resources in the domain (or potentially, other domains).
Active Directory Users and Computers provides a way to view and change group membership, but there is no way to find out where that group has been used inside (e.g. to grant permission to manage objects in an OU) or outside of Active Directory (e.g. on a folder, share, printer, or a local group on a computer).

2.3. Identify whether a group is a Resource or Role group by including Role or Res in the group name.

2.4. Name Resource groups so it is easy to tell what resource they apply to and what rights or permissions that resource group is used to grant on that resource (e.g. Res Server Administrators – used to grant administrator rights and permissions on server computers; Res lhdc1 GeneralInfomation Modify – used to grant Modify permission to the GeneralInformation share/folder on the computer called lhdc1).

2.5. For Resource groups, use the Description field to:

2.5.1. Identify exactly what permission(s) or right(s) to which resource this Resource group is being used for

2.5.2. Who has authority to change the membership of the group – usually this will be the resource “owner”.

2.6. Don’t nest Resource groups. A resource group is created to grant specific permissions to a specific resource. Resources (by our definition) can not be nested. In a hierarchy (folder, OU), the Resource is the highest level in the hierarchy to which the specific permission is to be applied. Lower levels in the hierarchy automatically inherit the applied permissions by default. While it is possible to block this inheritance, doing so complicates administration considerably and is to be avoided if at all possible. Also, it is a simple matter to remove the blocking of the inheritance accidentally, which will cause much consternation when “secret” stuff is suddenly available to people who shouldn’t see it or be able to modify it.

2.7. Populate Resource groups with Role groups instead of individual user accounts. In most cases, this is why you have certain Role groups in the first place.

If a particular Resource group is only ever going to have one or a few user accounts in it, then it makes sense to put the user accounts directly in the Resource group rather than creating another Role group specifically for the purpose. This is a judgement call – think it through and make a rational decision about what makes the most sense in the long term. If you get more than, say 10 user accounts in a Resource group, it may be time to re-think what’s going on and switch to using one or more Role groups, particularly if the same set (or a subset) of user accounts appears in several Resource groups.

2.8. Use Role groups to gather together user accounts (and often, related Role groups) for people that have similar roles in the organization. Most people will have more than one Role and their user account will therefore appear in more than one Role group.

2.9. Use Role group nesting (making a Role group a member of another Role group) to reduce the number of Role groups that user accounts have to be direct members of. This reduces administration overhead when users change roles (e.g. move from one department to another, get promoted, or change jobs).

3. About Permissions

3.1. When you use the Security tab, particularly if you click the Advanced button, you’ll notice that some of the groups have multiple entries with “Special” under “Permissions”. “Special” merely means that the Permissions granted don’t correspond to one of the pre-defined sets of permissions that are commonly used and have been assigned names. The pre-defined sets of permissions are such things as “Full Control” (every possible permission), “Read” (those permissions required to view or use the object, but not change it) etc.

3.2. To see which specific permissions have been assigned when “Special” appears, in the Advanced dialog, select the entry and click Edit.... Different object classes have different sets of possible permissions that can be granted. For most purposes, the pre-defined set of permissions is all that is needed, but the individual permissions are available and can be useful in particular situations.

3.3. As with file and folder permissions, Deny permissions for Active Directory objects take precedence over Allow permissions. If Deny permissions apply to a user because of one group membership, that user will not have that permission regardless of how many other groups the user is a member of have a corresponding Allow permission. Deny permissions have their uses, but I suggest avoid using them unless and until you have a very specific requirement to use them.

4. Group Policies

4.1. Do not mix user accounts and computer accounts in the same OU

4.2. Do not mix User Configuration settings and Computer Configuration settings in the same GPO

4.3. Link GPOs with User Configuration settings only to OUs with User Accounts and link GPOs with Computer Configuration Settings only to OUs with Computer Accounts

4.4. Avoid using the Block Inheritance option for an OU hierarchy because that will block all Group Policy Objects including the Default Domain Policy. Try to arrange the OU hierarchy so this is not necessary to achieve any business objective.

Last updated 14 February, 2008