Lesson 2: Planning User Accounts and Groups

After you define OU structures, the next step in creating an OU plan is to plan user accounts and groups. When you plan user accounts and groups, you define the user accounts and groups needed for each domain in your organization. This lesson discusses how to plan user accounts and groups, which includes naming and placing user accounts and naming and defining groups.

---

After this lesson, you will be able to

• Identify the factors in an organization's environment that impact its naming conventions
• Analyze an organization's environment to establish naming conventions for users and groups
• Identify factors in an organization's environment that impact the placement of user accounts
• Analyze an organization's environment to place user accounts
• Identify factors in an organization's environment that impact its need for groups
• Analyze an organization's environment to define groups

Estimated lesson time: 25 minutes

---

Understanding Users and Groups

Before launching into a discussion of users and groups, it's important to understand the difference between OUs and groups. In the previous lesson, you learned that OUs contain objects such as user accounts, groups, computers, printers, applications, file shares, and other OUs from the same domain. OUs are defined mainly to delegate the administration of their contents. Groups also contain objects such as user accounts, contacts, computers, and other groups. However, groups are defined mainly to assign permissions to users or to restrict user access to various objects in the domain. Planning user accounts and groups is the second part of creating an organizational unit plan.

User Accounts

A domain user account provides a user with the ability to log onto the domain to gain access to network resources. Each person who regularly uses the network should have a unique user account.

You create a domain user account in a container or in an OU on a domain controller. The domain controller replicates the new user account information to all domain controllers in the domain. After Windows 2000 replicates the new user account information, all of the domain controllers in the domain tree can authenticate the user during the logon process. During the logon process, each user provides his or her user name and password. By using this information, Windows 2000 authenticates the users and then builds an access token that contains information about the user and security settings. The access token identifies the user to computers running Windows 2000 and pre–Windows 2000 computers on which the user tries to gain access to resources. Windows 2000 provides the access token for the duration of the logon session.

Groups

A group is a collection of user accounts. Groups simplify administration by allowing you to assign permissions to a group of users rather than having to assign permissions to each individual user account. Permissions control what users can do with a resource, such as a folder, file, or printer. When you assign permissions, you give users the capability to gain access to a resource and define the type of access that they have. For example, if several users need to read the same file, you would add their user accounts to a group. Then, you would give the group permission to read the file.

In addition to user accounts, you can add other groups, contacts, and computers to groups. You add groups to other groups to create a consolidated group and reduce the number of times that you need to assign permissions. However, you should use caution to add only those groups that are absolutely necessary. You add computers to groups to simplify the process of giving a user logged on to one computer access to a resource on another computer.

Group Types

You can create groups for security-related purposes, such as assigning permissions, or for nonsecurity purposes, such as sending e-mail messages. To facilitate this, Windows 2000 includes two group types: security and distribution. The group type determines how you use the group. Both types of groups are stored in the database component of Active Directory, which allows you to use them anywhere in your network.

Windows 2000 uses only security groups, which you use to assign permissions to gain access to resources. Programs that are designed to search Active Directory can also use security groups for nonsecurity-related purposes, such as retrieving user information for use in a Web application. A security group also has all the capabilities of a distribution group. Because Windows 2000 uses only security groups, this lesson focuses on security groups.

Group Scopes

When you create a group you must select a group type and a group scope. Group scopes allow you to use groups in different ways to assign permissions. The scope of a group determines where in the network you are able to use the group to assign permissions to the group. The three group scopes are global, domain local, and universal.

Global security groups are most often used to organize users who share similar network access requirements. A global group has the following characteristics:

• Limited membership. You can add members only from the domain in which you create the global group.
• Access to resources in any domain. You can use a global group to assign permissions to gain access to resources that are located in any domain in the domain tree or forest.

Domain local security groups are most often used to assign permissions to resources. A domain local group has the following characteristics:

• Open membership. You can add members from any domain.
• Access to resources in one domain. You can use a domain local group to assign permissions to gain access only to resources located in the same domain where you create the domain local group.

Universal security groups are most often used to assign permissions to related resources in multiple domains. A universal security group has the following characteristics:

• Open membership. You can add members from any domain.
• Access to resources in any domain. You can use a universal group to assign permissions to gain access to resources that are located in any domain.
• Available only in native mode. Universal security groups are not available in mixed mode.

Group Nesting

Adding groups to other groups, or nesting, creates a consolidated group and can reduce network traffic between domains and simplify administration in a domain tree. For example, you could create separate regional manager groups for the managers in each region. Then, you could add all of the regional manager groups to a worldwide managers group. When all managers need access to resources, you assign permissions only to the worldwide managers group.

Guidelines for group nesting include the following:

• Minimize levels of nesting. Tracking permissions and troubleshooting becomes more complex with multiple levels of nesting. One level of nesting is the most effective to use.
• Document group membership to keep track of permissions assignments. Providing documentation of group membership can eliminate the redundant assignment of user accounts to groups and reduce the likelihood of accidental group assignments.

To efficiently use nesting it is important to understand the membership rules of groups.

Rules for Group Membership

The group scope determines the membership of a group. Membership rules determine the members that a group can contain. Table 5.1 describes group membership rules, including what each group scope can contain in native and mixed mode.

Table 5.1 Group Scope Membership Rules

Group scope	In native mode, group can contain	In mixed mode, group can contain
Global	User accounts and global groups from the same domain	Users from the same domain
Domain local	User accounts, universal groups, and global groups from any domain; domain local groups from the same domain	User accounts and global groups from any domain
Universal	User accounts, other universal groups, and global groups from any domain	Not applicable; universal groups cannot be created in mixed mode

Design Step: Planning User Accounts and Groups

Planning user accounts and groups is a two-step process:

1. Name and place user accounts.
2. Name and define groups.

Naming and Placing User Accounts

To name and place user accounts, you must complete the following tasks:

1. Assess the organization's existing user account naming conventions and OU structure to determine current user account naming requirements and the OU structure.
2. Determine the user account naming convention.
3. Place user accounts in the appropriate OUs.

Assessing User Account Naming Conventions and the OU Structure

To determine current user account naming conventions, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current user account naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes in user account names currently planned to address growth, flexibility, and the ideal design specifications of the organization.

NOTE

---

A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

To place user accounts in the appropriate OUs, use the OU structure diagram to determine

• The user accounts administered by each administrative group
• The user accounts affected by each GPO

Determining User Account Naming Conventions

By establishing a naming convention for user accounts, you can standardize how users are identified in the domain. A consistent naming convention will help you and your users remember user logon names and locate them in lists. Table 5.2 summarizes some points you might want to consider in determining a user account naming convention for your organization.

Table 5.2 User Account Naming Convention Considerations

Consideration	Explanation
Domain user accounts	The user's logon name (distinguished name) must be unique to the directory. The user's full name (relative distinguished name, also referred to as display name or account name) must be unique within the OU where you create the domain user account.
20 characters maximum	User logon names can contain up to 20 uppercase or lowercase characters. Although the field accepts more than 20 characters, Windows 2000 recognizes only the first 20.
Invalid characters	The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
User logon names are not case sensitive	You can use a combination of special and alphanumeric characters to help uniquely identify user accounts. User logon names are not case sensitive, but Windows 2000 preserves the case.
Accommodate duplicate employee names	If two users were named John Doe, you could use the first name and the last initial and then add letters from the last name to differentiate the duplicate names. In this example, one user account logon name could be Johnd and the other Johndo. Another possibility would be to number each user logon name—for example, Johnd1 and Johnd2.
Identify the type of employee	In some organizations, it is useful to identify temporary employees by their user account. To identify temporary employees, you can use a T and a hyphen in front of the user's logon name—for example, T-Johnd. Alternatively, use parentheses in the name—for example, John Doe (Temp).
E-mail compatibility	Some e-mail systems may not accept characters, such as spaces and parentheses—"()".

Placing User Accounts in the Appropriate OUs

After you determine the user account naming convention, you can place user accounts in the appropriate OUs. To determine the OU for a user account, you must identify the administrative groups that administer the account and any GPOs that must apply to the account. The OU for the user account is the OU that is administered by the administrative group and the GPO.

To name and place user accounts

1. Select a naming scheme that ensures that unique user account names are generated for all users in the forest.
2. Ensure that all administrators adhere to the naming scheme.
3. List the administrative groups that must administer the account.
4. List the GPOs that must apply to the account.
5. Place the account in the OU administered by the designated administrative group and the designated GPO. List the accounts contained in each OU.

Naming and Defining Groups

To name and define groups, you must complete the following tasks:

1. Assess the organization's existing group naming conventions and OU structure to determine group naming requirements and the definition of appropriate groups.
2. Determine the group naming convention.
3. Define the appropriate global and domain local groups.
4. Define the appropriate universal groups.

Assessing Group Naming Conventions and the OU Structure

To determine group naming requirements, you must first consult the Technical Standards Worksheet compiled earlier by your design team to find out the current group naming requirements. In addition to assessing the information in this worksheet, it is imperative that you assess changes to group names currently planned to address growth, flexibility, and the ideal design specifications of the organization.

NOTE

---

A blank copy of the worksheet is located on the Supplemental Course Materials CD-ROM (\chapt02\worksheets). A completed example of the worksheet is located in Chapter 2, "Introduction to Designing a Directory Services Infrastructure."

Use the list of accounts contained in each OU to define the appropriate global, domain local, and universal groups.

Determining the Group Naming Convention

By establishing a naming convention for groups, you can standardize how groups are identified in the domain. A consistent naming convention will help you and your users remember group names and locate them in lists. Table 5.3 summarizes some points you might want to consider in determining a group naming convention for your organization.

Table 5.3 Group Naming Convention Considerations

Consideration	Explanation
Groups	The group name must be unique to the directory.
64 characters maximum	Group names can contain up to 64 uppercase or lowercase characters.
Invalid characters	The following characters are invalid: " / \ [ ] : ; | = , + * ? < >
Group names are not case sensitive	You can use a combination of special and alphanumeric characters to help uniquely identify groups. Group names are not case sensitive, but Windows 2000 preserves the case.

Defining the Appropriate Global and Domain Local Groups

Depending on the administration required for the group, you can define global and domain local groups in either domains or organizational units. The group scope determines the domain from which members can be added and the domain in which the rights and permissions assigned to the group are valid.

To define appropriate global and domain local groups:

• Identify users with common job responsibilities and add the user accounts to a global group. For example, in a finance department, user accounts for all accountants are added to a global group called Finance.
• Identify the resources to be shared, such as files or printers, and add the resources to a domain local group for that resource. For example, color printers in a company are added to a domain local group called Color Printers.
• Identify all global groups that share the same access needs for resources and make them members of the appropriate domain local group. For example, add the global groups Finance, Sales, and Management to the domain local group Color Printers.
• Assign the required permissions for the resource to the domain local group. For example, assign the necessary permissions to use color printers to the Color Printers group. Users in the Finance, Sales, and Management global groups receive the required permissions because their global group is a member of the domain local group Color Printers.

This strategy gives you the most flexibility for growth and reduces permissions assignments. Although there are other methods for defining groups, these methods have the following limitations:

• Placing user accounts in domain local groups and assigning permissions to the domain local groups does not allow you to assign permissions for resources outside of the domain, reducing the flexibility when your network grows.
• Placing user accounts in global groups and assigning permissions to the global groups can complicate administration if you are using multiple domains. If global groups from multiple domains require the same permissions, you have to assign permissions for each global group.

Defining the Appropriate Universal Groups

Use universal groups to grant or deny access to resources that are located in more than one domain. Because universal groups and their members are listed in the global catalog, when membership of any universal group changes, the changes must be replicated to every global catalog in the forest. This action can cause excessive network traffic. Therefore, you should define universal groups with caution.

Follow these guidelines to ensure minimal impact on replication traffic:

• Add global groups, not users, to universal groups. The global groups are the members of the universal group. Keep the number of group members in universal groups as low as possible and minimize the number of individual users.
• Change the membership of universal groups as infrequently as possible. By requiring all members of universal groups to be global groups and making individual membership changes in the global groups, the membership changes you make to the global groups will not affect the universal groups or replication traffic.

To name and define groups

1. Select a naming scheme that ensures that unique group names are generated for all groups in the forest.
2. Ensure that all administrators adhere to the naming scheme.
3. List the user accounts that must be added to a global group.
4. List the resources that must be added to a domain local group.
5. List all global groups that share the same access needs for resources and note the domain local group to which they must be added.
6. List the global groups that must be added to a universal group or groups.

Design Process Examples: Planning User Accounts and Groups

The following scenarios are examples of naming and placing user accounts and naming and defining groups.

Naming and Placing User Accounts

Consolidated Messenger, a worldwide fictitious delivery service, has 21 new users that need accounts at their location in Dallas. Consolidated Messenger has selected a user account naming scheme that ensures that unique user account names are generated for all users in the forest. Three years ago, the company instituted a naming scheme that creates the account name by taking the user's first initial followed by the first six letters of his or her last name. In case of the same last name, the first two letters of the first name will be used. For temporary employees, "T-" will precede the user account name. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.4 provides fictitious names and hiring information for the new employees. The table also lists the administrative groups that must administer each account and the GPOs that apply to some of the accounts.

Table 5.4 New Hire List

User name	User logon name	Title	Department	Status	Administrative group	GPOs
Alboucq, Steve	t-salbouc	Representative	Delivery	Temp	DelAdmin	1
Egert, Amy	aegert	Manager	Human Resources	Perm	AdAdmin
Guo, Bei-Jing	bguo	Developer	IT	Perm	ITAdmin
Hjellen, Robin	rhjelle	Representative	Dispatch	Perm	DspAdmin
Koduri, Sunil	skoduri	Representative	Delivery	Perm	DelAdmin
Lyon, Robert	rlyon	Representative	Human Resources	Perm	HRAdmin
Lysaker, Jenny	jlysake	Representative	Delivery	Perm	DelAdmin
Miksovsky, Jan	t-jmiksov	Representative	Delivery	Temp	DelAdmin	1
Ota, Lani	lota	Representative	Dispatch	Perm	DspAdmin
Ramirez, Francisco	t-framire	Representative	Delivery	Temp	DelAdmin	1
Richardson, Miles	mrichar	System Administrator	IT	Perm	DomainAdmins
Samarawickrama, Prasanna	psamara	Representative	Delivery	Perm	Perm
Smith, James	t-jasmith	Representative	Delivery	Temp	DelAdmin	1
Smith, Jeff	jesmith	Representative	Delivery	Perm	DelAdmin
Smith, Jeff	jsmith	Representative	Payroll	Perm	FinAdmin	4
Spencer, Phil	pspence	Representative	Delivery	Perm	DelAdmin
Steiner, Alan	asteine	Manager	Dispatch	Perm	DspAdmin
Thomas, Stephen	t-sthomas	Representative	Delivery	Temp	DelAdmin	1
Van Dam, Tanya	tvandam	Representative	Delivery	Perm	DelAdmin
Wood, John	jwood	Representative	Dispatch	Perm	DspAdmin
Yim, Kevin	kyim	Manager	Delivery	Perm	OpsAdmin

Figure 5.13 shows the OU structure diagram for the corp.dallas.c-100times.com domain.

Figure 5.13 OU structure diagram for corp.dallas.c-100times.com domain

Table 5.5 is a list of administrative groups that can administer users in each OU.

Table 5.5 Administrative Groups in Consolidated Messenger OUs

OU	Administrative groups
Operations	SysAdmin
	OpsAdmin
Distribution	SysAdmin
	OpsAdmin
	DstAdmin
Dispatch	SysAdmin
	OpsAdmin
	DspAdmin
Delivery	SysAdmin
	OpsAdmin
	DelAdmin
Administration	SysAdmin
	AdAdmin
Finance	SysAdmin
	AdAdmin
	FinAdmin
Payroll	SysAdmin
	AdAdmin
	FinAdmin
IT	SysAdmin
	AdAdmin
	ITAdmin
Human Resources	SysAdmin
	AdAdmin
	HRAdmin
Sales	SysAdmin
	AdAdmin
	SlsAdmin
Temp	SysAdmin
	TmpAdmin

Table 5.6 shows the new user accounts placed in the OU administered by the designated administrative group and the designated GPO.

Table 5.6 New User Accounts Placed in OUs

OU	New user accounts
Operations	mrichar (or Administration OU)
Dispatch	rhjelle, lota, asteine, jwood
Delivery	skoduri, jlysake, psamara, jesmith, pspence, tvandam, kyim
Temp	t-salbouc, t-jmiksov, t-framire, t-jasmith, t-sthomas
Administration	mrichar (or Operations OU)
Payroll	jsmith
IT	bguo
Human Resources	aegert, rlyon

Naming and Defining Groups

Consolidated Messenger has selected a group naming scheme that ensures that unique group names are generated for all groups in the forest. Three years ago, the company instituted a naming scheme for administrative groups that uses a two- or three-letter abbreviation for the group followed by "Admin." User group names consist of one word that describes the group. Consolidated Messenger will continue to use the naming scheme. All administrators have been trained and recognize the importance of adhering to the naming scheme. All administrators are aware of the procedures to follow in the event of exceptions to the naming scheme.

Table 5.7 provides the job function and number of employees in each job function in Consolidated Messenger's Operations division.

Table 5.7 Consolidated Messenger Operations Division Employee Information

Job function	Number of employees
Distribution Tracker	50
Distribution Handler	100
Domestic Dispatcher	50
International Dispatcher	25
Delivery Representative	200
Manager	10

Table 5.8 lists the information access requirements for various employee functions.

Table 5.8 Employee Access Requirements

Employee	Need access to
Domestic Dispatchers, International Dispatchers, Managers	Customer database, full access
Delivery Representatives	Customer database, read-only access
All employees	Company policies, read-only access
Distribution Trackers, Managers	Tracking database, full access
Distribution Handlers	Tracking database, read-only access
All employees	Company announcements through e-mail
All employees, except Delivery	Shared installation of Microsoft Office
Representatives	applications
Managers, Managers from other domains	Delivery time reports

To meet the needs listed in the table, Consolidated Messenger has planned the groups listed in Table 5.9.

Table 5.9 Consolidated Messenger Groups

Group name	Type and scope	Members
Trackers	Security, global	All Distribution Trackers
Handlers	Security, global	All Distribution Handlers
DomDispatchers	Security, global	All Domestic Dispatchers
IntDispatchers	Security, global	All International Dispatchers
DeliveryReps	Security, global	All Delivery Representatives
Managers	Security, global	All Managers
AllEmployees	Security, global	All employees
CustDatabase	Security, domain local	Domestic Dispatchers, International Dispatchers, Managers, Delivery Representatives
CompanyPol	Security, domain local	All employees
TrackDatabase	Security, domain local	Distribution Trackers, Managers, Distribution Handlers
MSOffice	Security, domain local	Distribution Trackers, Distribution Handlers, Domestic Dispatchers, International Dispatchers, Managers
DeliveryTimeReports	Security, domain local	Managers
E-mail	Distribution, domain local	All employees

The Consolidated Messenger network does not require universal groups because the information provided indicates that no groups need access to resources in multiple domains and also need to have members from multiple domains.

Lesson Summary

To begin this lesson, you were reminded that the purpose of defining OUs is to delegate administration, while the purpose of groups is to provide users with access to resources. In this lesson you learned how planning user accounts and groups is a two step-process: (1) naming and placing user accounts and (2) naming and defining groups. You learned how naming conventions help you and your users remember user logon names and locate them in lists. To place user accounts in the appropriate OUs, you must use the OU structure diagram to determine the user accounts administered by each administrative group and the user accounts affected by each GPO. You also learned how a consistent group naming convention will help you and your users remember group names and locate them in lists. To define the appropriate global, domain local, and universal groups, you identify the users to be assigned to various global groups, the resources to be assigned to various domain local groups, and the resources that are located in more than one domain to be assigned to universal groups.