Secure Authentication Features in Windows XP

This chapter is from the book

Windows XP Networking

Learn More Buy

This chapter is from the book

This chapter is from the book 

Windows XP Networking

Learn More Buy

Configuration and Recommended Practices

Part of a good security plan includes determining what rights and features will be available to a user that wishes to log on to Windows XP. Even if your Windows XP computer is not a member of a domain, it is important to ensure that it is protected from unauthorized access by other users on your network. The network to which you are connected may be just two devices using a wireless network, but if you are connected to the Internet via an "always on" connection such as DSL, you need to consider that your network now extends beyond just the boundaries of your home or office. Your username and password are the two pieces of information that you supply to get access to resources. It is important to protect these credentials, and establishing (and subsequently enforcing) a general policy on how these items will be treated in your network will go a long way toward keeping your network as safe as possible. Besides just protecting the log-on credentials, you need to devise a policy for limiting log-on access to resources on your network, to prevent unauthorized users from using "accidental backdoors" such as blank passwords or a guest account that has been given an exceptionally high level of privileges. You want to create the most restrictive local authentication policies you can for your network to prevent intruders from accessing information that you have not explicitly designated as public (such as a Web site).

This section discusses configuration and management of Windows XP credentials, authentication policies, and recommended practices. While previous sections referred to the domain log-on process, the information in this section is primarily for stand-alone Windows XP computers, because domain account management is beyond the scope of this book. Where applicable, however, specific caveats or recommendations are made in cases where domain-related issues are of particular importance.

Individual Account Settings

Some account settings affect only a single account. These settings govern certain aspects of that account's password and are configured from within the Local Users and Groups console. To access these settings:

1. Launch Control Panel, then select Administrative Tools, and then select Computer Management. (There are a number of other ways to reach this console besides this, but for the sake of discussion we limit it to this way for now.)

2. In the left-hand pane of the console select Local Users and Groups and then click on the Users subfolder. The users configured for this system appear in the right-hand pane of the console.

3. Right-click the user you wish to modify, and select Properties from the pop-up menu. The property sheet for that user appears, as shown in Figure 16.15. Click the boxes to enable or disable the settings as you desire.

   Figure 16.15 Configure individual account settings from within Local Users and Groups.

The configuration options for user account passwords are as follows:

1. User must change password at next logon: If you reset a user's password for them and assign a generic password, it may be helpful to require the user to change the password the next time they log on. The user selects a password that is easier for them to remember and reduces the possibility of other unauthorized users attempting to guess another user's password by using the generic password that was previously assigned to the unauthorized user. If this option is selected, however, the next two options are disabled.

2. User cannot change password: This option is useful when used in conjunction with accounts that are used by multiple people, such as Guest Accounts. This prevents one user from changing a password, thereby locking out all users of that account. It also reduces the administrative workload from having to reset this password and disseminating the new password to all users of that account.

3. Password never expires: This is another option useful for multiple-user accounts, such as Guest or Administrative Accounts. If you set a maximum password age in the global account policies (to be covered in the section below), it affects all accounts except for the accounts where this has been designated.

4. Account is disabled: By selecting this setting, the user cannot log on. You might wish to disable an account rather than deleting it; perhaps for a user that has left, but will be replaced with someone who will need to have access to the same resources as the previous user. Disabling it prevents unauthorized access to the network by users who know the current username and password combination. Once the replacement user has been determined, you should rename the account, change the password, and enable the account. This way the user account has the same SID and retains all previous rights and permissions.

5. Account is locked out: If a user has attempted to log on with incorrect credentials that exceed the maximum number of allowable attempts, this box is checked. An administrator can unlock the account by removing the check in this box. This setting cannot be selected by the administrator, only deselected. If you wish to quickly terminate user access, use the Account is disabled setting.

Stored User Names and Passwords

Windows XP includes a new tool that helps users maintain a library of passwords for accounts they have for a variety of resources, such as Web sites (sites that require Passport or SSL logon only), network resources, and so forth. It provides the illusion of having a single set of credentials for these resources, even for resources that you do not manage directly. For example, you have an administrative account on several computers in your network, but for security reasons you do not wish to log on with an administrative account. You also have a .NET Passport for use with a variety of Web sites, as well as the credentials you need for your online brokerage. By configuring these credentials in the Stored User Names and Passwords tool, they are saved as part of your profile and automatically presented to the resource to which you request to be logged on. To configure Stored User Names and Passwords:

1. Launch Control Panel and open User Accounts.

2. Select your account name and in the Related Tasks box, click Manage my network passwords. However, if this computer belongs to a domain, you select the Advanced tab, and then click Manage Passwords. The Stored User Names and Passwords dialog box appears, as shown in Figure 16.16.

   Figure 16.16 Manage Stored User Names and Passwords from within User Accounts in Control Panel.

3. Click the button that corresponds to the action you wish to perform. If you select Add or Properties, the Logon Information Properties dialog box appears, as shown in Figure 16.17. Simply add to or change the information stored here.

   Figure 16.17 Provide Server Name, User Name, and Password in Logon Information Properties.

You can also save credentials from a command line, if you prefer to use the command line rather than a GUI tool. The net use command provides the /savecred switch, used when the user is prompted for a username and/or password. The syntax for this command is either of the following examples:

1. When prompted only for a password:

   net use * \\computer_name\share_name /savecred
   

2. When prompted for both username and password:

   net use * \\computer_name\share_name /u:domain_name\user_name /savecred
   

Note that /savecred is used only in conjunction with devicename and is ignored when the remote resource does not prompt the user for credential presentation automatically. /savecred, when used with password *, only caches those credentials for the duration of the logon session, rather than saving them in Stored User Names and Passwords. Further, /savecred is only available in Windows XP Professional. It is ignored in Windows XP Home Edition.

Global Account Settings

Settings that affect all accounts are configured from within the Local Computer Policy console. They are grouped by function, which is how they are covered here. To open this console, launch Control Panel, then select Administrative Tools, then select Local Security Policy. Alternatively, you can open the Local Computer Policy snap-in within the Microsoft Management Console. The groups discussed in this section are found in Account Policies and Local Policies. Local account policies are applied in stand-alone Windows XP workstations, while domain members logging on to a Windows XP computer are subject to domain account policies.

Account Policies

Account policies include both password and account lockout–related settings. Password policy dictates password strength and lifespan, while account lockout specifies what, if anything, happens in the event that a user attempts to logon too many times with an incorrect credential set. To access these options, navigate to Computer Configuration, then Windows Settings, then Security Settings, then Account Policies, in the left-hand pane.

Let's look at Password Policy first. Clicking the Password Policy folder under Account Policy displays the configuration options, as shown in Figure 16.18.

Figure 16.18 Password Policies are managed from within the Local Security Policy console.

All of the options here are configured in accordance with a well thought out password policy that you must devise for your network. In addition to keeping passwords secret and safe, they should also be difficult to guess. You can accomplish this by requiring them to be strong, unique, and changed frequently.

• Maximum password age: Requiring users to change their passwords frequently helps prevent fraudulent use of passwords. The shorter the duration you set, the more often a user has to create a new one. This can be difficult for users when initially implemented, especially when this implementation is in conjunction with other settings. It also means an additional level of work for you, the administrator, who may have to assist with the reset of their passwords (although the Password Reset Wizard can provide some relief). You need to balance the aging requirement with the actual level of security requirements in your network.

• Enforce password history: This is a great one to set to keep users from defeating the requirement to change their password every so many days. Some crafty users will try to change their password to the exact same password, which really does not do much in the way of keeping things secure. By setting a history, users have to create a unique password each time they are forced to change their password.

• Minimum password age: This is another way to defeat the users who want to reuse the same password. This prevents him or her from changing the password n times, where n represents the number of unique passwords required in a single day, and reverting back to their original password.

• Minimum password length: By specifying a specific length of a password, you are doing two things—making passwords difficult to guess and preventing the use of blank passwords. Six characters is a recommended minimum, while 14 characters is the maximum permitted. By default, Windows XP workstations that are not part of a domain prevent users with blank passwords from logging on over the network. This is especially helpful for preventing unauthorized access to home workstations connected to the Internet. All blank password access is restricted to local logons only.

• Passwords must meet complexity requirements: In addition to requiring passwords of a minimum length, you can also require that they consist of both alphanumeric and special characters and use both upper- and lowercase letters. In addition, by enabling this policy, Windows XP prohibits users from including their username or their "friendly name" as configured in their account properties sheet as part of their password.

  To make it easier for users to remember long and seemingly random combinations of letters, symbols, and numbers, encourage them to create "passphrases." A good strong passphrase can be a nonsensical expression such as "Bob is your uncle" or "The White Sox won the pennant!" but with a twist—substitute numbers and symbols for letters and spaces. "Bob is your uncle" becomes B0b_1s_y0ur_unc1e, and "The White Sox won the pennant!" becomes The_Wh1te_S@x_W0n_the_pennant! Voila! Instant, difficult to guess (and type), but easy to remember password.

• Store passwords using reversible encryption for all users in the domain: This option should be selected only when CHAP authentication is required for Remote Access Service or Internet Authentication Service. Enabling this is equivalent to storing passwords in plain text, which is a definite security no-no! Enable only when absolutely required.

Now that you have made it difficult for fraudulent users to guess passwords, you need to limit their opportunity of trying to crack those passwords with dictionaries or manual attempts. The account lockout options are designed to do just that. These options are found in the same Account Policy area as Password Policy, shown in Figure 16.19.

• Account lockout threshold: The first option you need to configure is the number of bad log-on attempts permitted before the account is administratively disabled. By default, this is set at zero or disabled. No other account lockout options can be set until the threshold is set to some number above zero. The maximum number of attempts allowed is 999. The more secure the network, the lower this number should be. Three to five attempts should be adequate for most networks.

• Account lockout duration: This setting sets the amount of time that an account will be locked out. In other words, how many minutes will elapse from the time the account is locked out to the time that the account is unlocked and log-on attempts can begin again. A setting of zero means that the administrator must manually unlock the account. Setting the duration to 25 minutes strikes a nice balance between making a dictionary attack difficult and letting the administrator have enough time to get out of the office for lunch without having to return to unlock someone's account.

• Reset account lockout counter after: This setting provides yet another way to cut down on some of the administrative work of unlocking accounts. Windows XP tracks the number of bad log-on attempts in preparation to locking out an account. Specifying a span of time between a number of bad log-on attempts that are not sufficient to lock out the account and the point at which the bad log-on attempt counter is set not only slows down an intruder guessing passwords, but also provides an additional bit of room for error for a user who may have repeatedly fat-fingered a recently changed password.

Figure 16.19 Account Lockout Policy dictates when and how user accounts are disabled after too many bad attempts to log on.

When setting an account lockout policy, it is important to set up auditing and check the logs any time a user account is locked out and you are made aware of it. This way you can become aware of any suspicious log-on activity as soon as possible.

Changing the Way Users Log On

There are a number of ways the log-on experience for users can be modified, from requiring smart cards to automation of the log-on process to policies that limit time and location of logons. This section reviews these log-on process modifications.

Smart Cards

Smart cards are an excellent way to physically and logically secure access to your computer's resources. A smart card is very similar to an ATM card: In order to complete a transaction, both the card and a PIN are required. The card is read in a reader attached to the computer, and the user is prompted to enter his or her PIN. When smart cards are used, this credential combination is used in place of the account password stored within the operating system.

Smart cards use public and private key cryptography and can only be used for domain account authentication; local account authentication is not supported on Windows XP. Kerberos version 5 protocol is used with smart cards to authenticate to Windows 2000 domains, while Kerberos with x.509 v3 certificates are used with non–Windows 2000 domains. Unlike passwords, smart card PINs are not sent over the network. Like Windows accounts, smart cards can be set to lock after too many bad log-on attempts. An administrator must unlock any locked cards.

Automating Logon

Going in the opposite direction from the security provided by smart cards is the ability to automate user logons. When automated logon is configured, users do not have to use the Control + Alt + Delete command to initiate logon, nor do they enter a username or password. Instead, user credentials are stored in the registry, which is then parsed for this information when required for loading a specific user's operating system environment.

It is highly recommended that any computer configured with automatic logon be physically secure and protected from unauthorized network access. While automatic logon offers a great deal of convenience to users, because they can boot up and get right to work on their Windows XP computer, it also leaves a gaping hole where a certain level of security would have been provided by entering user credentials. All users of that system have access to all network resources that are granted to the account that was logged on automatically. As you can imagine, this is a dangerous situation. Even weak passwords can provide a higher level of local logon deterrence to unauthorized users. The log-on screen works in much the same way a sign alerting intruders to the presence of a burglar alarm works. A trespasser is not sure if there really is an alarm system, and may not be willing to risk finding out one is truly installed. An unauthorized user may not be willing to take the 10 or 15 extra seconds to figure out what the weak password is before he or she is caught with the proverbial hand in the cookie jar. Another danger point with automated logons is that user passwords are stored in plain text in the registry. Any remote user that is a member of the Authenticated Users group by default has access to the key where this is stored. This makes it an easy target for users looking for unauthorized access to the files of another user.

To set up automated logon you must edit the registry. As always, use extreme caution when making modifications to the registry and be sure you have a good backup before you start. Any registry change can have unexpected and unpleasant results. When you are ready to proceed, you perform the following steps:

1. Open a registry editor, such as regedit.exe.

2. Locate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

3. Double-click DefaultUserName.

4. In the Value data box, type the username, and then click OK.

5. Double-click DefaultPassword.

6. In the Value data field, type the password and click OK.

7. Double-click AutoAdminLogon.

8. Enter 1 in the Value data box and click OK.

Changes take effect on the next reboot.

Disabling the Welcome Screen

The Windows XP Welcome screen provides the usernames of all users with local accounts on a computer. Users viewing this screen can attempt to log on with the username of another user by guessing the password. If this is an unacceptable risk in your network and you are not in a domain, you can use the traditional Control + Alt + Delete screen instead. To do so, perform these steps:

1. Open Control Panel, click User Accounts.

2. Click Change the way users log on or off.

3. Remove the check in the Use the Welcome screen check box.