Managing the Directory

Like this article? We recommend

Windows 2000 Essential Reference

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Windows 2000 Essential Reference

Learn More Buy

4.4: Creating and Managing User Accounts

Overview of User Accounts

The management of user accounts is one of the primary responsibilities of system administrators. User accounts are important because they are a fundamental unit of security and audit policies. In past versions of Windows, it was uncommon for anyone but administrators to require the ability to list user accounts. Accordingly, there was little identifying information to maintain other than Login Name, Full Name, and Description.

In Windows 2000, the strategic importance of user account maintenance has increased. Active Directory now represents not just a list of accounts, but also a database and referral point for many services that require the data to be up-to-date. The Active Directory is exposed to users often—especially in collaborative activities such as video conferencing and electronic mail. As a result, more fields have been created to help associate directory objects with real people and resources.

Although this has resulted in an increased burden on administrators, powerful new tools have come to their rescue. The traditional GUI-based management applications still exist, but additional command-line applications and API (Application Program Interface) techniques are now included. Although these new tools are sophisticated, they do not require extensive application programming experience to use.

Virtually all these new fields, functionality, and tools focus on the Active Directory. Although Windows 2000 still supports the "workgroup" networking model (utilizing local accounts), Active Directory is where the exciting improvements are.

For more information on Active Directory, see Chapter 1.2, "Introduction to Active Directory," and Chapter 4.2, "DNS and Active Directory."

Local (SAM) Accounts

The concept of local accounts has been carried over from the Windows NT security model. Although every Windows 2000 computer maintains a list of accounts, only non-Domain Controllers can contain local accounts.

Local accounts are sometimes referred to as SAM accounts because the Security Accounts Manager (SAM) service is responsible for their maintenance. The SAM service stores local accounts in an encrypted file on the local computer (%systemroot%\system32\config\sam). Local accounts are known only to the local computer, so they can be used only to authenticate to and use resources on that one computer.

Local accounts are useful in the following scenarios:

• To allow users in untrusted Domains or workgroups to access resources that exist on the local computer.

• To ensure access to a computer when Domain authentication services may be unavailable. For example, a local administration account would be needed to reconfigure a computer that cannot communicate on the network.

Local accounts may also present you with security problems. By definition, local accounts are not centrally managed, so maintaining standards throughout your enterprise may prove difficult. In addition to the security issues, the automation tools discussed later in this chapter (Command Prompt tools and ADSI) do not apply to local accounts.

To create a local account, do the following:

1. Ensure that you are logged on to the computer with appropriate credentials. You must be a member of the local Administrator's group to create local accounts.

2. Launch the Computer Management MMC snap-in. The easiest way to do this is to right-click the My Computer desktop icon and choose Manage.

3. Navigate to the Local Users and Groups section under System Tools. When you select the Users folder, a list of local accounts will appear in the right pane. If there is a red X on the icon, you are probably managing a Domain Controller, which does not support local accounts.

4. Right-click and choose New User. The New User dialog box appears.

5. In the User Name field, enter the new account's logon name. End users typically recognize the User Name as their logon name or the identification they provide to gain access to the computer or network.

6. In the Full Name field, enter the full name of the user, preferably in last, first format.

7. Enter the initial password into the Password and Confirm Password fields.

Best Practices for Local Accounts

• Use them sparingly.

• If you have implemented a Windows NT or Windows 2000 Domain model, do not permit end users to create local accounts on their computers. Instead, encourage them to engage the IT support process to have a Domain account created. Although this might seem like more work for you (and the user) in the beginning, you will have fewer problems in the long run.

• Design a predictable, secure architecture for how and where you will use local accounts. Standardize their use throughout your enterprise, whenever possible. If each system has different local accounts and different passwords, you will (or should) spend a lot of time tracking this information. Consult with your organization's security group to get input.

• Make sure that at least one local Administrator account is enabled on all workstations. This will ensure that you can gain administrative control of the workstation if it is not able to contact a Domain Controller. If you standardize the password for this account, carefully guard this password!

Domain User Accounts

For the most part, Domain user accounts are the preferred way to implement network security. Although there is additional complexity involved in maintaining a Domain architecture, Domain accounts have the following compelling advantages over local accounts:

• Domain accounts exist as objects in the Active Directory, and thus may be centrally (and securely) managed.

• Access to resources on any computer in the Domain may be granted to Domain accounts. This allows a single Domain account to have access to resources on multiple computers. To accomplish this with local accounts, each computer accessed would require an identical account and password.

• Domain accounts can be granted access to resources in other Domains when trust relationships have been established. With new support in Windows 2000 for transitive trusts, access to other Domain resources may not even require an explicit trust.

When Active Directory is first installed, a set of default accounts is automatically included in the new directory. These accounts are created for one of two reasons:

• They help you get started in effectively managing the Active Directory.

• They ensure the secure, reliable operation of an option or service that is running on computer(s) in your network. Usually, these services need to run under a specific security context other than Administrative rights.

Table 4.4.1 contains a list of default Domain accounts included in a typical installation of Windows 2000.

Table 4.4.1 Default Domain Accounts

Administering User Accounts

As objects in the Active Directory, user accounts are available for administration by any of the various channels provided to manipulate data in the directory. These channels include GUI (Graphical User Interface), command-line scripting, and API methods. A brief overview of each method to administer user accounts is shown in the sections that follow.

GUI Interface

The Active Directory Users and Computer MMC snap-in is the most common and convenient way to administer user accounts. The snap-in is available by default on Windows 2000 servers and is installable as an optional software package (ADMINPAK.MSI) from the Windows 2000 CD.

AD Users and Computers presents a hierarchical view of the containers within the Active Directory and the contents within those containers. Users within the containers are identified in the right pane with an icon representing a person's face. If an account is disabled (not currently permitted to log in), a red X appears in front of the icon. It is generally good practice to use the Description field to make administrative notes for special cases. In Figure 4.4.1, you can see that the account for Robert Johnson has been disabled because he is on sabbatical.

Figure 4.4.1 AD Users is showing the status of different users.

Creating and Deleting User Accounts

After you have launched Active Directory Users and Computers, and you have determined which OU should contain a new user, creating a Domain user account is very similar to the process of creating a local user:

1. Right-click the container name and choose New, User.

2. The New User dialog box appears. Note that the Domain name fields will be automatically included in the form.

3. Enter the information shown in Table 4.4.2 into the appropriate fields.

Table 4.4.2 New User Account Fields, Part 1

Field	Purpose
First Name, Initials, Last Name	These fields help identify the person who uses the account.
Full Name	This field populates a number of fields in the Active Directory. The most important of these is the Canonical Name. Because the Canonical Name is difficult to change, ensure that you standardize it among all users you create. Full names must be unique within the OU.
User Logon Name	Also known as the User Principal Name (UPN), the user logon name is what most users associate as their ID or account. It is the logon name they provide when first starting a session with a Windows computer. User logon names must be unique within the Domain.
User Logon Name (pre-Windows 2000)	This field provides compatibility with earlier versions of Windows. This field also must be unique within the Domain.




4. When complete, click the Next button.

5. A new property dialog box appears.

6. Define the password and select the appropriate settings, shown in Table 4.4.3.

Table 4.4.3 New User Account Fields, Part 2

Field	Purpose
Password, Confirm Password	If you want to set an initial password on the account, enter that password in these fields. These fields are not required, but it is strongly recommended that you set a password on all accounts in your network.
User Must Change Password At Next Logon	Check this checkbox if you want to force the next user to log in with this account to change the password.
User Cannot Change Password	Check this checkbox if you want to prevent the user from changing the password. This is useful if you have an account that is shared by many people or a computer service that runs in a user context.
Password Never Expires	This checkbox overrides any password-expiration rules and prevents the password from ever expiring.
Account Is Disabled	When checked, this option disables the account and prevents anyone from logging onto the network with it.




7. Click Next. The final screen will summarize the options chosen. Verify these settings and click Finish. The user account is then created in the directory.

Command-Prompt Utilities

The command-line utilities are well-suited for those with good Microsoft Office skills.

Two command-prompt utilities are provided with Windows 2000 that provide this functionality: CSVDE and LDIFDE.

Although generally similar, LDIFDE is more functional because it supports creation, deletion, and modification of existing objects, whereas CSVDE supports only the creation and deletion of objects.

The following sections give a brief overview of each utility and include some samples that show how to use them.

CSVDE

CSVDE is a command-line application that provides for the import or export of the attributes of many user objects at once. By transferring data between Active Directory and text files formatted in comma- separated-value (CSV) format, new objects (such as user accounts) can be created. CSV formatting allows many applications (notably Microsoft Office) to be used to manage data from Active Directory without programming.

The first line (or header) of a CSV file contains a sequential list of attribute names, separated by commas. Subsequent lines reflect the values of those attributes for the exported objects, also separated by commas. If an attribute supports multiple values (for example, a user may belong to multiple groups), the individual values are separated by a colon (:). Typically, each line after the header represents a discrete object, although it's legal to use the ampersand character (&) to continue an object's definition to the next line.

Raw CSV files are difficult for a human to read, but applications such as Microsoft Access and Excel make them a breeze to view and manipulate!

CSVDE is run from the command prompt and requires a number of command-line parameters. In addition to the parameters defined in Table 4.4.4, additional parameters may apply, depending on whether you are exporting objects (see Table 4.4.5) or importing objects (see Table 4.4.6).

Table 4.4.4 General Options for CSVDE

When using CSVDE to perform a directory Export, certain additional options are available, as shown in Table 4.4.5.

Table 4.4.5 Export Options for CSVDE

When using CSVDE to perform a directory Import, another option is available, as shown in Table 4.4.6.

Table 4.4.6 Import Option for CSVDE

CSVDE Import Examples

To add a user with CSVDE, create a comma-separated file with the following minimum fields, shown in Table 4.4.7.