NT Authentication Using a Domain Controller

Now that basic steps are understood, consider a configuration in which user information is stored in an authentication server rather than on the login system. As in the case of NIS in the UNIX environment, this setup introduces a client-server interaction between the login workstation and the NT authentication server that is also called the domain controller.

The NT login panel enables you to choose whether you want to login using a particular domain controller or the local workstation. The distinction is that when logging in locally, your user information is verified against the local SAM database. If a domain name is entered in the login dialog box, I&A information is tested against the domain controller’s database. If a domain login is chosen, you still must enter your name and password. As in the local login example given previously, the password is hashed using MD4. The difference occurs in the protocol between the login node and the domain controller.

When the LSA determines that domain login is in process, the LSA communicates this to the authentication module (MVS 1_0). Instead of calling the local SAM routines as before, the authentication threads invoke the Netlogon service to contact the domain controller with an initialization message. The domain controller responds with a random value or nonce to be issued as a challenge to the login node. The NT login node encrypts the nonce with the hashed key derived from the user’s password. This encrypted value then is sent to the domain controller. Because the domain controller also has access to the hashed user password in its SAM database, the controller computes the same encryption. The two results are compared and login succeeds if there is a match. See Figure 2.3 for example NT logins.

Figure 2.3  Local and domain logins in NT.

Some additional variations require that administrators establish trust relationships between domain controllers. If a user chooses, a specific domain controller can be entered on the login dialog screen. In the case in which the login node relies on domain controller A for authentication, but the user has requested a different but trusted domain controller B, a protocol is defined for allowing the two domain controllers to work together to authenticate the user. The specifics of trust relationships are interesting but not particularly relevant for showing how one might improve the security of I&A in an NT environment. Instead, it is time to consider problems associated with depending on passwords for authenticating users.

For more details on NT login security, you might want to read Sheldon (1997) or Okuntseff (1997). The Microsoft Web site also contains security white papers that provide an overview of NT’s features.

You should know that Microsoft plans to modify a number of security relevant NT features in NT V5.0. User accounts will be stored in a directory service rather than in the registry and support for Kerberos Version 5 authentication (see section later in this chapter) will play a major role.

How Hackers Exploit Weaknesses in Password Security

With an out-of-box operating system, the same reusable password is entered by the user each time a login is performed. The biggest problem with reusable passwords is that they are susceptible to a variety of attacks that have a single goal: to uncover the user’s password. In the preceding chapter, this kind of security boundary was cited as a source of concerns. The login boundary is affected by three factors: the strength of the data provided by the user, the integrity of the data transmitted at the boundary, and safe communications at the boundary. A weak password is an example of the first factor. If the password is transmitted across a network, an adversary might be able to intercept and modify the value, validating the second type of concern. Finally, if the login programs are tampered with, and the boundary between the user and the computer becomes untrustworthy, the third factor is attacked. These three factors are targeted to varying degrees by the attacks described next.

Easily Guessed Passwords

The first weakness lies in the composition of the password itself. Passwords to avoid include the following:

•  Common names, especially relatives, coworkers, or dignitaries

•  Jargon words often found in a specialty area, such as the name of a football play

•  Simple strings, such as those composed of all the same character

•  Words found in dictionaries

•  Important numbers, such as your social security number, driver’s license, birthdays, or vehicle tags

When choosing a password, pick one that is hard to guess and also easy to remember. Often, these two goals are contradictory. However, if you pick pronounceable strings mixed with numbers or special characters, you will be making the task of the attacker more difficult. Increasing the size of the space someone must search through to guess a password is your goal. Longer passwords are better because there are more combinations of letters to consider. Klein (1990) provides an interesting set of metrics on how easy passwords are to guess.