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
Estimated lesson time: 25 minutes
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.
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.
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:
Domain local security groups are most often used to assign permissions to resources. A domain local group has the following characteristics:
Universal security groups are most often used to assign permissions to related resources in multiple domains. A universal security group has the following characteristics:
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:
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 |
Planning user accounts and groups is a two-step process:
To name and place user accounts, you must complete the following tasks:
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
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
To name and define groups, you must complete the following tasks:
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:
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:
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:
To name and define groups
The following scenarios are examples of naming and placing user accounts and naming and defining groups.
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 |
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 |
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.
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.