Export (0) Print
Expand All
Expand Minimize

Creating User and Group Accounts

from Chapter 8, Microsoft Windows 2000 Administrator's Pocket Consultant by William R. Stanek.

A key part of your job as an administrator is to create user accounts, and this chapter will show you how to do that.

User accounts allow Microsoft Windows 2000 to track and manage information about users, including permissions and privileges. When you create user accounts, the primary account administration tools you use are

  • Active Directory Users And Computers, which is designed to administer accounts throughout an Active Directory domain.

  • Local Users And Groups, which is designed to administer accounts on a local computer.

Creating domain accounts as well as local users and groups is covered in this chapter.

User Account Setup and Organization

The most important aspects of account creation are account setup and organization. Without the appropriate policies, you could quickly find that you need to rework all your user accounts. So before you create accounts, determine the policies you'll use for setup and organization.

Account Naming Policies

A key policy you'll need to set is the naming scheme for accounts. User accounts have display names and logon names. The display name (or full name) is the name displayed to users and the name referenced in user sessions. The logon name is the name used to log on to the domain. Logon names were discussed briefly in the section of Chapter 7 entitled "Logon Names, Passwords, and Public Certificates."

Rules for Display Names

In Windows 2000, the display name is normally the concatenation of the user's first name and last name, but you can set it to any string value. The display names must follow these rules:

  • Local display names must be unique on a workstation.

  • Display names must be unique throughout a domain.

  • Display names must be no more than 64 characters long.

  • Display names can contain alphanumeric characters and special characters.

Rules for Logon Names

Logon names must follow these rules:

  • Local logon names must be unique on a workstation and global logon names must be unique throughout a domain.

  • Logon names can be up to 104 characters. However, it isn't practical to use logon names that are longer than 64 characters.

  • A Microsoft Windows NT version 4.0 or earlier logon name is given to all accounts, which by default is set to the first 20 characters of the Windows 2000 logon name. The Windows NT version 4.0 or earlier logon name must be unique throughout a domain.

  • Users logging on to the domain from Windows 2000 computers can use their Windows 2000 logon name or their Windows NT version 4.0 or earlier logon name, regardless of the domain operations mode.

  • Logon names can't contain certain characters. Invalid characters are

    " / \ [ ] : ; | = , + * ? < >
    
  • Logon names can contain all other special characters, including spaces, periods, dashes, and underscores. But it's generally not a good idea to use spaces in account names.

Note: Although Windows 2000 stores user names in the case that you enter, user names aren't case sensitive. For example, you can access the Administrator account with the user name Administrator or administrator. Thus, user names are case aware but not case sensitive.

Naming Schemes

You'll find that most small organizations tend to assign logon names that use the user's first or last name. But you can have several Toms, Dicks, and Harrys in an organization of any size. So rather than having to rework your logon naming scheme when you run into problems, select a good naming scheme now and make sure other administrators use it. For naming accounts, you should use a consistent procedure that allows your user base to grow and limits the possibility of name conflicts and ensures that your accounts have secure names that aren't easily exploited. If you follow these guidelines, the types of naming schemes you may want to use include:

  • User's first name and last initial You take the user's first name and combine it with the first letter of the last name to create the logon name. For William Stanek, you would use williams or bills. This naming scheme isn't practical for large organizations.

  • User's first initial and last name You take the user's first initial and combine it with the last name to create the logon name. For William Stanek, you would use wstanek. This naming scheme isn't practical for large organizations, either.

  • User's first initial, middle initial, and last name You combine the user's first initial, middle initial, and last name to create the logon name. For William R. Stanek, you would use wrstanek.

  • User's first initial, middle initial, and first five characters of the last name You combine the user's first initial, middle initial, and the first five characters of the last name to create the logon name. For William R. Stanek, you would use wrstane.

  • User's first name and last name You combine the user's first and last name. To separate the names, you could use the underscore character ( _ ) or hyphen (-). For William Stanek, you could use william_ stanek or william-stanek.

Tip In tight security environments, you can assign a numeric code for the logon name. This numeric code should be at least 20 characters long. Combine this strict naming method with smart cards and smart card readers to allow users to quickly log on to the domain. Don't worry, users can still have a display name that humans can read.

Password and Account Policies

Windows 2000 accounts use passwords and public certificates to authenticate access to network resources. This section focuses on passwords.

Secure Passwords

A password is a case-sensitive string that can contain up to 104 characters with Active Directory directory service and up to 14 characters with Windows NT Security Manager. Valid characters for passwords are letters, numbers, and symbols. When you set a password for an account, Windows 2000 stores the password in an encrypted format in the account database.

But simply having a password isn't enough. The key to preventing unauthorized access to network resources is to use secure passwords. The difference between an average password and a secure password is that secure passwords are difficult to guess and crack. You make passwords difficult to crack by using combinations of all the available character types—including lowercase letters, uppercase letters, numbers, and symbols. For example, instead of using happydays for a password you would use haPPy2Days&, Ha**y!dayS, or even h*PPY%d*ys.

Unfortunately, no matter how secure you initially make a user's password, eventually the user usually chooses the password. Because of this, you'll want to set account policies. Account policies are a subset of the policies configurable as a group policy.

Setting Account Policies

As you know from previous discussions, you can apply group policies at various levels within the network structure. You manage local group policies in the manner discussed in the section of Chapter 4 entitled "Managing Local Group Policies." You manage global group policies as explained in the section of Chapter 4 entitled "Managing Site, Domain, and Unit Policies."

Once you access the group policy container you want to work with, you can set account policies by completing the following steps:

  1. As shown in Figure 8-1, access the Account Policies node by working your way down the console tree. Expand Computer Configuration, then Windows Settings, and then Security Settings.

  2. You can now manage account policies through the Password Policy, Account Lockout Policy, and Kerberos Policy nodes.

    Note: Kerberos policies aren't used with local computers. Kerberos policies are only available with group policies that affect sites, domains, and organizational units.

    Figure 8-1: Use entries in the Account Policies node to set policies for passwords and general account use. The console tree shows the name of the computer or domain you're configuring. Be sure this is the appropriate network resource to configure.

    Figure 8-1: Use entries in the Account Policies node to set policies for passwords and general account use. The console tree shows the name of the computer or domain you're configuring. Be sure this is the appropriate network resource to configure.

    Figure 8-2: With local policies, you'll see the effective policy as well as the local policy.

    Figure 8-2: With local policies, you'll see the effective policy as well as the local policy.
  3. To configure a policy, double-click its entry or right-click on it and select Security. This opens a Properties dialog box for the policy.

  4. For a local policy, the Properties dialog box is similar to the one shown in Figure 8-2. The effective policy for the computer is displayed but you can't change it. You can change the local policy settings, however. Use the fields provided to configure the local policy. For a local policy, skip the remaining steps; those steps apply to global group policies.

    Note: Site, domain, and organizational unit policies have precedence over local policies.

  5. For a site, domain, or organizational unit, the Properties dialog box is similar to the one shown in Figure 8-3.

    Figure 8-3: Define and configure global group policies using their Properties dialog box.

    Figure 8-3: Define and configure global group policies using their Properties dialog box.
  6. All policies are either defined or not defined. That is, they are either configured for use or not configured for use. A policy that isn't defined in the current container could be inherited from another container.

  7. Select or clear the Define This Policy Setting check box to determine whether a policy is defined.

Tip Policies can have additional fields for configuring the policy. Often, these fields are option buttons labeled Enabled and Disabled. Enabled turns on the policy restriction. Disabled turns off the policy restriction.

Specific procedures for working with account policies are discussed in the sections of the chapter entitled "Configuring Password Policies," "Configuring Account Lockout Policies," and "Configuring Kerberos Policies." This chapter's next section, "Viewing Effective Policies," will teach you more about viewing the effective policy on a local computer.

Viewing Effective Policies

When working with account policies and user rights assignment, you'll often want to view the effective policy on a local system. The effective policy is the policy being enforced and, as discussed in Chapter 4 under "Group Policy Management," the effective policy depends on the order in which you apply the policies.

To view the effective policy on a local system, complete the following steps:

  1. Access the local policy for the system you want to work with, as explained in the section of Chapter 4 entitled "Managing Local Group Policies." Or select Local Policy Settings on the Administrative Tools menu (if these tools are installed and you're currently logged on to the computer you want to examine).

  2. Access the policy node that you want to examine. Figure 8-4 shows the Password Policy node.

  3. With local policies, the Computer Setting column is replaced by a Local Setting column and an Effective Setting column. The Local Setting column shows the local policy settings. The Effective Setting column shows the policy settings that are being enforced on the local computer.

  4. If there are policy conflicts that you want to track down, review the sections of Chapter 4 entitled "In What Order Are Multiple Policies Applied?" and "When Are Group Policies Applied?"

Configuring Account Policies

As you learned in the previous section, there are three types of account policies: password policies, account lockout policies, and Kerberos policies. The sections that follow show you how to configure each one of these policies.

Figure 8-4: Local policies show the effective setting as well as the local setting.

Figure 8-4: Local policies show the effective setting as well as the local setting.
Configuring Password Policies

Password policies control security for passwords and they include

  • Enforce Password History

  • Maximum Password Age

  • Minimum Password Age

  • Minimum Password Length

  • Passwords Must Meet Complexity Requirements

  • Store Password Using Reversible Encryption For All Users In The Domain

The uses of these policies are discussed in the following sections.

Enforce Password History

Enforce Password History sets how frequently old passwords can be reused. You can use this policy to discourage users from changing back and forth between a set of common passwords. Windows 2000 can store up to 24 passwords for each user in the password history. By default, Windows 2000 stores one password in the password history.

To disable this feature, set the size of the password history to zero. To enable this feature, set the size of the password history using the Passwords Remember field. Windows 2000 will then track old passwords using a password history that is unique for each user, and users won't be allowed to reuse any of the stored passwords.

Note: To discourage users from cheating Enforce Password History, you shouldn't allow them to change passwords immediately. This will prevent users from changing their passwords several times to get back to their old passwords.

Maximum Password Age

Maximum Password Age determines how long users can keep a password before they have to change it. The aim is to periodically force users to change their passwords. When you use this feature, set a value that makes sense for your network. Generally, you use a shorter period when security is very important and a longer period when security is less important.

The default expiration date is 42 days, but set it to any value from 0 to 999. A value of zero specifies that passwords don't expire. Although you may be tempted to set no expiration date, users should change passwords regularly to ensure the network's security. Where security is a concern, good values are 30, 60, or 90 days. Where security is less important, good values are 120, 150, or 180 days.

Note: Windows 2000 notifies users when they're getting close to the password expiration date. Anytime the expiration date is less than 30 days away, users see a warning when they log on that they have to change their password within so many days.

Minimum Password Age

Minimum Password Age determines how long users must keep a password before they can change it. You can use this field to prevent users from cheating the password system by entering a new password and then changing it right back to the old one.

By default, Windows 2000 lets users change their passwords immediately. To prevent this, set a specific minimum age. Reasonable settings are from three to seven days. In this way, you make sure that users are less inclined to switch back to an old password but are able to change their passwords in a reasonable amount of time if they want to.

Minimum Password Length

Minimum Password Length sets the minimum number of characters for a password. If you haven't changed the default setting, you'll want to do so immediately. The default is to allow empty passwords (passwords with zero characters), which is definitely not a good idea.

For security reasons, you'll generally want passwords of at least eight characters. The reason for this is that long passwords are usually harder to crack than short ones. If you want greater security, set the minimum password length to 14 characters.

Passwords Must Meet Complexity Requirements

Beyond the basic password and account policies, Windows 2000 includes facilities for creating additional password controls. These facilities are available in the password filters, which can be installed on a domain controller. If you've installed a password filter, enable Passwords Must Meet Complexity Requirements. Passwords are then required to meet the filter's security requirement.

For example, the standard Windows NT filter (PASSFILT.DLL) enforces the use of secure passwords that follow these guidelines:

  • Passwords must be at least six characters long.

  • Passwords can't contain the user name, such as stevew, or parts of the user's full name, such as Steve.

  • Passwords must use three of the four available character types: lowercase letters, uppercase letters, numbers, and symbols.

Store Password Using Reversible Encryption

Passwords in the password database are encrypted. This encryption can't normally be reversed. If you want to allow the encryption to be reversed, enable Store Password Using Reversible Encryption For All Users In The Domain. Passwords are then stored with reversible encryption and can be recovered in case of emergency. Forgetting a password in not an emergency situation. Any administrator can change user passwords.

Configuring Account Lockout Policies

Account lockout policies control how and when accounts are locked out of the domain or the local system. These policies are

  • Account Lockout Threshold

  • Account Lockout Duration

  • Reset Account Lockout Threshold After

Account Lockout Threshold

Account Lockout Threshold sets the number of logon attempts that are allowed before an account is locked out. If you decide to use lockout controls, you should set this field to a value that balances the need to prevent account cracking against the needs of users who are having difficulty accessing their accounts.

The main reason users may not be able to access their accounts properly the first time is that they forgot their passwords. If this is the case, it may take them several attempts to log on properly. Workgroup users could also have problems accessing a remote system where their current passwords don't match the passwords the remote system expects. If this happens, several bad logon attempts may be recorded by the remote system before the user ever gets a prompt to enter the correct password. The reason is that Windows 2000 may attempt to automatically log on to the remote system. In a domain environment, this normally doesn't happen because of the Single Log-On feature.

You can set the lockout threshold to any value from 0 to 999. The lockout threshold is set to zero by default, which means that accounts won't be locked out because of invalid logon attempts. Any other value sets a specific lockout threshold. Keep in mind that the higher the lockout value, the higher the risk that a hacker may be able to break into your system. A reasonable range of values for this threshold is between 7 and 15. This is high enough to rule out user error and low enough to deter hackers.

Account Lockout Duration

If someone violates the lockout controls, Account Lockout Duration sets the length of time the account is locked. You can set the lockout duration to a specific length of time using a value between 1 and 99,999 minutes or to an indefinite length of time by setting the lockout duration to zero.

The best security policy is to lock the account indefinitely. When you do, only an administrator can unlock the account. This will prevent hackers from trying to access the system again and will force users who are locked out to seek help from an administrator, which is usually a good idea. By talking to the user, you can determine what the user is doing wrong and help the user avoid problems.

Tip When an account is locked out, access the Properties dialog box for the account in Active Directory Users And Computers. Then click the Account tab and clear the Account Is Locked Out check box. This unlocks the account.

Reset Account Lockout Threshold After

Every time a logon attempt fails, Windows 2000 raises the value of a threshold that tracks the number of bad logon attempts. Reset Account Lockout Threshold After determines how long the lockout threshold is maintained. This threshold is reset in one of two ways. If a user logs on successfully, the threshold is reset. If the waiting period for Reset Account Lockout Threshold After has elapsed since the last bad logon attempt, the threshold is also reset.

By default, the lockout threshold is maintained for one minute, but you can set any value from 1 to 99,999 minutes. As with Account Lockout Threshold, you need to select a value that balances security needs against user access needs. A good value is from one to two hours. This waiting period should be long enough to force hackers to wait longer than they want to before trying to access the account again.

Note: Bad logon attempts to a workstation against a password-protected screen saver don't increase the lockout threshold. Similarly, if you lock a server or workstation using Ctrl+Alt+Delete, bad logon attempts against the Unlock dialog box don't count.

Configuring Kerberos Policies

Kerberos version 5 is the primary authentication mechanism used in an Active Directory domain. To verify the identification of users and network services, Kerberos uses service tickets and user tickets. As you might expect, service tickets are used by Windows 2000 service processes and user tickets are used by user processes. Tickets contain encrypted data that confirm the identity of the user or service.

You can control ticket duration, renewal, and enforcement through the following policies:

  • Enforce User Logon Restrictions

  • Maximum Lifetime For Service Ticket

  • Maximum Lifetime For User Ticket

  • Maximum Lifetime For User Ticket Renewal

  • Maximum Tolerance For Computer Clock Synchronization

These policies are discussed in the sections that follow.

Caution: Only administrators with an intimate understanding of Kerberos security should change these policies. If you change these policies to inefficient settings, you may cause serious problems on the network. In most cases the default Kerberos policy settings work just fine.

Enforce User Logon Restrictions

Enforce User Logon Restrictions ensures that any restrictions placed on a user account are enforced. For example, if the user's logon hours are restricted, this policy is what enforces the restriction. By default, the policy is enabled and should only be disabled in rare circumstances.

Maximum Lifetime

Maximum Lifetime For Service Ticket and Maximum Lifetime For User Ticket set the maximum duration for which a service or user ticket is valid. By default, service tickets have a maximum duration of 41,760 minutes and user tickets have a maximum duration of 720 hours.

You can change the duration of tickets. For service tickets, the valid range is from 0 to 99,999 minutes. For user tickets, the valid range is from 0 to 99,999 hours. A value of zero effectively turns off expiration. Any other value sets a specific ticket lifetime.

A ticket that expires can be renewed, provided the renewal takes place within the time set for Maximum Lifetime For User Ticket Renewal. By default, the maximum renewal period is 60 days. You can change the renewal period to any value from 0 to 99,999 days. A value of zero effectively turns off the maximum renewal period and any other value sets a specific renewal period.

Maximum Tolerance

Maximum Tolerance For Computer Clock Synchronization is one of the few Kerberos policies that you may need to change. By default, computers in the domain must be synchronized within five minutes of each other. If they aren't, authentication fails.

If you have remote users that log on to the domain without synchronizing their clock to the network timeserver, you may need to adjust this value. You can set any value from 0 to 99,999.

from Microsoft Windows 2000 Administrator's Pocket Consultant by William R. Stanek. Copyright © 1999 Microsoft Corporation.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft