MCSA/MCSE Exam 70-290 Training Guide: Managing Users, Computers, and Groups

Date: Jan 9, 2004

Sample Chapter is provided courtesy of Que.

Return to the article

Objectives

This chapter covers the following Microsoft-specified objectives for the "Managing Users, Computers, and Groups" section of the Managing and Maintaining a Microsoft Windows Server 2003 Environment exam:

Create and manage user accounts.

• Create and modify user accounts by using the Active Directory Users and Computers console.
• Create and modify user accounts by using automation.
• Import user accounts.

A primary function of a network administrator is to create and manage user accounts because user accounts are needed for users to authenticate to the network and to determine what resources the user can access.

For a small network, creating and modifying the user accounts one at a time with a management tool is not too time consuming. But on a network with hundreds or thousands of users, it makes sense to use tools that automate the process. If the data about the users exists in some other form, such as a new-hire database, you can create the user accounts by importing them from a compatible file.

Create and manage groups.

• Create and modify groups by using the Active Directory Users and Computers console.
• Identify and modify the scope of a group.
• Manage group membership.
• Find domain groups in which a user is a member.
• Create and modify groups by using automation.

For simplicity of network administration, we can create group objects and allocate resource access rights to these objects. Then by making user accounts members of the group, we can grant them the access that the group objects have been assigned.

Manage local, roaming, and mandatory user profiles.

• Create and modify local user profiles.
• Create and modify roaming user profiles.
• Create and enforce mandatory user profiles.

The settings for a user's work environment are stored in the user's profile. Any changes the user makes to the environment (Favorites, Start menu items, icons, colors, My Documents, Desktop, local settings, application-specific settings) are saved when the user logs off. The profile is reloaded when the user logs on again.

It is important for administrators to know how to manage user profiles so that the users' settings are saved from session to session. If managed properly, this also ensures the users see the same desktop no matter where they log on.

Create and manage computer accounts in an Active Directory environment.

Every computer running Windows NT, Windows 2000/2003, or Windows XP that is a member of a domain has a computer account in that domain. The computer account is a security principal, and it can be authenticated and granted permissions to access resources. A computer account is automatically created for each computer running the listed operating systems when the computer joins the domain.

Troubleshoot user accounts.

• Troubleshoot account lockouts.
• Troubleshoot issues related to user account properties.

With a large group of users, there are sure to be trouble calls every day from users having difficulties with their accounts. One system setting that often results in trouble calls is Account Lockout—a user cannot log in because the account has been disabled after too many incorrect passwords were entered. Other problems can arise due to inappropriate settings in the user accounts.

Troubleshoot user-authentication issues.

Sometimes a user will not be able to log on to the network. This can be caused by simple factors, such as a user error when entering a user ID and password, or by more complex issues such as the computer account being unusable. The network administrator must be able to determine what is causing the problem and to promptly correct the situation.

Troubleshoot computer accounts.

• Diagnose and resolve issues related to computer accounts by using the Active Directory Users and Computers MMC snap-in.
• Reset computer accounts.

When a computer account is operating incorrectly, it may be impossible to log on to the domain from the computer. In this case it is necessary to reset the computer's account and rejoin the computer to the domain. This process reestablishes the secure relationship between the computer and the domain it is a member of.

Outline

Introduction

• Creating and Managing User Accounts
  
  
• Creating and Modifying User Accounts Using Active Directory Users and Computers
  • Adding Users to Groups
  • Saving Time with User Templates
    
    
• Creating Accounts Using Automation
  • Creating and Modifying User Accounts with Command-line Tools
  • Importing and Exporting User Accounts
    
    
• Troubleshooting User Accounts
  • Troubleshooting Account Lockouts
  • Troubleshooting Issues Related to User Account Properties
    
    
• Managing Local, Roaming, and Mandatory User Profiles
  • Creating and Modifying Local User Profiles
  • Creating and Modifying Roaming User Profiles
  • Creating and Enforcing Mandatory User Profiles

Creating and Managing Groups

• The Four Domain Functional Levels
  
  
• Group Type
  
  
• Group Scope
  • Domain Local Groups
  • Global Groups
  • Universal Groups
  • Recommended Sequence of Groups
  • Creating and Modifying Groups by Using the Active Directory Users and Computers Console
    
    
• Identifying and Modifying the Scope of a Group
  
  
• Managing Group Membership
  • Adding Accounts to Groups with Command-line Tools
    
    
• Finding Domain Groups in Which a User Is a Member
  
  
• Creating and Modifying Groups by Using Automation

Creating and Managing Computer Accounts in an Active Directory Environment

• Creating Computer Accounts Using the Active Directory Users and Computers Console
  
  
• Creating Computer Accounts by Joining the Domain
  
  
• Troubleshooting Computer Accounts
  
  
• Troubleshooting Issues Related to Computer Accounts by Using the Active Directory Users and Computers Console

Chapter Summary

Apply Your Knowledge

Study Strategies

In studying this section, be sure to practice all the activities described. Become very familiar with Active Directory Users and Computers, creating users and groups, resetting user and computer accounts, and defining roaming profiles and mandatory profiles. Microsoft is proud of the new command-line directory-management tools—dsquery, dsadd, dsmod, and dsget—so be sure you know what each one is for as well as how to use it. Also be sure to understand piping—sending the output from one command as the input to another.

Use both ldifde and csvde, but don't spend hours making them work. Understand what they are for, and get to know the command structure. Work through the exercises until you can explain authoritatively ldifde and csvde to a colleague.

You will need access to a Windows Server 2003 domain controller. Many of the tools are new or differ from those available in Windows 2000, so don't try to get by with a Windows 2000 domain controller.

You don't have to buy Windows Server 2003 to try it out. You can download a free evaluation version (which expires in 180 days) from http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx.

Introduction

Starting with this chapter, you're going to learn about some of the common daily duties of a Windows Server 2003 administrator. You can rest assured that you will be performing the tasks you learn in this chapter very often. This chapter discusses creating and managing user accounts, group accounts, and computer accounts, and setting up roaming profiles. Troubleshooting is a big part of the job, too. Troubleshooting entails helping users understand why they cannot connect to the network—whether it's because of locked-out user accounts, inoperative computer accounts, or other reasons. We'll be starting with user accounts. Let's get to it!

Creating and Managing User Accounts

User accounts are created so that people can identify themselves to the system and receive access to the network resources they need. In Windows Server 2003 with Active Directory enabled, user accounts (often called user IDs) are assigned using the Active Directory Users and Computers management console. On standalone Windows Server 2003 computers, user accounts are created using the User Accounts applet in Control Panel.

Every user should have a separate account. If there are problems with system usage or a security breach, it's necessary that the administrator be able to tell who was acting incorrectly. If all the engineers in a department logged on using a single account called "Engineer," it would be impossible to tell which one of the engineers was accessing the resources. Allocating separate accounts also allows each user to have access to exactly the resources needed and no more. Also, each user account can have its own private home directory—multiple users sharing a single account would have no such private storage.

The following subsections discuss three ways of creating and managing user accounts:

• Creating and managing accounts with the Active Directory Users and Computers management console

• Creating and managing accounts with automated processes

• Creating and managing accounts using bulk Import/Export tools

Creating and Modifying User Accounts Using Active Directory Users and Computers

This section explains how to use the Active Directory Users and Computers console, first to create user accounts and then to modify user accounts.

The Active Directory Users and Computers (ADUC) console is the most straightforward way to create and modify user accounts. It is accessible from Start, Administrative Tools, Active Directory Users and Computers; from the Manage Your Server Wizard; or by using Start, Run and typing dsa.msc in the Run dialog box.

When you start Active Directory Users and Computers, as shown in Figure 3.1, you will see a familiar Explorer-like display. In the left pane is a folder containing saved queries (we'll talk about queries later on) and an icon showing the name of the domain the managing computer is attached to (lantrainers.local, in this case). The right pane shows the contents of the container selected in the left pane. Because we have the domain selected in the figure, we see the containers that reside in the domain.

Figure 3.1 Selecting a container on the left pane displays its contents in the right pane.

Let's assume we're the network administrators for the Vancouver location of our organization, and we need to create some user accounts. Because the Vancouver Organizational Unit (OU) hasn't yet been created, we will need to do that. OUs are used in Active Directory to store users, groups, and resources. We'll create that OU and two more subordinate OUs below it in Step by Step 3.1.

STEP BY STEP

3.1 Creating OUs and User Accounts

1. In the left pane of the Active Directory Users and Computers console, select the top-level container in which you want to create the OU. In our example, the top-level container is lantrainers.local.

2. Right-click the container and choose New, Organizational Unit. Type the name Vancouver for the OU in the Name box.

3. Right-click the Vancouver OU and choose New, Organizational Unit. Type Users.

4. Repeat step 3, calling this Organizational Unit Workstations. We now have the organizational structure we want.

5. Right-click the Vancouver\Users container and select New, User.

6. Type the first and last names and the user logon name, as in Figure 3.2. In this organization, the default rule for creating the user logon name is the initial letter of the first (given) name, followed by the full last name (surname).

Figure 3.2 Fill in the name of the person for whom you are creating the user account.

7. Type the initial password for the user and repeat it in the confirmation field (see Figure 3.3). Accept the default password options.

Figure 3.3 In most organizations, the default password settings for a new user are reasonable.

8. Review the information in the confirmation dialog box and select Finish to create the user object.

9. We need a group account for a later exercise (groups are discussed later in this chapter), so let's create one now. Start by right-clicking Users in the left pane.

10. Choose New, Group and then create a global security group called Engineers. Click OK.

The account has now been created, and at this point the user could log in. However, there are many properties of the account that we have not yet set, so let's now look at how to modify a user account with Active Directory Users and Computers.

Once the user object has been created, you can select it and review or set its properties. Simply double-clicking the object in the right panel of ADUC opens a Properties dialog box, as shown in Figure 3.4.

Figure 3.4 Change any of the properties on the General tab of the user account dialog box.

Larger organizations generally have a list of the required information that must be entered for each user account. As an example, it may be mandatory to fill in the Office Location field, and there may be a fixed list of allowable entries. Like all fields in a user object, it is possible to search on the contents of the Office Location field. However, if one administrator enters Salt Lake, another enters SLC, and a third enters Salt Lake City, then how are users to search for that location? Requiring administrators to use office location names from a published list will resolve that problem.

The Address tab is available so that Active Directory can hold personal and business address information about the user. Most large organizations have personnel systems that carry this information, however, and these systems can use Active Directory or other database systems to store the data. Even if Active Directory is the directory system used to hold this employee data, the personnel system would update the directory programmatically, not via the Active Directory Users and Computers console.

The Account tab contains several useful entry areas. The Logon Hours button allows you to specify which hours during the week the user is permitted to log on to the system. The Log On To button lets you specify the NetBIOS or the fully qualified domain name (FQDN) of the computers the user is permitted to log on to. Among the Account options is the setting Smart Card Is Required for Interactive Logon, which, if activated, requires the user to present a smart card to log on directly to a server or workstation. In order for this to work, this smart card must be encoded with a certificate issued to the user, and a smart card reader must be installed on the computer. The smart card eliminates the need for a username and password; the user just needs the smart card and a personal identification number (PIN).

Account Expiration Date is the final entry area on the Account tab. Although we would expect most accounts to be valid indefinitely, for temporary employees, such as summer students, interns, or contractors, it is wise to specify the last date an account can be used (see Figure 3.5).

Figure 3.5 Use the End Of radio button to select a date after which the account will no longer be valid.

On the Profile tab, shown in Figure 3.6, in the User profile section you can specify where the user's profile data will be stored. We'll discuss profiles in depth later in this chapter, in the "Managing Local, Roaming, and Mandatory User Profiles" section. Also on the Profile tab, you can specify the name of the logon script (the scripted commands that will run on the user's behalf) when the user logs on.

In the Home Folder section of the Profile tab, you can specify the path where the user's home folder will be located. This can either be a path on the local computer or a network drive mapped to a shared folder on a server.

Figure 3.6 Enter values for profile path, logon script, and home directory location on this tab.

The next tabs all concern how the user interacts with Terminal Services—a method for having multiple users run programs in sessions that actually operate on a network server. The user can work at a low-function workstation (even one running Windows 95) and run programs that need the power and resources of a computer running Windows Server 2003.

The Remote Control tab, shown in Figure 3.7, allows the administrator to control whether a user's session can be controlled remotely. If Remote Control is enabled, the administrator can choose whether the user's permission is needed before the administrator can see the user's session. The administrator can also choose whether a session being controlled remotely can be operated by the administrator or merely viewed.

Figure 3.7 The Remote Control tab lets you specify whether the user's Terminal Services session can be controlled remotely.

Remote Control can be a very helpful facility for help desk staff. With the appropriate authorization, a help desk analyst can connect to a user's Terminal Services session and see what the user is seeing or is having difficulties with. If needed, the analyst can take control of the session to demonstrate how a task is to be performed or to investigate program settings. This is much more efficient than having the user describe to the analyst what is on the screen, and it's much faster than having the analyst go to the user's desk to see the problem.

The Terminal Services Profile tab allows the administrator to configure the user profile applied to the user's Terminal Services session. The administrator can specify the path of the profile to be used and the home folder location. These items can be different from the profile path and home folder location specified on the Profile tab. There is also a check box on which the administrator can determine whether the user is allowed to log on to the terminal server (see Figure 3.8).

Figure 3.8 Use the Terminal Services Profile tab to specify the profile path and home folder location for the user's Terminal Services sessions.

On the Environment tab, shown in Figure 3.9, the administrator can configure the startup environment a Terminal Services user sees. Any setting specified here will override the setting specified by the Terminal Services client. The administrator can require that a program start automatically at logon—when the user exits the program, the session will be logged off. This is a way of limiting users to a specific application instead of presenting them with a Windows Server 2003 desktop, which is the default. In addition, the administrator can control whether drives and printers on the client computer are available from the session, as well as whether print jobs are automatically sent to the default printer of the client computer.

Figure 3.9 Control the Terminal Services user's environment through settings on the Environment tab.

On the Sessions tab, shown in Figure 3.10, the administrator can specify what to do with Terminal Services sessions that are disconnected or left idle. A session is disconnected when the user disconnects rather than logging off or when the communication between the client computer and the Terminal Services server is broken. The administrator can choose to leave the disconnected session running forever, or only for a fixed period (such as 3 hours). The administrator can also specify how long an active session can continue, and how long an idle session can be left connected. When either of these limits is met, the session can be disconnected or ended. Finally, when the session has been disconnected, the administrator can specify whether reconnection is allowed from any client computer, or only from the client computer with which the disconnected session was initiated.

Figure 3.10 Specify how idle and disconnected sessions are handled on the Sessions tab.

On the Dial-In tab, shown in Figure 3.11, the administrator can determine whether a user can connect to a Windows Server 2003 machine remotely, either by a dial-in or a virtual private network (VPN) connection. When the domain is at the Windows 2000 native or Windows Server 2003 functionality level, remote access can be controlled through Remote Access Policy, which is substantially more sophisticated than a simple Allow Access or Deny Access setting. For example, a remote access policy can specify that only members of specific groups can access the network by dial-in, and then only from specific IP addresses and during stated periods in the day or week.

Figure 3.11 Control remote access on the Dial-In tab.

Also on the Dial-In tab, the administrator can choose to verify caller ID on the dial-in connection. The administrator can also require, for additional certainty, that only authorized locations are dialing in. By the administrator configuring the callback options, the server can break the connection as soon as authentication is complete and then call the user back at a preset telephone number. To ensure the company is paying the lowest rates for the call, the administrator can allow the server to return the call to a user-defined telephone number. Allowing the call to originate from the server location is most likely a less-expensive corporate long-distance rate package. In addition, the dial-in connection can be assigned the same static IP address each time, and TCP/IP routing can be defined.

Adding Users to Groups

To save administrative effort, it is much easier to specify that users are members of groups. With users belonging to groups you can allocate resource access permissions to the group one time rather than individually to each user in that group. For example, you might have 50 members of a human resource group. You can individually grant access to human resource files and folders to the 50 members, but that obviously could take a long time and leave you open to committing an error that potentially could breach the security of highly sensitive human resource data. Now, if you create a human resource group and add the 50 human resource members to the group, you can configure all 50 access levels to human resource data at one time by configuring the proper access permissions to the group. A one-time action that takes care of 50 individuals! Therefore, it is useful to create groups, allocate members to those groups, and grant resource access permissions to the groups.

There are two ways to allocate users to groups. You can either open the Membership property of a group and add users to it, or you can open the Member Of property of a user and select the groups to which that user will belong. Step by Step 3.2 shows you how to make a user a member of a group.

STEP BY STEP

3.2 Adding a Member to a Group

1. In Active Directory Users and Computers, navigate to a user account object and open its properties.

2. Select the Member Of tab and view the existing memberships. By default, new users created in a domain are only members of the Domain Users group, as shown in Figure 3.12.

Figure 3.12 A new user is a member only of the Domain Users group.

3. Click the Add button to bring up the Select Groups dialog box. Type the name of the group and then click the Check Names button. Figure 3.13 shows the results of typing "Engineers" and then selecting Check Names.

Figure 3.13 Adding a user to the Engineers group.

4. Click OK to complete the addition of the Engineers group to the user account and to see the new list of groups to which the user belongs.

5. Click OK to close the user's properties.

Saving Time with User Templates

In most organizations, many people have the same resource access needs. Perhaps all Vancouver engineers need print and management access to a particular printer, and read and write access to two shared folders. Also, staff in a particular location may have the same logon hours or other information, which is the same from person to person.

Rather than laboriously entering the same information for each user account, it's easier to create one account as a template and then copy that account whenever you need to create another user account with the same characteristics.

To do this, create a new user account and give it a display name that will cause it to be shown at the start of the username list in the container in Active Directory Users and Computers. Because special characters sort first, a name such as _Engineer or _Engineer Template would work well. Assign the account to the groups the users will be in, specify logon hours and logon computer restrictions, and enter the information on the Address, Account, Profile, and Organization tabs that you want to apply to all users. It's a good idea to disable the template account so that when new accounts are created from the template, they will be disabled also. This ensures new accounts won't be automatically available to anyone with malicious intent who knows who the new hires will be.

As an example of a user template, note the Organization page of the _Engineer account shown in Figure 3.14. This is the template account used to create the Test Engineer account.

Figure 3.14 The template account should have commonly needed information in the fields of the Organization tab.

Once the template has been created, all you have to do to create a new user with the same characteristics is right-click the template account and choose Copy. You enter the username, user ID, and password of the specific user, and the resulting account has both the specific information for an actual user and the necessary ancillary information applicable to all users in the group because most of it was already entered into fields in the template account.

When a new account for Test Engineer was created by copying the _Engineer account, most of the information on the Organization tab was carried over, as you can see in Figure 3.15.

Figure 3.15 The Title field was not copied to the new account.

You might be wondering which attributes are copied to a new account created by copying a template. The values included in any attributes marked "Attribute Is Copied when Duplicating User" in the Active Directory Schema snap-in will be included in the copied account. With the necessary privileges, you can change which attributes are copied and which are not.

When creating template accounts, consider making separate templates for temporary employees. If your organization is planning to hire several summer students, set up a template with the account-expiration dates set to the end of the summer. This way, all the users created using the _Summer Intern template will have the correct expiration already set when the accounts are created.

A good rule when creating template accounts is that you want to have a new template account for every set of new user types that might have unique information prepopulated. For example, in the case of the summer interns, their accounts are unique because of the expiration date. Using the _Summer Intern template would not be appropriate for a new employee whose account will not expire, and vice versa. You might decide to create template accounts for the different departments in your company or for those who have different work hours or managers. The key thing to remember is that the template you use must match the characteristics of the user you are creating. Otherwise, information will be automatically placed in the user account properties (via the template copy) that is not relevant for that user.

Creating and Modifying User Accounts with Command-line Tools

New in Windows Server 2003 are several command-line tools that can help in automating the creation and modification of user accounts:

• dsadd—Used to create Active Directory objects

• dsget—Used to retrieve specific properties of a user account

• dsmod—Used to change a property in a user account

• dsmove—Used to move or rename an Active Directory object

• dsrm—Used to delete Active Directory objects

The first one we'll discuss is dsadd, which adds accounts to the Active Directory service.

Creating Accounts with dsadd

The dsadd command can be used to create several types of objects in Active Directory. You can consider these to be subcommands of the dsadd command:

• dsadd computer—Adds a computer to the directory

• dsadd contact—Adds a contact to the directory

• dsadd group—Adds a group to the directory

• dsadd ou—Adds an Organizational Unit to the directory

• dsadd user—Adds a user to the directory

• dsadd quota—Adds a quota specification to a directory partition

To learn how to use the dsadd command, open a command prompt and enter the following:

dsadd /?

To learn about the use of the subcommands, at the command prompt enter the following:

dsadd user /?

The dsadd user command can take several parameters, but the only required one is DN (distinguished name).

What's a distinguished name? It is the name assigned to an object in Active Directory, and it's made up of the object name (for example, Bill Bailey), the container it resides in, and the list of all the parent containers of that container, right up to the domain. Here's the distinguished name for Bill Bailey:

"CN=Bill Bailey,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"

The following list examines the parts of this name:

• CN=Bill Bailey—CN stands for common name. It can be used for users, groups, computers, and containers.

• OU=Users,OU=Vancouver,OU=LTI—OU stands for Organizational Unit, and this string lists all the containers in order, from the one the object resides in, up to the first container below the domain object.

• DC=lantrainers,DC=local—DC stands for domain component, and we need a DC for each part of the fully qualified domain name (FQDN) of the domain, lantrainers.local.

Windows Server 2003 will not permit you to create more than one object with exactly the same distinguished name so that you can be sure a distinguished name refers to a unique object. A good example of this is the Users OU we created earlier. Although its name is the same as the Users container that is created by default, the distinguished name is unique. With that knowledge in mind, you now know that we can create a new user in the same container as Bill Bailey's with the following command:

dsadd user "CN=Tom Thomson,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local"

Having run this command, we return to Active Directory Users and Computers, and after refreshing the contents of the Users container under Vancouver, we see the new user object, as shown in Figure 3.16.

Figure 3.16 The user object for Tom Thomson now exists.

If you look at the properties of the object, you will see that none of the user-defined fields have been filled in. Note that, by default, the account is shown as disabled.

Obviously, using dsadd in this way doesn't save us much time if we later have to go into the properties of the object manually to add the user's details. However, all the usually defined properties can be included in the dsadd command, along with the distinguished name, so the whole object-creation process, including the user details, can be automated.

The following is a partial list of the properties that can be included with the dsadd command (from dsadd user /?):

• -samid—The user ID in a form that is usable with non–Active Directory accounts management.

• -upn—The user principal name is an alternate name that can be used for logon. In place of the usual domain\user, you can enter name@domain. For example, Bill Bailey could log on as bbailey@lantrainers.local.

• -fn—The user's first name.

• -mi—The user's middle initial.

• -ln—The user's last name.

• -display—The name that denotes the account in listings, such as in Active Directory Users and Computers.

• -empid—An EmployeeID field.

• -pwd—This field can contain the password to be assigned to the account. If you want to be prompted for a password when creating the account, enter *. This wildcard is probably not appropriate for mass-creating users because the script will stop each time a user is created asking for a password.

• -desc—A description of the user.

• -memberof—A list of distinguished names of the groups the user should be made a member of.

• -office—The name of the user's office.

• -tel—The user's main phone number.

• -email—The user's email address.

• -webpg—The user's Web page address.

• -title—The user's title.

• -dept—Department.

• -company—Company.

• -mgr—The manager of this user.

• -hmdir—The path to the user's home directory.

• -hmdrv—The drive letter assigned to the user's home directory.

• -mustchpwd—The user must change the password at next logon: {yes | no}.

• -canchpwd—The user is able to change the password: {yes | no}.

• -reversiblepwd—The password is stored with reversible encryption (used with Macintosh systems and digest authentication): {yes | no}.

• -pwdneverexpires—The password does not expire: {yes | no}.

• -acctexpires—The number of days until the account expires.

• -disabled—The account is disabled: {yes | no}.

• -q—The command should run with no output to the console.

Using as many of these parameters as are necessary to define the user account, the administrator can create the account with a single command, like this:

dsadd user "CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" -samid ALismer -upn alismer@lantrainers.local -fn Arthur
-ln Lismer -pwd Passw0rd -memberof "CN=Vancouver Users,OU=LTI,
DC=lantrainers,DC=local" -office Vancouver -disabled no
-mustchpwd yes

"But wait," you say, "that's more effort than working my way through Active Directory Users and Computers to create a user." That's true, for one user. However, if you're creating a thousand of them, and you have their names in a spreadsheet, it takes very little work to create a batch file where each line in the file creates another user.

Once you have invested the time to master dsadd, you can save huge amounts of time in creating large numbers of user accounts.

Listing the Properties of User Accounts with dsget

If you want to get the value of some properties of a user account with a command-line tool, you use dsget user. The syntax of the command is as follows:

dsget user <dn> <list of properties>

The properties you can use are shown in the following list, from Windows Server 2003 Help and Support:

• -dn—Shows the DN of the user.

• -samid—Shows the SAM account name of the user.

• -sid—Shows the user's Security ID.

• -upn—Shows the user principal name of the user.

• -fn—Shows the first name of the user.

• -mi—Shows the middle initial of the user.

• -ln—Shows the last name of the user.

• -display—Shows the display name of the user.

• -empid—Shows the user employee ID.

• -desc—Shows the description of the user.

• -office—Shows the office location of the user.

• -tel—Shows the telephone number of the user.

• -email—Shows the email address of the user.

• -hometel—Shows the home telephone number of the user.

• -pager—Shows the pager number of the user.

• -mobile—Shows the mobile phone number of the user.

• -fax—Shows the fax number of the user.

• -iptel—Shows the user IP phone number.

• -webpg—Shows the user's Web page URL.

• -title—Shows the title of the user.

• -dept—Shows the department of the user.

• -company—Shows the company info of the user.

• -mgr—Shows the user's manager.

• -hmdir—Shows the user's home directory. It also displays the drive letter to which the home directory of the user is mapped (if the home directory path is a UNC path).

• -hmdrv—Shows the user's home drive letter (if home directory is a UNC path).

• -profile—Shows the user's profile path.

• -loscr—Shows the user's logon script path.

• -mustchpwd—Shows whether the user must change his or her password at the time of next logon. Displays yes or no.

• -canchpwd—Shows whether the user can change his or her password. Displays yes or no.

• -pwdneverexpires—Shows whether the user's password never expires. Displays yes or no.

• -disabled—Shows whether the user account is disabled for logon. Displays yes or no.

• -acctexpires—Shows when the user account expires. Displays a value (a date when the account expires or the string never if the account never expires).

• -reversiblepwd—Shows whether the user password is allowed to be stored using reversible encryption. Displays yes or no.

For example, the command

dsget user "CN=Najma Lakhani,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" -fn -ln -desc -office

returns the following information:

desc             fn     ln       office
Senior Engineer  Najma  Lakhani  Vancouver

This command can be very useful in determining the values of the properties of one or several user accounts.

Modifying User Accounts with dsmod

You've probably been wondering what you would do if you had to make a change to hundreds or thousands of users. Well, just as dsadd allows you to automate the creation of users, dsmod allows you to change them.

dsmod uses the same parameters as dsadd, so you indicate the account you want to change with its distinguished name and then specify the parameter and the value it should have. For example,

dsmod user "CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local"–office Burnaby

would change the value of the office parameter to Burnaby, while leaving all the other parameters unchanged.

Using Piping Commands

If you're like some administrators, you took one look at the dsmod command in the previous paragraph and said, "There's too much work in typing distinguished names! I'm sticking with Active Directory Users and Computers!"

This is where piping comes in. Piping allows you to use the output of one command as the input for a second command. If you can issue a dsquery command that finds the Arthur Lismer user object, you can pipe (using the | symbol on the keyboard) the output from the dsquery command into the dsmod command. Let's walk through this:

C:\>dsquery user -name arthur*
"CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"
"CN=Arthur Adams,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"

No, that produced too many Arthurs. Let's try this:

C:\>dsquery user -name *lismer
"CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"

There we go, just the user we wanted. Now let's pipe the output of dsquery into dsget to find the current value of the office parameter:

C:\>dsquery user -name *lismer | dsget user –office
 Office
 Vancouver
dsget succeeded

Good. Now we change the value of the office parameter with a dsmod command:

C:\>dsquery user -name *lismer | dsmod user -office Burnaby
dsmod succeeded:CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,
 DC=lantrainers,DC=local

And now we can confirm that the change was made:

C:\>dsquery user -name *lismer | dsget user –office
 Office
 Burnaby
dsget succeeded

This is much more efficient than typing long distinguished names! And if you use a dsquery that returns several user accounts, the dsmod command can modify the same field in all the returned accounts, all at once.

For example, as in the preceding example when we changed the office location, typing the following command changes the user's telephone number without typing the DN:

C:\>dsquery user -name *lismer | dsmod user –tel 803-734-1122

You can use similar logic to change any other piece of information in the directory by simply searching for the user's name, UPN, location in the directory, or even several other parameters you can see when using dsquery user /?. Hopefully, you are starting to see that the power of these commands is far greater than what it first appears.

Moving or Renaming Objects with dsmove

If you need to move an object to another location within Active Directory, or you want to rename the object, you can do so with dsmove. The syntax of dsmove is as follows:

dsmove <ObjectDN> [-newparent <ParentDN>] [-newname <NewName>]

So if Najma Lakhani moves from Vancouver to Calgary, and she changes her name to Najma Larson, we could accomplish the change with the following command:

C:\>dsquery user -name "Najma*" |dsmove -newparent
"OU=Users,OU=Calgary,OU=LTI,DC=lantrainers,DC=local"
 -newname "Najma Larson"

Checking in Active Directory Users and Computers shows Najma Larson in the new OU. Note that only the object name has changed. To complete the user's name change, properties of the object such as display name, last name, and email address will still have to be modified with dsmod or Active Directory Users and Computers.

Removing Objects with dsrm

The final command-line tool for Active Directory is dsrm. It is used to delete Active Directory objects. If the object being referenced is a container, it's possible to delete the objects in the container but retain the object itself.

The syntax for dsrm is as follows:

dsrm <ObjectDN ...> [-noprompt] [-subtree [-exclude]]

• -noprompt—Do not prompt for confirmation before deleting object.

• -subtree—Delete the object and all objects included in it.

• -exclude—Used with subtree. Do not delete the object, just its contents.

For example, assume the Calgary office has just completed a Systems Analysis course and wants to delete the accounts that were created for students in the course. The accounts were in the OU called AnalysisStudents under the "OU=Calgary,OU=LTI,DC=lantrainers, DC=local" OU. The AnalysisStudents OU should be retained for future classes. The following command will delete all the objects in the AnalysisStudents OU but retain the OU:

C:\>dsrm "OU=AnalysisStudents,OU=Calgary,OU=LTI,DC=lantrainers,DC=local"
 -subtree -exclude
Are you sure you wish to delete all children of
OU=AnalysisStudents,OU=Calgary,OU=LTI,DC=lantrainers,DC=local (Y/N)? y
dsrm succeeded:OU=AnalysisStudents,OU=Calgary,OU=LTI,
DC=lantrainers,DC=local

Importing and Exporting User Accounts

Some organizations occasionally have a need to create, modify, or delete thousands of user accounts at a time. Think of a large university, with an incoming class of several thousand students at the start of each term. You certainly wouldn't want to create each of those accounts with Active Directory Users and Computers!

What saves the day here is two facts: Almost certainly there is a database somewhere in the organization that has all the information needed to define the needed accounts, and Microsoft has provided two programs with Windows Server 2003, ldifde and csvde, that can be used to import accounts into Active Directory.

To create the thousands of user accounts, you would export the necessary information from the database system, manipulate the data so that it is in the format the import program needs, and then run the import program. It may take some time to go through these steps, but that's better than many days of tedious and error-prone work with Active Directory Users and Computers.

Why are there two import utilities, and how do they differ? The next sections answer those questions. csvde is simpler, so we'll discuss it first.

The csvde Utility

The csvde (Comma Separated Value Directory Exchange) utility exports data from Active Directory, or imports data into Active Directory, in Comma Separated Value (CSV) format. In this format, each line of data represents one record, and each field is separated from the next by a comma. If any field has commas as part of the data, the whole field is enclosed by quotation marks. So that the import utility can properly allocate each value to the appropriate field, the first line of the data file lists the names of the fields in the order they will appear in the data records.

As an example, here is the output from csvde of the Arthur Lismer record in our sample company:

DN,objectClass,ou,distinguishedName,instanceType,whenCreated,whenChanged,
uSNCreated,uSNChanged,name,objectCategory,dSCorePropagationData,
cn,sn,physicalDeliveryOfficeName,givenName,displayName,
userAccountControl,codePage,countryCode,accountExpires,
sAMAccountName,userPrincipalName,description,mail,c,l,st,
title,postalCode,co,department,company,streetAddress,
userWorkstations,manager"CN=ArthurLismer,OU=Users,OU=Vancouver,
OU=LTI,DC=lantrainers,DC=local",user,,"CN=ArthurLismer,OU=Users,
OU=Vancouver,OU=LTI,DC=lantrainers,DC=local",4,20030421210344.
0Z,20030421210345.0Z,33732,33738,ArthurLismer,"CN=Person,
CN=Schema,CN=Configuration,DC=lantrainers,DC=local",
,ArthurLismer,Lismer,Vancouver,Arthur,
,512,0,0,9223372036854775807,ALismer,alismer@tlantrainers.local
,,,,,,,,,,,,,

The first line (starting DN,objectClass... is the header line, listing the fields in the data. The second line is the data for the Arthur Lismer record. It's hard to read, but if you load it into a spreadsheet program, each field will be in a separate column, and it's easy to work with then.

This output was created with the following command:

csvde -f c:\lismer.csv -r "(name=*lismer)"

The parameter -f c:\lismer.csv sends the output of the command to the file c:\lismer.csv, and the parameter -r "(name=*lismer)" tells the utility to select just those records whose name field ends in lismer.

To make the output of csvde easier to use, you can specify the fields you want to have exported. For example, the command

C:\>csvde -f c:\lismer.csv -r "(name=*lismer)" -l
l,company,objectclass,name,title,company,l,telephoneNumber,
userAccountControl,samaccountname

results in the simpler output file

DN,objectClass,title,telephoneNumber,company,name,
userAccountControl,sAMAccountName "CN=Arthur
Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local",user,Network Architect,555-5678,Thomson Associates,
Arthur Lismer,512,Alismer

It is useful to run csvde in output mode first, to list the names of the attributes.

Now, to import a user, we make a text file in the same format as the output files and then run csvde in import mode. For example, let's run the command

csvde -i -f c:\adams-in.csv -j c:\

with the following input file:

DN,objectClass,title,telephoneNumber,company,name,userAccountControl,
sAMAccountName"CN=ArthurAdams,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local",user,Network Architect,555-5678,
Thomson Associates,Arthur Adams,514,Aadams

This creates a user account for Arthur Adams, with the attributes listed. Note that we have used the userAccountControl value of 514, which means the account is disabled when it is first created. This is because our work is not yet done because we haven't assigned the user to any groups and we haven't set the user's password. We can complete these tasks with the dsmod utility and then enable the account.

The ldifde Utility

The name of this utility, ldifde, means LDIF Directory Exchange. LDIF (LDAP Data Interchange Format) is a definition of how data can be exchanged between LDAP-based directories. LDAP (Lightweight Directory Access Protocol) is an industry-standard protocol for accessing directories. For complete information about LDAP, see RFCs 2251–2256, and for information on LDIF, see RFC 2849, which can be read at http://www.ietf.org/rfc/rfc2849.txt.

There are two primary differences between ldifde and csvde. First, whereas csvde can only import and export records, ldifde can also modify records and delete records, making it a much more powerful utility. Second, the data format is very different. Instead of a file with a header record and one record per entry, the file contains many lines per entry, with the field name as the first part of each line.

Here is what the ldifde output looks like for the Arthur Lismer user account. Note that an entry starts with the distinguished name (dn) of the entry, then a changetype line (the changetype command can be add, modify, or delete), and then the attributes of the entry, in alphabetical order by attribute name:

dn: CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local
changetype: add
accountExpires: 9223372036854775807
cn: Arthur Lismer
codePage: 0
countryCode: 0
distinguishedName: CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local
givenName: Arthur
instanceType: 4
name: Arthur Lismer
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=lantrainers,
DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
physicalDeliveryOfficeName: Vancouver
sAMAccountName: ALismer
sn: Lismer
userAccountControl: 512
userPrincipalName: alismer@tlantrainers.local
uSNChanged: 33738
uSNCreated: 33732
whenChanged: 20030421210345.0Z
whenCreated: 20030421210344.0Z

To use ldifde to create a series of user accounts, we'll need to build an input file of records in the format shown.

The following input file was used with the command

Ldifde -i -f c:\ldif-in1.txt

to create a new user account for Frank Carmichael:

dn: CN=Frank Carmichael,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local
changetype: add
cn: Frank Carmichael
codePage: 0
countryCode: 0
distinguishedName: CN=Frank Carmichael,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local
givenName: Frank
instanceType: 4
name: Frank Carmichael
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=lantrainers,
DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
physicalDeliveryOfficeName: Vancouver
sAMAccountName: FCarmichael
sn: Carmichael
userAccountControl: 514
userPrincipalName: fCarmichael@tlantrainers.local

Using dsmod as described earlier, we can add three users' accounts to the Vancouver Users group with this command (entered as a batch file):

dsmod group "CN=Vancouver Users,OU=LTI,DC=lantrainers,DC=local" -addmbr
 "CN=Tom Thomson,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"
 "CN=Arthur Adams,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local"
 "CN=Frank Carmichael,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" –c

A second dsmod command sets all these users' passwords to Secur1ty and requires them to change their passwords at the next logon:

dsmod user "CN=Tom Thomson,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" "CN=Arthur Adams,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" "CN=Frank Carmichael,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local" -pwd Secur1ty -mustchpwd yes

And a final dsmod command enables the three accounts:

dsmod user "CN=Tom Thomson,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" "CN=Arthur Adams,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" "CN=Frank Carmichael,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local" -disabled no

Using the -c Parameter

A common use for ldifde is to create a set of objects in a new directory from an existing one. For example, you might be creating a set of user accounts in a new test directory from the user accounts in a production directory.

It's a fairly simple process to use ldifde in export mode to create a file containing information about the existing user accounts. Then running ldifde in import mode will load the accounts into the new location. However, the distinguished names will all have to be changed because they will refer to the source directory.

For example, imagine that we are setting up a test domain called lantrainers.com. We want to populate the new directory with information exported from our lantrainers.local domain. All the information about the accounts will be the same, but the Active Directory paths will be different in all the distinguished names.

This is where the –c parameter is used. Using ldifde with –c <old string> <new string> causes the replacement of any occurrences of <old string> by <new string> before the data is acted on by ldifde.

Troubleshooting User Accounts

There are several reasons why users may find that they cannot use their user accounts. In this section we will look at account lockouts and at reasons why an account might not be usable.

Troubleshooting Account Lockouts

Account lockout is a Windows Server 2003 security feature designed to protect accounts from repeated attempts to guess the account's password. A policy can be set that causes a user account to be disabled if a specific number of invalid login attempts are made within the specified timeframe. The account is disabled for a specific number of minutes; if the specified timeframe passes without another invalid attempt, the count of invalid attempts is reset to zero. Figure 3.17 shows the default settings if you enable account lockout in the Group Policy Object Editor.

Figure 3.17 The default settings for account lockout.

The term invalid logon attempt includes attempts to guess a password that is protecting a workstation's session, whether with a password-protected screensaver, a Ctrl+Alt+Del Lock Workstation command, the initial login dialog box, or from across the network.

Table 3.1 shows the default values and the ranges of possible values for the account lockout feature.

Table 3.1 Default Values for Account Lockouts

Setting	Default Value	Range of Values
Account lockout duration	30 minutes	From 0–99,999 minutes. A setting of 0 means the account is locked out until an administrator unlocks it.
Account lockout threshold	Five invalid attempts	From 0–999. A setting of 0 means account lockout will not be used.
Reset lockout counter after	30 minutes	From 1–99,999 minutes.

Many administrators initially set the account lockout duration to 0 so that they will always know if an attempt was made, and this is certainly the most secure approach. However, a few irate calls from locked-out users usually results in a setting of 30 or 60 minutes!

If a user account is locked out, you can allow it to be used again with Active Directory Users and Computers. Figure 3.18 shows the location.

Figure 3.18 Allow the account to be used by clearing the Account Is Locked Out check box.

To implement account lockout, modify the Default Domain Policy (in the Group Policy tab of the domain object of Active Directory Users and Computers). The account lockout settings are found under Computer Configuration, Windows Settings, Security Setting, Account Policies, Account Lockout Policy.

Like password policies, account lockout can be defined only at the domain level. So be careful—all password policy settings will affect every user account in your domain!

Account lockout is a security feature that must be put in place for any production network to be considered secure. Be sure you have management agreement with any new account password settings, and give your user community several days' warning before you implement it.

Troubleshooting Issues Related to User Account Properties

Many help desk analysts will tell you that a large portion of the calls they receive have to do with settings on the user account. Here are several situations that arise because of settings on user account properties.

Account Disabled

It is common practice to disable the account of any user who is either on leave for an extended period or no longer with the organization. Of course, when the user returns and attempts to use the account, she will be unable to log on.

A disabled account can easily be enabled. With Active Directory Users and Computers, open the properties of the user account. On the Account tab, clear the Account Is Disabled check box. Alternatively, you can use dsmod and enter the following:

dsmod user <distinguished name> -disabled no

Account Expired

We know that an account can have an expiration date—the date after which the account cannot be used. If a temporary worker's contract is extended and the network administrator has not been asked to adjust or remove the account expiration date, the worker will not be able to log in until the expiration date is reset.

This setting can be modified in Active Directory Users and Computers: Open the properties of the user account, then on the Account tab, in the Account Expires section, select either Never or a new date. Alternatively, with dsmod, you can enter

dsmod user <distinguished name> -acctexpires never

or

dsmod user <distinguished name> -acctexpires <number of days>

Dial-in Disallowed

A user might complain of being unable to connect by dial-in connection or through a virtual private network (VPN) connection. In this case, check the Dial-In tab of the user accounts properties, as shown in Figure 3.19.

Figure 3.19 If the Remote Access Permission setting is Deny Access, no dial-in or VPN connections will be allowed.

To permit dial-in or VPN connections, select Allow Access or, in domains where the functional level is at least Windows 2000 native, Control Access Through Remote Access Policy.

Cannot Change Password

In some cases, users call the help desk because the operating system does not allow them to change their password. There are two possible reasons for this situation.

First, the account may have been set up with the User Cannot Change Password option. This situation is easily rectified, if appropriate, by going to the Account tab of the user account Properties dialog box and clearing the check box.

Second, a user may be unable to change the user account's password because the password entered does not meet the complexity requirements determined by the domain account policies. If enabled, this policy requires that passwords meet the following minimum requirements:

• Not contain all or part of the user's account name

• Be at least six characters in length

• Contain characters from three of the following four categories:

• English uppercase characters (A through Z)

• English lowercase characters (a through z)

• Base 10 digits (0 through 9)

• Nonalphabetic characters (for example, !, $, #, %)

If the user's password change is being denied due to password complexity requirements, minimum password age, or other restrictions, you must explain the requirements to the user.

Guided Practice Exercise 3.1

You are the administrator of a network for a manufacturing company that has multiple Windows Server 2003 servers used for file and print services.

Common to most manufacturing entities is the need to protect sensitive design data from industrial espionage. The products that your company manufactures are for very price-conscious consumers—not only the design of the products, but also the manufacturing techniques, must be protected.

You need to find a way to minimize the exposure of external users hacking in to your servers.

Using the things that you have learned so far in this chapter, what is the best way to solve this issue in Windows Server 2003? On your own, try to develop a solution that would involve the least amount of downtime and expense.

If you would like to see a possible solution, follow these steps:

Estimated Time: 40 minutes

This is a fairly straightforward decision, mainly because the only security features we have discussed so far are user accounts and passwords. To increase security in your domain, you can modify the default domain policy to adjust the account-lockout settings so that hackers can't repeatedly try different passwords to access your servers. In addition, you can require complex passwords so that dictionary attacks won't be effective.

1. From the Start menu, select All Programs, Administrative Tools, Active Directory Users and Computers.

2. Right-click the domain name entry and select Properties from the pop-up menu.

3. From the Properties dialog box, click the Group Policy tab.

4. On the Group Policy tab, double-click the Default Domain Policy entry.

5. From the Group Policy MMC, navigate to Default Domain Policy, Computer Configuration, Windows Settings, Security Settings, Account Policy, Password Policy. Ensure the following settings are applied:

• Account Lockout Threshold—3

• Account Lockout Duration—60

• Passwords Must Meet Complexity Requirements—Enabled

6. Close the MMC and then click OK on the Properties dialog box to save.

With the lockout threshold set, the account will be locked after three failed logon attempts, and it will be reenabled automatically after 1 hour. Passwords will be required to meet the complexity requirements discussed earlier in this chapter.

Managing Local, Roaming, and Mandatory User Profiles

The settings for a user's work environment are stored in a set of files and folders known as the user profile. The profile is automatically created the first time a user logs on to a computer running any version of Windows, and any changes to the environment (Favorites, Start menu items, icons, colors, My Documents, local settings) are saved when the user logs off. The profile is reloaded when the user logs on again. Table 3.2 lists the components of a user profile (from Windows Server 2003 Help and Support).

Table 3.2 User Profile Folders and Their Contents

User Profile Folder	Contents
Application Data	Program-specific data (for example, a custom dictionary). Program vendors decide what data to store in this user profile folder.
Cookies	Web site user information and preferences.
Desktop	Desktop items, including files, shortcuts, and folders.
Favorites	Shortcuts to favorite Internet locations.
Local Settings	History and temporary files.
My Documents	User documents and subfolders.
My Recent Documents	Shortcuts to the most recently used documents and accessed folders.
NetHood	Shortcuts to My Network Places items.
PrintHood	Shortcuts to printer folder items.
SendTo	Shortcuts to document-handling utilities.
Start Menu	Shortcuts to program items.
Templates	User template items.

The user profiles facility allows several people to use the same computer running Windows, yet each can see his or her own private desktop, and the settings will be remembered each time the user logs on.

Initially, the profile exists only on the computer where it was created: For this reason, it is called a local user profile. However, the profile can also be stored on a server, allowing the user to see the same desktop no matter what machine he or she is logged on to. This server-based profile is known as a roaming user profile. For some groups of users, we can also create mandatory user profiles, which cannot be changed by the users.

Creating and Modifying Local User Profiles

The first time a user logs on to a computer running Windows Server 2003, the folder structure shown in Figure 3.20 is created. This structure used the data and shortcuts contained in the DefaultUser profile as a template. In Figure 3.20 you see the Administrator profile.

Figure 3.20 The folder structure of a user profile.

The folders of interest in the structure are Application Data, where software vendors store data for particular users, Cookies, where data about Web site preferences are stored, Desktop, which contains the desktop items, including any files stored there, My Documents, which is the default location for the storage of user data, and Start Menu, from which programs can be accessed that were installed for this user, but not all users of this computer.

Within the root folder of the profile, you will see a file called NTuser.dat. This file contains the contents of the current user-specific section of the Registry (HKEY_CURRENT_USER). This file is updated each time the user logs off.

Another profile structure that is used to create the user work environment is the All Users folder. Profile items that all users will see, such as program links that are on all users' All Programs menu, are stored in the All Users folder.

The contents and settings of the user profile are modified by working with the environment—using Control Panel applets such as Display, installing programs, and creating shortcuts on the desktop.

Creating and Modifying Roaming User Profiles

Because many users move from computer to computer and would like to see the same work environment each time, the Roaming User Profiles facility has been created. This facility allows the profile to be stored on a network server. When the user logs on, the profile is downloaded from the server, and the expected work environment is seen. When the user logs off, the profile is uploaded to the server, so any changes made are available for the next logon at that or any other computer.

To assign a roaming profile to a user using Active Directory Users and Computers, go to the Profile tab on the user accounts Properties dialog box and enter a valid path in the Profile field, as shown in Figure 3.21.

Figure 3.21 Use the %username% variable to substitute for the username.

The next time the user logs on, the profile type will be changed to "Roaming," and after logoff the server-based profile will be updated.

Note that Active Directory Users and Computers will allow you to change some properties of multiple user accounts at once. That is, you can select multiple users and then choose Action, Properties and set the values for those properties. See Figure 3.22 for the Profile tab of the Properties on Multiple Objects dialog box.

Figure 3.22 Changing the home folder and profile path on multiple user accounts at once.

You can also use dsmod to set the home folders and profile paths for multiple users. The following command entered as a batch file, for convenience, sets the profile path and the home folder path simultaneously:

dsmod user "CN=Tom Thomson,OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" "CN=Arthur Lismer,OU=Users,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=local" "CN=Arthur Adams,OU=Users,OU=Vancouver,
OU=LTI,DC=lantrainers,DC=local" -profile "\\mars\users\
$username$\profile" -hmdrv x: -hmdir \\mars\users\$username$

Creating and Enforcing Mandatory User Profiles

You might want to ensure that the profiles for a specific group of users are the same for all the users and unchangeable. A preconfigured profile that is not allowed to be changed by the user is called a mandatory user profile. You might want to set up a mandatory user profile for a group of user accounts, all of whom do the same limited set of tasks, such as an inside sales group.

To set up a mandatory user profile, first create a temporary user account and assign a profile path (such as \\mars\profiles\Adams) in Active Directory Users and Computers. Ensure that the user has permissions to update files in the profile path. Once the profile path is defined, the user has a roaming profile. Log on as that user, make the changes to the work environment (appearance of the desktop, icons available, programs installed, and so on) that are appropriate for the group of users, and then log off.

Log on again as an administrator, navigate to the user's profile folder, and rename the NTuser.dat file to NTuser.man.

To test that the mandatory profile is working, log on as the temporary user, change some settings, and log off. Log on again as the same user, and you should see that the changes you made in the previous session were discarded.

The template user account now has a mandatory user profile assigned. You can assign the same mandatory user profile to any number of user accounts by adding the profile path to the Profile tab of ADUC. In addition, all users or groups who will be assigned the mandatory profile must be granted Write permissions for the folder.

Creating and Managing Groups

It's much easier to administer a network when you can manage several users at once. We can expect that all members of a given section of an organization will have the same needs in accessing data or using printers, and it's also likely that they should be subject to the same security restrictions. Rather than granting individual users the rights to print to a particular printer or to update files in a given folder, we can allocate those rights to a group object. Making user accounts members of the group automatically grants them any rights that group object has.

Windows Server 2003 has a number of different ways of defining groups of user accounts. We'll describe the different methods a little later, but first you have to understand that Windows Server 2003 domains can be in four different functional levels, and those levels impact what types of groups are possible and what nesting of those groups can be done. (The functional levels have implications related to other capabilities as well, such as Active Directory replication efficiencies, but we're only interested in group behavior here.)

The Four Domain Functional Levels

When the Windows Server 2003 version of Active Directory is installed, a basic set of features is enabled that allows the new domain controller to retain backward compatibility with older domain controllers running Windows NT 4.0 or Windows 2000. As these older domain controllers are removed from the network, the administrator can enable the additional features by raising the domain functional level. The domain functional level determines what features are available and whether or not older domain controllers are supported. Here are the four domain functional levels:

• Windows 2000 mixed—The default level in Windows Server 2003, this level is equivalent to mixed mode in Windows 2000. At this level, a domain can contain domain controllers on computers running Windows NT, Windows 2000, or Windows Server 2003. This flexibility comes with a price, as you'll see, because at this level you cannot use the enhanced group features available in either Windows 2000 or Windows Server 2003.

• Windows 2000 native—Once you have removed all Windows NT domain controllers from the domain, you can increase the domain functionality level to Windows 2000 native. At the Windows 2000 native level, you get the improved group capabilities of Active Directory as delivered in Windows 2000, such as the ability to "nest" groups and the availability of groups of Universal scope.

• Windows Server 2003 interim—Both Windows NT and Windows Server 2003 domain controllers can exist in a domain at this level. As with the Windows 2000 mixed level, enhanced group functionality cannot be used.

• Windows Server 2003—Only domains that have no Windows 2000 or Windows NT domain controllers can be raised to this level of domain functionality. This is the most advanced level of domain functionality. Although important enhancements are achieved in upgrading from Windows 2000 to Windows Server 2003 Active Directory, there are no significant differences in group functionality between the two levels.

Figure 3.23 shows raising the domain functional level.

Figure 3.23 Raising the domain functional level.

Group Type

The two types of groups are distribution groups, which only are used for email lists, and security groups, which can be used both for email distribution and resource access. You choose the type depending on the reason you are creating the group:

• Distribution—Used for email distribution lists only. Cannot be assigned permissions to use resources.

• Security—Used both for assignment of permissions to use resources and for email distribution.

Group Scope

The second way of classifying a group is by defining its scope. Group scope means determining where the group members and the resources that the group can be granted access permissions to reside. Table 3.3 lists the scope of the group object in the first column (Domain Local, Global, and Universal); in the second column, the object types that can be members of this kind of group; in the third column, the locations of the resources that a group can be given access to.

Note that in several cases, the characteristics of the group object differ depending on the functionality of the domain.

Table 3.3 Group Scopes and Applicable Members and Rights

Scope	Can Include	Can Be Granted Access to Resources In
Domain Local	Accounts, global groups, and universal groups from any domain, and, in Windows 2000 native or Windows Server 2003 functional level domains, other domain local groups from the same domain as the group object.	The local domain
Global	In domains at the Windows 2000 mixed level or at the Windows 2003 interim level, only accounts from the same domain as the group object. In Windows 2000 native or Windows Server 2003 functional level domains, accounts and other global groups from the same domain as the group object.	Any domain in the forest and any domain in any other forest that trusts the local domain
Universal	(Not available in domains at the Windows 2000 mixed level or the Windows Server 2003 interim level.) Accounts, global groups, and universal groups from any domain.	Any domain in the forest and any domain in any other forest that trusts the local domain

How would you choose the scope of a group you need to create? Let's talk about each scope in turn.

Domain Local Groups

Groups of the Domain Local scope are typically used for resource access. When creating a group of this scope, you think of the resource that we're granting access to, rather than the users who might use the resource. You also name the group object after the resource. You might create a Domain Local group with the name DL-CalgaryEngineeringResources, for example. You would grant this group Read and Write access to the folders and printers that are used by engineers in Calgary. The members of the group can be (refer back to Table 3.3) user accounts, global groups, and universal groups from any domain trusted by this domain.

If the domain is at the Windows 2000 native functional level or the Windows Server 2003 functional level, the new group can also have other domain local group accounts among its members. The ability to make a group a member of another group of the same type is called nesting.

We have just listed the types of objects that can be members of our new domain local group, but what types are we likely to use? Typically, the member list of a domain local group includes an administrator account and one or more global group accounts. More rarely, you may also see universal group accounts in the domain local group member list.

Global Groups

A global group is used to collect user accounts, typically according to the function the members perform in their work. Therefore, their names reference the accounts that are on the group member list—typical global group names are G-CalgaryEngineers and G-VancouverHR. Only accounts in the same domain as the group object can be members of the global group. The reason the group is called "global" is that the group can be assigned access to any resource or made a member of any domain local group in the entire forest.

If the domain is at the Windows 2000 native functional level or the Windows Server 2003 functional level, the new group can also have other global group accounts from its domain among its members.

A good example of the use of Global groups is when users are disbursed and resources exist in few domains. For example, an engineering company has engineers in its Vancouver, Calgary, and Edmonton offices. Each location hosts its own domain in a Windows Server 2003 Active Directory forest. All engineering resources are located in the Calgary domain. Each domain administrator places his engineers in an "engineers" Global group for his domain. The Calgary domain administrator creates the EngRes Domain Local group and assigns the selected permissions to that group. He then places each Engineers Global group from each domain into the EngRes group. The Calgary administrator relies on the other administrators to determine who in their respective domains is allowed access to the resources.

Universal Groups

A universal group, as its name implies, has no limitations as to where its members are located, or in what domains it can be granted resource access. Its members can come from any trusted domain, and it can be a member of any group or granted access to resources in any trusted domain. These qualities make the group type seem ideal: no worrying about whether the source of members is all right or whether the group can be assigned access in another domain.

There is a cost to this universality, however: The list of members of a universal group is kept in the Global Catalog (GC) and therefore is replicated to all domain controllers designated as Global Catalog servers in the forest. However, the new link-value replication feature in Windows Server 2003 reduces the amount of replication traffic significantly, compared to Windows 2000, where the entire Universal group membership list was replicated whenever a change was made.

You create a universal group when both these conditions apply:

• The members of the group come from more than one domain.

• The group needs resource access in more than one domain.

Universal groups are useful when users and resources are disbursed in all domains. For example, when every domain has EngRes and Engineer Global groups, this might not be bad during the initial setup, but it becomes a nightmare as new domains are added. The Universal groups make it easier, in that each domain's Engineers Global group gets added to the Engineers Universal group, and the Engineers Universal group is added to each domain's EngRes Domain Local group. As new domains come online, they only have to add their Engineers Global group to the Engineers Universal group, and the Engineers Universal group to the Domain Local group that they have assigned permissions for the shared resources to.

Recommended Sequence of Groups

In small networks (a single domain, with one domain controller), you could work exclusively with groups of global scope. Any user account within the domain can be a member of a global group, and global groups can be given access to resources anywhere within the domain.

In larger networks, the recommended usage of groups is as follows:

• Make accounts members of global groups.

• Make global groups members of domain local groups.

• Assign resource access permissions to the domain local groups.

In some cases it is helpful to make global groups members of universal groups and then to make the universal groups members of domain local groups. This is only necessary when a universal group is needed—that is, when a group will have members from multiple domains and will need access to resources in multiple domains.

This sequence is known as AGUDLP, which stands for Accounts, Global, Universal, Domain Local, and Permissions.

Here's the hierarchy, then: Say we have three domains (Lantrainers, Lanwriters, and Lanconsultants), and there is a global group in each domain that holds all the finance mangers in that domain (Lantrainers/G-FinanceManagers, Lanwriters/G-FinanceManagers, and Lanconsultants/G-FinanceManagers). We could make the U-FinanceManagers universal group with these three global groups as members, and then place the universal group on the member list of a domain local group in each of the domains, to give the finance managers access to the resources the domain local group provides. Finally, we could add U-FinanceManagers to the member list of the DL-FinanceResources domain local group in each domain.

You might wonder why we don't grant access to the resources directly to the universal group. We could, of course, but our assumption is that the domain local groups would exist already, to give access to the resource to groups within the local domain.

This hierarchy of groups allows very simple handling of new employees. When a new finance manager joins any of the companies, the local administrator needs only to make the finance manager's user account a member of the G-FinanceManagers global group in the new user's local domain, and that user will immediately be able to access the resources needed.

Creating and Modifying Groups by Using the Active Directory Users and Computers Console

To create a group with Active Directory Users and Computers, first select the domain or OU where you want the group object to reside. Generally you should place the group objects inside OUs because you will most likely delegate responsibility for all the objects in an OU to a subadministrator. In our sample company, it has been agreed that any domain local group that has members from outside the domain will be created at the LTI level. Also, global groups will be created at the level in the hierarchy above all the objects in the groups' member list. So the DL-FinanceResources domain local group is created at the LTI level, as is G-FinanceManagers. The G-CalgaryEngineers group would be created at the Calgary OU level.

In Step by Step 3.3, we'll create groups with Domain Local, Global, and Universal scope.

STEP BY STEP

3.3 Creating Groups with Domain Local, Global, and Universal Scope

1. Open Active Directory Users and Computers.

2. Right-click the LTI Organizational Unit.

3. Select New, Group from the context menu.

4. When the dialog box opens, ensure that the Domain Local and Security radio buttons are selected and then type the name DL-FinanceResources (see Figure 3.24).

Figure 3.24 Give the group a name and specify its type and scope.

5. Click OK, and the group object is created.

6. Right-click the LTI Organizational Unit again and select New, Group from the context menu.

7. This time, ensure the Global and Security radio buttons are selected and then type the name G-FinanceManagers and click OK.

8. Right-click the LTI Organizational Unit a third time and select New, Group from the context menu.

9. This time, ensure the Universal and Security radio buttons are selected and then type the name U-FinanceManagers and click OK. Now we have our three groups—and in production we would create several others (see Figure 3.25).

Figure 3.25 The group objects are shown in the details pane for the Organizational Unit in which they were created.

10. Now we want to make G-FinanceManagers a member of U-FinanceManagers, and we want to make U-FinanceManagers a member of DL-FinanceResources.

11. Right-click the U-FinanceManagers object and choose Properties. Select the Members tab.

12. Click Add. In the Select Users, Contacts, Computers or Groups dialog box (in the Enter the Object Names to Select area), type G and click Check Names. A dialog box appears listing all the users, contacts, computers, or groups whose names start with G (see Figure 3.26).

Figure 3.26 Select the group you want and click OK.

13. Select G-FinanceManagers and click OK. G-FinanceManagers is now a member of U-FinanceManagers. In production we would also add the G-FinanceManagers global groups from the other domains as well.

14. Now click the Member Of tab. Select Add, type DL in the Enter Object Names to Select area, and click Check Names. Select DL-FinanceResources and click OK.

15. We now want to create the \\MARS\Finance share and give DL-FinanceResources access rights to it. To do this, start the Share a Folder Wizard by clicking Add Shared Folder from the Manage Your Server application.

16. After selecting the folder to be shared, naming the share Finance, and assigning a share name, choose Use Custom Share and Folder Permissions, and in the dialog box click Add and browse to the DL-FinanceResources group. Assign the group Full Control rights, remove the Everyone group from the list, and click OK.

We have accomplished our task. Any member of the G-FinanceManagers global group will have the correct access to the \\MARS\Finance share.

Identifying and Modifying the Scope of a Group

Now you know that the scope of a group object in a domain can be Domain Local, Global, or Universal. (On a member server, standalone server, or workstation, local groups can also exist.) So how can you tell the scope of a group object?

The first thing to know is that it won't help you to look at the icons in the details pane of Active Directory Users and Computers. The icons used to denote group objects of all scopes are the same. However, the Type column in the details pane does indicate both the group scope and the group type. See Figure 3.25 to confirm this.

What if you want to change the scope of a group? Perhaps you have a global group, and you have realized that it would be useful to add accounts from another domain to the member list. That's not possible with a global group, but it is with a universal group. If you can change the scope to universal, you can add members from domains in different parts of the enterprise and retain the domain local memberships the existing group has.

If the domain functionality level of your domain is Windows 2000 mixed or Windows Server 2003 interim, you cannot change a group's scope. Universal groups are not available at that domain functionality level, and you cannot change a group's scope from domain local to global, or vice versa.

If the domain functionality level is Windows 2000 native or Windows Server 2003, you can change a group's scope, but only if the group is not a member of another group and has no group members that would be illegal for groups of the new scope.

Here are some examples:

• You want to change the scope of a group from Global to Universal—This is not allowed if the group is a member of another global group.

• You want to change the scope of a group from Domain Local to Universal—This is not allowed if the group has another domain local group as one of its members.

• You want to change the scope of a group from Universal to Global—This is not allowed if the group has another domain local group as one of its members.

• You want to change the scope of a group from Universal to Domain Local—This is allowed under all conditions.

Note that it is not possible to change a domain local group to a global group, or vice versa. To change a group's scope with Active Directory Users and Computers, first you have to select the group and look at its properties. Simply click the radio button beside the new scope and click OK to change the scope. If you have followed group naming conventions that indicate the scope of the group, you will probably want to rename the group to show the new scope.

To determine the scope of a group object from the command line, you can use dsget. This command shows the description of a group, whether its type is security, and its scope:

dsget group <dn> [-desc] [-secgrp] [-scope]

To change a group's scope from the command line, you can use dsmod. Its syntax in this case is very simple; you just type this:

dsmod group <dn> -scope <L, G, or U>

You need to be a member of Domain Admins, Enterprise Admins, or Account Operators, or you have to been delegated the appropriate authority to change the scope of a group by either method.

Managing Group Membership

You can make an account a member of a group in two ways:

• By starting with the properties of the account and changing the list of groups of which the account is a member

• By starting with the properties of the group object and changing the member list of the group

There are several methods for changing the group membership, both from Active Directory Users and Computers and from the command line.

In Active Directory Users and Computers, you can use the Member Of tab of the account to see the list of groups the account belongs to, or you can use the Members tab of the group to see the list of members.

Let's look at the "Member Of" method first. Choose the properties of a user, group, or computer object in Active Directory Users and Computers and then click the Member Of tab. A list of group objects is displayed. Click Add and use the Object Picker to locate the group or groups you want the account to be a member of. Click OK, and the Member Of list is updated, as shown in Figure 3.27.

Figure 3.27 Click Add to make the user a member of an- other group.

Another way to use Active Directory Users and Computers to add accounts to a group is to select multiple accounts and then choose File, Properties and click the Member Of tab. With the Object Picker, find the group whose member list you want to add the accounts to, select it, and select OK. Alternatively, you can right-click the objects and choose Add to a Group from the shortcut menu.

Now let's try starting from the group object. Display its properties and choose Members. Use the Object Picker again, but this time the goal is to find the accounts that should be added to the member list of the group. Select the objects and click Add.

A third method (but not recommended) is to select the accounts you want to add to a group's member list and then drag them to the group object. Dropping the accounts on the group object adds them to the member list. This method is not recommended because it is too easy to drop the accounts on the wrong group object.

Adding Accounts to Groups with Command-line Tools

Naturally, a command-line tool is also available for this purpose—you can change the member list of a group with the dsmod group command. This command adds the accounts whose distinguished names follow –addmbr to the member list of the group specified:

dsmod group <groupdn> -addmbr <dn's of accounts to be added>

Note that dsmod group has two similar-looking parameters that can be used to alter the membership list of a group. As you can see from Table 3.4, -chmbr and -addmbr both change the membership list, but with quite different results.

Table 3.4 The chmbr and addmbr Commands

Parameter	Member List Before	Member List After
-addmbr John	Jack, Barbara, Gill, Catherine	Jack, Barbara, Gill, Catherine, John
-chmbr John	Jack, Barbara, Gill, Catherine	John

dsmod with the –addmbr parameter adds the account to the member list of the group, whereas the –chmbr parameter replaces the current member list with the accounts following –chmbr. And dsmod group with the –rmmbr parameter removes the accounts listed from the group's member list.

You're probably expecting to find that there is a command-line method for adding a member to a group using dsmod user. There isn't! In the Active Directory Users and Computers interface you cannot tell whether the group membership information is a property of the user object or the group object. But because dsmod only allows group membership changes with dsmod group, it is clear that the membership information belongs to the group object.

Finding Domain Groups in Which a User Is a Member

If you want to know what groups a user belongs to, you can easily find out with Active Directory Users and Computers by looking at the properties of the user object and then selecting the Member Of tab. There you will see the groups the user belongs to.

There is a problem, however. What if the user is a member of group A, and group A is a member of group B? In that case, the user is effectively a member of group B, but that fact is not shown on the Member Of tab of the properties of the user object. In fact, there is no way within Active Directory Users and Computers to show the expanded member list. However, we can use dsget user to show this information.

To find all the groups the user belongs to, not counting those due to group nesting, use the following dsget command:

dsget user <dn> –memberof

To find all the groups the user belongs to, including those due to group nesting, use the following dsget command:

dsget user <dn> –memberof –expand

In Figure 3.28, you can see the output of these two commands for the same user.

Figure 3.28 The first command shows the direct group memberships of the user, whereas the second shows the nested memberships as well.

Do you remember the discussion of piping earlier in this chapter? We can pipe the output of one command to another command, which will allow us to avoid having to know the distinguished name of an account in memberof queries. Look at Figure 3.29.

Figure 3.29 We only need to know enough of the user's name to make the -name parameter unique.

As you can see from the figure, it was sufficient to enter najma* to select the one user whose group memberships are wanted.

Creating and Modifying Groups by Using Automation

Earlier in this chapter, we described using ldifde to create and modify user accounts. ldifde can also be used to create and modify group accounts.

In Step by Step 3.4, we will list the group accounts in the Vancouver OU, modify the names to create new group accounts, and add user accounts to the group accounts.

STEP BY STEP

3.4 Creating Group Accounts

1. Open a command prompt and change to the root of the C: drive.

2. Type the following command:

ldifde -f ldifgroupout.txt -d "OU=Vancouver,OU=LTI,DC=lantrainers,
DC=local" -l objectclass,cn,distinguishedname,name,
samaccountname -r "(objectclass=group)"

This command will change the OU's distinguished name appropriately, if necessary, and list the group names in the ldifgroupout.txt file.

3. Type notepad ldifgroupout.txt to open the file in Notepad.

4. Change the names of the groups to new ones—for example, Marketing and Production in place of Sales and Engineering.

5. Remove the entry for VancouverUsers.

6. Save the file as ldifgroupin1.txt.

7. Type the following command:

ldifde -i -f ldifgroupin1.txt -j c:\ -k

-j c:\ puts a log file called ldif.log on c:\, and -k tells ldifde to continue in case of errors. You should see the message 2 entries modified successfully.

8. In Notepad, create a file called ldifgroupin2.txt, to change the member list of the Vancouver Users group, with the following content (note that ldifde can only replace the complete member list of a group, so you have to include all members in this file):

dn: CN=Vancouver Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local
changetype: modify
replace: member
member: CN=Sales,OU=Vancouver,OU=LTI,DC=lantrainers,
DC=localmember: CN=Engineers,OU=Vancouver,OU=LTI,
DC=lantrainers,DC=localmember:CN=Marketing,OU=Vancouver,
OU=LTI,DC=lantrainers,DC=local
member: CN=Production,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local
-

9. At the command prompt type the following command:

ldifde -i -f ldifgroupin2.txt -j c:\ -k

You should see the message 1 entry modified successfully.

10. In Active Directory Users and Computers, view the group objects in the Vancouver OU to see that the Marketing and Production groups have been created and that the four groups listed in ldifgroupin2.txt are shown as members of the Vancouver OU.

Creating and Managing Computer Accounts in an Active Directory Environment

For every computer running Windows NT, Windows 2000 Professional, or Windows XP and every server running Windows Server 2003 that is a member of a domain, a computer account must be created in the domain. The computer account is a security principal, and it can be authenticated and granted permissions to access resources. A computer account is automatically created for each computer running the listed operating systems when the computer joins the domain.

Although it is true that computer accounts are created automatically when a computer joins a domain, sometimes it is worthwhile to create computer accounts manually. Doing so allows a user to install a new computer in the appropriate location in the domain, even if that user doesn't have the necessary administrative privileges, using the name of the computer account that already exists.

When you're using Remote Installation Services (RIS), it is helpful to set up a default naming policy because this allows you to determine where in Active Directory the computer object is placed. You have three options in choosing the Organizational Unit for the computer object:

• In the default location for computer objects (Computers, under the domain object)

• In the same Organizational Unit as the object of the user installing the computer

• In a predetermined Organizational Unit

Note that even if the computer object has been pre-created, the user installing the computer must have been delegated the right to join a computer to the domain.

Creating Computer Accounts Using the Active Directory Users and Computers Console

To create a computer account using Active Directory Users and Computers, right-click the container you want the account to appear in and then choose New, Computer from the context menu. Assign the necessary values to the parameters available and click OK. Figure 3.30 shows the New Object dialog box in which you type the computer name and give a pre–Windows 2000 computer name (limited to 15 characters). You may also designate the computer as a pre–Windows 2000 computer, and you may state that the computer is to be a Windows NT 4 backup domain controller.

Figure 3.30 Type the name of the computer. Windows Server 2003 will automatically create a pre–Windows 2000 computer name.

The next dialog box you see will ask you whether this is a managed computer. If you accept this option, the computer object will be accessible for automatic operating system installation by RIS.

Creating Computer Accounts by Joining the Domain

To create a computer account by joining a domain, first log on to the computer you want to join to the domain with the credentials of a user with administrative privileges on that computer. Choose the System applet from Control Panel, change the workgroup membership information to reference the domain the computer is to join, and click OK. The system will ask you for the credentials of a user object that has the necessary rights and, after a short pause, will show a dialog box to welcome the computer to the domain. The computer must be rebooted so that it can come up as a member of the domain.

Once the computer is a member of the domain, a user logging on to the domain has the logon request passed by the workstation through a secure channel to the domain controller. The computer must have a domain computer account for the secure channel to be created.

Guided Practice Exercise 3.2

You are the administrator of a network for a manufacturing company that has multiple Windows Server 2003 servers used for applications and file and print services. The Research and Development Department has received a massive increase in funding this fiscal year, and it is purchasing all new desktop computers.

You plan to delegate the desktop replacements to the desktop support group. However, because Windows XP Professional computers are being installed, a computer account will need to be added for each computer. You do not want to grant the desktop support group the necessary access to add the computer accounts, but you cringe at the idea of adding 500 computer accounts manually.

You must find a way to automate this process.

What is the best way to solve this issue in Windows Server 2003? On your own, try to develop a solution that would involve the least amount of downtime and expense.

If you would like to see a possible solution, follow these steps:

Estimated Time: 30 minutes

This is a fairly easy solution. You can use the dsadd utility with the computer option to add a computer account to the domain. The dsadd utility allows you to accept the computer account name from standard input (stdin) so that you can redirect the contents of a text file that contains a list of the computer names to be used in creating the accounts.

1. From the Start menu, select Run.

2. From the Run dialog box, enter CMD to open a command window.

3. On the command line, enter the following command, where names.txt is a text file that contains a listing of the computer names:

dsadd computer <names.txt>

By default, dsadd computer uses the user context of the currently logged on user to connect a domain controller in the logon domain. Administrative access is required.

Troubleshooting Computer Accounts

Because computers need to authenticate to one another, they need accounts and passwords. In addition to the two methods described previously, a computer account is also created when a Windows Server 2003 server is promoted to a domain controller with dcpromo.

Like user accounts, each computer account has a password. Passwords are created by the process that creates a computer account. On a defined interval, a process running on the local computer changes the password automatically, and the new password is communicated securely to a domain controller in the computer's domain.

What happens if a server running Windows Server 2003 changes its password, but there is no domain controller available for the new password to be written to? The next time the two computers are able to communicate, the server with the changed password, on finding that the new password is not accepted, uses the previous one instead. Once authentication is complete with the old password, the new password is stored on the domain controller and is subsequently replicated to all domain controllers in the domain.

Troubleshooting Issues Related to Computer Accounts by Using the Active Directory Users and Computers Console

When a computer account is operating incorrectly, it may be impossible to log on to the domain from the computer. You can see how, if the computer cannot authenticate to the domain controller, it will be impossible for the user to log on. In this case it is necessary to reset the computer's account and rejoin the computer to the domain. This process reestablishes the secure relationship between the computer and the domain it is a member of.

To reset a computer's account using Active Directory Users and Computers, select the folder containing the computer account and right-click the computer object. Choose Reset Account from the context menu, and click Yes from the confirmation dialog box. Reboot the workstation and then rejoin the domain as described earlier.

To reset a computer's account from the command line, you use the dsmod command with the -reset switch:

dsmod computer <dn of computer> -reset

As in the case where the computer account was reset using Active Directory Users and Computers, you will have to rejoin the computer to the domain.

Case Study: T Foster

Essence of the Case

Here are the essential elements in this case:

• Export the Harshaw user accounts.

• -Change the Harshaw accounts to reflect that they are now T Foster employees.

• -Import the Harshaw data into the T Foster AD.

Scenario

T Foster is a wholesaler for farm equipment based in the Midwest. T Foster has decided to merge with Harshaw, Inc., one of its biggest rivals, located in the Upper Midwest. The mission of this newly formed conglomerate is to dominate the wholesale farm implement business in the plains states.

T Foster now wants to merge the information technology systems of the two companies as quickly as possible. Fortunately, the two companies run the same order-entry and inventory software, so there won't be any end-user training required.

T Foster has decided to give the former Harshaw employees access to resources on the T Foster network, while slowly migrating the Harshaw data over.

Analysis

The features in Windows Server 2003 enable T Foster to merge the two companies with the least amount of difficulty. The first step is to export the user list from the Harshaw Active Directory using ldifde. This extracts the existing user accounts to a file.

The next step is to change the distinguished name in all the user records because the users are now part of T Foster. All the information about the accounts will be the same, but the Active Directory paths will be different in all the distinguished names. This can be accomplished by using ldifde with –c <old string> <new string> to cause the replacement of any occurrences of <old string> with <new string>.

Here's an overview of the requirements and solutions in this case study:

Requirement	Solution Provided By
Export the Harshaw user accounts.	Exporting the user list from the Harshaw Active Directory using ldifde.
Change the Harshaw accounts to reflect that they are now T Foster employees.	Using ldifde with the –c switch to change the distinguished names.
Import the Harshaw data into the T Foster AD.	Importing the user list from the Harshaw AD into the T Foster AD using ldifde.

Chapter Summary

Key Terms

• Active Directory Users and Computers

• Organizational Unit (OU)

• User accounts—domain and local

• Password

• User templates

• Command-line tools for Active Directory tasks

• dsadd

• dsquery

• dsget

• dsmod

• dsmove

• dsrm

• csvde

• CSV (Comma Separated Value)

• ldifde

• LDAP Data Interchange Format

• Account lockout

• Disabled account

• Expired account

• Dial-in disallowed

• Complexity requirements for passwords

• User profiles—local, roaming, and mandatory

• Properties on multiple objects

• Group accounts

• Domain functionality level

• Group scope—Domain Local, Global, Universal

• Group types—distribution and security

• Nested groups

• Group expansion

• Computer accounts

• Remote installation services

• Managed computer

This chapter discussed many important skills—skills that you will use every day as a network administrator.

You started with creating and modifying user accounts. You used Active Directory Users and Computers first, learning how to create user accounts in the graphical user interface (GUI). You then progressed to using the command-line tools: dsadd to create a user account, dsget to inquire into an object's properties, dsmod to change properties, dsquery to find objects of any type, and dsrm to remove objects from Active Directory. Then you moved on to using csvde and ldifde to create user accounts automatically, by importing information about the new user accounts from data created from other sources, such as enrollment databases or other directories.

Next you learned about Windows Server 2003 group accounts. You discovered the two types of groups—security and distribution—and the three possible scopes a group account in a domain can have: Domain Local, Global, and Universal. Once again, you started with Active Directory Users and Computers and progressed to the command-line tools. Then you learned about using ldifde to create groups.

You also covered computer accounts. There is much less that a network administrator needs to do with computer accounts compared to user and group accounts because computer accounts are typically created automatically when the computer joins the domain and are managed automatically thereafter by the operating system. The network administrator only gets involved if RIS is in use and managed computer accounts are needed, or if a computer account needs to be reset.

Apply Your Knowledge

Exercises

3.1 Creating User Accounts via Automation

Imagine that our fictional company, Lantrainers, has a class starting next week, and the students registered for the class will need user accounts. Each account will need to be a member of the Students group, and we'll need the student's title, company name, and business phone number in the user account information.

We will use dsadd, csvde, and dsmod to make an OU called LanStudents, create user accounts, set passwords, and make the user accounts members of the Students global group.

Here is the data we'll be using:

Amell	Bernie	Trainer	555-7179	Prairie Sky Consulting
Blanchard	Verna	Systems Analyst	555-4296	Housing Associates
Bond	Dorothy	Trainer	555-7096	Prairie Sky Consulting
Clark	Cathie	Trainer	555-7028	Prairie Sky Consulting
Ducharme	Lydia	Network Administrator	555-7220	Goldenrod Developments
Emmett	Matt	Network Administrator	555-6057	Goldenrod Developments
Guyn	Karen	Network Administrator	555-1544	Goldenrod Developments
Guyn	Pat	Systems Analyst	555-6669	Goldenrod Developments
James	Robert	Systems Analyst	555-8729	Housing Associates
Jensen	Nicole	Systems Analyst	555-8849	Goldenrod Developments
Kyle	Ann	Trainer	555-8849	Prairie Sky Consulting
Magnus	Holly	Trainer	555-5295	Prairie Sky Consulting
Michell	Christine	Network Administrator	555-4755	Prairie Sky Consulting
Myers	Leslie	Network Administrator	555-1479	Goldenrod
Nowlin	Patty	Systems Analyst	555-4296	Housing Associates
Poulin	Paule	Systems Analyst	555-8606	Housing Associates
Rutherford	Donna	Trainer	555-7612	Prairie Sky Consulting
Ryan	Kathleen	Network Administrator	555-5467	Goldenrod Developments
Sept	Rick	Systems Analyst	555-6057	Housing Associates
Stratton	Susan	Systems Analyst	555-6669	Housing Associates
Swenson	Kathi	Network Administrator	555-5487	Goldenrod Developments

Estimated Time: 45 minutes

1. Open a command prompt and change to the root directory of the C: drive.

2. Use dsadd to create an OU called "OU=LanStudents,OU=Vancouver,OU=LTI, DC=lantrainers,DC=local".

3. Type a csvde command to create a list of the user accounts in the OU=Users,OU=Vancouver,OU=LTI,DC=lantrainers,DC=local OU. Use the parameter -l l,company,objectclass,name,title,company,l,telephoneNumber,userAccountControl,samaccountname to limit the number of fields displayed. Send the output to csvde-out.txt. Copy the file to csvde-in.txt.

4. Use a spreadsheet program, a database program, or Notepad to modify csvde-in.txt. Retain the first record (it has the field names we'll need), but replace the data lines with data from the preceding table. Ensure that the fields are in the proper columns.

5. Use csvde to input the data in csvde-in.txt into Active Directory. Confirm that the records were created with Active Directory Users and Computers (csvde -i -f csvde-in.csv -j c:\).

6. Use dsquery to display all the users in the LanTrainers OU, and pipe the result as input to a dsmod command that sets the password for all users to Security and enables the account (dsquery user "OU=LanStudents,OU=Vancouver, OU=LTI,DC=lantrainers,DC=local" | dsmod user -pwd Secur1ty -mustchpwd yes -disabled no).

7. Open Active Directory Users and Computers and navigate to the LanStudents OU to see the user accounts.

3.2 Creating Users and Groups

In this exercise we will create three groups and add members to them. Then we will make the three groups members of a universal group. Because there aren't many groups to work with, we'll use Active Directory Users and Computers.

Estimated Time: 5 minutes

1. Open Active Directory Users and Computers, and navigate to the LanStudents OU.

2. Create a global security group object called AdminStudents. Add the user accounts for those users whose title is Network Administrator to the member list of the group.

3. Create a global security group object called AnalystStudents. Add the user accounts for those users whose title is Systems Analyst to the member list of the group.

4. Create a global security group object called TrainerStudents. Add the user accounts for those users whose title is Trainer to the member list of the group.

5. Create a universal security group object called AllStudents. Add the three group accounts we just created to the member list of the group.

Review Questions

1. Because you can do everything you need to do, in terms of creating and managing accounts, with Active Directory Users and Computers, why is it worthwhile to learn the command-line and automation methods?

2. What are the similarities and differences between csvde and ldifde?

3. What would be the impact of using groups of Universal scope exclusively, rather than using groups of Domain Local, Global, and Universal scope?

4. You are planning to implement Remote Installation Services. How can you ensure that the computer accounts the users create go in the right Organizational Units?

5. You are setting up instructions for help desk analysts, and you're writing a list of items for them to check when users cannot log on. What should go on that list?

6. Your manager has asked you to investigate Terminal Services and report on how you can control the Terminal Services sessions. What do you report?

7. Every month your manager wants you to produce a list of all accounts that have passwords that do not expire and all accounts that are disabled. How will you do this?

8. Explain how to ensure that the order-entry clerks will all see the same desktop environment each time they log on.

Exam Questions

1. You want to create a user account for Joan Myles using a command from the command prompt. The account is to be a member of the Engineers group in the Vancouver container, disabled when created, have Secur1ty as its password, and be placed in the "ou=Users,ou=Vancouver,ou=LTI, dc=Lantrainers,dc=local" container. Which of the following tools or combination of tools can do the job?

1. A. Net User followed by dsmove

2. ldifde followed by dsmod

3. dsadd

4. csvde followed by dsmove

5. dsquery followed by dsmod

2. A manager tells you one of his staff has taken a job in another company. The manager wants to ensure that the user cannot access his computer or his files on the network file server. What is your best course of action?

1. A. Delete the user account.

2. Rename the user account to "Departed User."

3. Select the Account Is Disabled check box.

4. Change the value in the Account Expires field.

3. You are planning for resource access in a multidomain forest. Some users from all domains will need access to three continental headquarters domains. What is the recommended strategy for providing access to these resources?

1. Users -> universal groups -> global groups -> domain local groups -> permissions to resources

2. Users -> global groups -> universal groups -> domain local groups -> permissions to resources

3. Users -> domain local groups -> universal groups -> global groups -> permissions to resources

4. Users -> universal groups -> permissions to resources

4. You need to explain profiles to your management, and you realize that you need to start your presentation with definitions of the three profile types. Choose the three profile types.

1. Active Directory user profile

2. Local user profile

3. Group profile

4. Group policy user profile

5. Roaming user profile

6. Mandatory user profile

5. You are the network administrator for a small company that provides customer service operators for other companies. One of your users calls to complain that the photograph of her grandson that she added to her desktop yesterday wasn't there when she logged on this morning. What is the most likely cause of her problem?

1. Her user profile is corrupted.

2. She logged in to a different computer.

3. She is logged on locally.

4. She was assigned a mandatory profile.

6. Due to economic circumstances, your company had to lay off 200 people. The Human Resources department has provided you with a list of names in a text file. Which command can be used to delete these user accounts?

1. A. dsmod

2. dsadd delete

3. csvde

4. dsrm

7. Your company has recently purchased a small company. The other company runs Unix with an LDAP-compatible directory. Your job is to create user accounts in Active Directory for the employees from this company. What is the best tool to use for this task?

1. dsadd

2. ldifde

3. csvde

4. dsrm

8. You are the administrator for a small university. As usual for this type of environment, bored students try to hack into the university billing system every night between 10 p.m. and 2 a.m. What two steps can you take to ensure that a dictionary attack will fail, while still allowing your user to log on at 8 a.m.?

1. Set Account Lockout Threshold to 0.

2. Set Account Lockout Duration to 60.

3. Set Account Lockout Duration to 0.

4. Set Account Lockout Threshold to 3.

9. You are the network administrator for a small company that provides customer service operators for other companies. One of your users calls to complain that she can't see any files in her My Documents folder. She was able to get to them with no problem yesterday. Group Policy is not in use. What is the most likely cause of her problem?

1. Her user profile is corrupted.

2. She logged in to a different computer.

3. She is logged on locally.

4. She was assigned a mandatory profile.

10. You are the junior administrator for a large engineering firm with several locations. You read in a magazine that the best way to assign resources in a multidomain environment is to assign permissions to a Domain Local group, then add the Global groups to the Domain Local group, and then add the Global groups to a Universal group. However, the server won't let you create a Universal group. What is the most likely problem?

1. You don't have the proper authority.

2. The domain function level is at Windows 2000 mixed.

3. The domain functional level is at Windows 2000 native.

4. The domain functional level is not at Windows 2003 native.

11. You are the administrator for a small, family-owned firm. Because of the firm's size and informality, it has been tough to get users to understand the need for security. You want to change the password policy so that the users will be required to change their passwords every 30 days and can't reuse a password more than every 2 years. Which of the following choices will accomplish this?

1. Set the password history to 730 and the maximum password age to 30.

2. Set the password history to 365 and the maximum password age to 30.

3. Set the password history to 25 and the maximum password age to 28.

4. Set the password history to 24 and the maximum password age to 30.

12. A manager tells you that his administrative assistant has left the company. The manager wants to ensure that her replacement has access to her computer and her files on the network file server. What is your best course of action?

1. Create a new user account for the replacement and grant the replacement access to the necessary files.

2. Rename the old user account for the new user.

3. Create a new user account for the replacement and copy the necessary files to her home directory.

4. Give the new user the user ID and password of the departed administrative assistant.

Answers to Review Questions

1. Using Active Directory Users and Computers for creating and managing accounts is fine if you're dealing with just a few accounts. But it's time consuming and error prone if you are dealing with dozens or hundreds of accounts. The command-line and automation tools are much more efficient for dealing with large numbers of users. See "Creating and Modifying User Accounts with Command-line Tools."

2. csvde and ldifde can both be used to import or export large numbers of accounts. csvde uses CVS-formatted files for input and output, whereas ldifde uses files in the LDAP Directory Interchange Format (LDIF). Only ldifde can be used to modify or delete existing accounts. See "Importing and Exporting User Accounts."

3. If you used universal groups exclusively, you would lose the structure and manageability of domain local and global groups. Also, you would increase the replication traffic on your network, as the member lists of universal groups are stored in the global catalog. See "Universal Groups."

4. In the properties of Remote Installation Services (accessible on a tab of the properties of the computer running Windows Server 2003 where RIS is installed), create a default naming policy with the desired location defined. See "Creating and Managing Computer Accounts in an Active Directory Environment."

5. Here are the items to check if users cannot log on:

• Is the account locked out due to too many logon failures?

• Is the account disabled?

• If the user is trying to connect via VPN or dial-up, is Remote Access Permission set to Deny Access, or is access controlled through a Remote Access Policy that denies access?

• Has the account expired?

6. See "Troubleshooting Issues Related to User Account Properties."

7. First, a Terminal Services session can be controlled. An administrator can view a user's session and control it if necessary. Second, you can specify a profile and home folder location that are different from the values set up in the user's normal profile. Third, you can configure a program to start automatically at logon and for the session to end when the program is exited. Also, you can control whether drives and printers on the client computer are available from the session.

8. You will define a saved query with the required fields selected. When the report is due, you return to Active Directory Users and Computers, select Saved Queries, and select the query you need.

9. Set up a mandatory user profile, by creating a user profile with the desired desktop environment, convert it to a roaming user profile stored on a server, and then rename the profile to NTUser.man. See "Creating and Enforcing Mandatory User Profiles."

Answers to Exam Questions

1. B, C. ldifde (with the appropriate data file as input) followed by dsmod (to change the password) does the job, as does dsadd by itself. Net User cannot create a group membership. csvde cannot create group memberships, and dsmove is unnecessary because csvde can create the user account in any container. dsquery cannot create a user account.

2. C. It is best to disable the account immediately and then reset the password and enable the account again when someone is ready to review the files held by the account. Deleting the user account makes the review of files very difficult. Renaming the account without changing the logon name or password does not stop the user from accessing the account. Changing the value in the Account Expires field would work, but it is inappropriate to the situation and hence would confuse other administrators.

3. B. This is the recommended method for providing access to resources through group membership.

4. B, E, F. These are the profile types.

5. D. Although all the other choices are possibilities, in a customer service environment, it's most likely that mandatory profiles are in use. A manda- tory profile allows you to make changes; however, those changes are not saved when you log off.

6. D. The dsrm command can be used to delete Active Directory objects, using a text file as input. The csvde command can only be used to import or export accounts, the dsmod command can be used only to change the properties of accounts, and the dsadd command doesn't have a delete option.

7. B. ldifde is the best tool to use for this task. It allows you to extract the user list from the LDAP-compatible directory on the Unix server. Next, it allows you to change the distinguished name in the exported file to match your AD structure. Then it imports the new users into AD.

8. B, D. Setting the lockout threshold to 3 locks the account after three failed attempts to log on. Setting the lockout duration to 60 reenables the account after 60 minutes. Setting the lockout threshold to 0 allows an indefinite number of logon attempts—definitely not what you want. Setting the lockout duration to 0 will keep the account locked until the administrator manually reenables it.

9. B. The most likely problem is that she logged on to a different computer, and roaming profiles are not in use.

10. B. Universal groups are available only at the Windows 2000 native and Windows Server 2003 functional levels. The Windows 2000 mixed and Windows Server 2003 interim levels are used to support Windows NT 4.0 domain controllers, so Global group nesting and Universal groups cannot be used.

11. D. With the maximum age set to 30 days, users are prompted to change their passwords every 30 days. The history setting will retain 24 passwords, approximately 2 years worth.

12. B. The easiest way to give the new user the proper access is to just rename the old account with the new user's name because they will be performing the same duties and need access to the same files.

Suggested Readings and Resources

1. For information about LDAP, see RFCs 2251–2256. For information on LDIF, see RFC 2849.

2. Windows Server 2003 Deployment Guide (not yet published). Microsoft Corporation.

3. Windows Server 2003 Resource Kit (not yet published). Microsoft Corporation.

4. Boswell, William. Inside Windows Server 2003. New Riders, 2003. ISBN 0735711585.

5. Matthews, Marty. Windows Server 2003: A Beginners Guide. McGraw-Hill, 2003. ISBN 0072193093.

6. Minasi, Mark, et al. Mark Minasi's Windows XP and Server 2003 Resource Kit. Sybex, 2003. ISBN 0782140807.

7. Minasi, Mark, et al. Mastering Windows Server 2003. Sybex, 2003. ISBN 0782141307.

8. Shapiro, Jeffrey, et al. Windows Server 2003 Bible. John Wiley & Sons, 2003. ISBN 0764549375.

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240