Passwords

Many administrators use a method of combining initials and numbers for passwords and keep them consistent throughout the enterprise.

To set up your password convention checklist, consider the following:

♦ The passwords can be up to 128 characters in length. That does not mean that Microsoft expects you to saddle your users with a password that takes all day to input, but smart cards and noninteractive logon devices can use a field of that length.

♦ Do not create passwords that contain fewer than five characters; a minimum of eight is recommended.

♦ The following characters are not permissible in the password: "/ \ I ; : = , + [ ].

Password management is a nightmare for everyone. Most administrators we know keep lists of passwords in various database files and help desks because users often find themselves locked out of domains and resources for "no apparent reason." To troubleshoot and assist users, we often need to log on to a user's account and "experience" what may be going wrong. Many administrators troubleshoot this way; being in the user's context helps in troubleshooting. The new RunAs service that we describe in the section "Getting familiar with RunAs," earlier in this chapter, is a useful tool for managing user accounts and troubleshooting passwords.

The password issuance and management-style challenges are similar from platform to platform, especially from NetWare to Windows NT and Windows Server 2003. Regarding the use of user passwords, the following three options are available:

♦ Assign the passwords.

♦ Enable the user to choose the password.

♦ Assign passwords to certain users; enable others to set their own.

All three options have their pros and cons, and every company has a reason for going with one option or the other. If you go with the first option, you must either adopt a password-naming scheme that lends itself to easy recollection by administrators (as secure as an open field) or enter the users' passwords in a secure database.

The former is not really secure because figuring out the scheme that the administrators are using would not take much effort. A popular password-forming approach is to join a user's initials and part of his or her social security numbers, driver's license number, or some other form of number that society issues — for example, jrs0934. This scheme has been in place at several companies where we worked. In that several thousand accounts were set up under the scheme, changing it has been a nightmare.

The second approach, enabling users to select their own passwords, is fraught with danger. First, users who have a lot of sensitive information on their machines and in their folders often assign weak passwords that can easily be cracked. We have found users choosing 12345678 and giving us the excuse that they were going to change it later . . . three months later.

Second, enabling users to choose their own passwords can be nightmarish on corporate networks. In troubleshooting problems, administrators often need to ask for the passwords over the telephone (for all to hear) and in e-mail. Then there are the occasions where you must reset the password anyway because the owner is either not present or Windows Server 2003 rejects the password.

We believe that the best policy is to let users choose their own passwords and then govern them with a sound password management policy, as described in Chapter 12. You can assign a password for most corporate users if you have a specific reason, and enable selected users (who demand the security and who can justify it) to set their own passwords. The latter users fall into groups that have access to company financial information, bank account numbers, credit card numbers, personnel records, and so on. Paranoid executives fall into the latter group as well. For the most part, this practice is archaic.

For service accounts, generate secure passwords (as opposed to obvious acronyms). Record the password in a secure place: either a database management system that is hard to crack, such as an encrypted Microsoft Access database file, or in an SQL Server table.

Protecting passwords is more important under Windows Server 2003 than under Windows NT — or any other OS, for that matter. The reason is the Single Sign-On (SSO) initiative and the Kerberos ticket-granting service discussed in Chapter 3. On older OSs, you need new user IDs and passwords for just about any service, such as voice mail, fax mail, SQL Server, Internet access, and so on. As more applications support the SSO, one password eventually suffices for all. This is a double-edged sword, however. If the password or access falls into mischievous hands, the culprit has access to everything authenticated in the SSO process.

Was this article helpful?

0 0

Post a comment