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

This chapter is from the book 

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.