The Challenge/Response Logon

Windows NT computers use the challenge/response authentication mechanism to validate user logons. Challenge/response is discussed in detail in Chapter 10, “Encryption Overview,” but it basically provides a way to validate and log on a user without transmitting a password across the wire. Once authenticated, the user can access a system or network with the rights and privileges assigned to that account. Any attempt to access resources on other computers causes another authentication in the background using the original credentials.

When a Windows NT server is set up on the Internet and the Microsoft Internet Information Server (IIS) is installed, the same authentication protocol can be used to verify users as long as they are running a compatible web browser that supports Windows NT Challenge/Response authentication and as long the IIS server is set up use it. Using this type of authentication for web servers allows strict control of who can access a server based on predefined user accounts. This is discussed later in the IIS section.

Here’s how the challenge/response mechanism works:

•  When a user attempts to log on, challenge the user to return a piece of information that only that user (and the server) knows.

This process relies on a “shared secret.” When the administrator created the user account, a password is defined at the domain server and a copy is given to the user. Thus, the server and the user share a secret password.

The challenge is in the form of a “nonce,” which is a one-time nonsensical message that pertains to only the current logon. The steps for this process are outlined below. To keep things simple, assume the user is logging onto the same server that is the primary domain controller (that is, the primary location of the user account database). This eliminates the need to discuss any additional steps that take place in a situation where the target server does not have a copy of the user account database and must itself contact the domain controller.

1.  The client attempts to log on to the domain server.

2.  The server sends a challenge (called a nonce) to the client’s logon process.

3.  The client’s logon process then combines the nonce with the client’s logon name and encrypts them. The client’s password serves as the key for the encryption.

4.  The results of this encryption are returned to the server.

5.  The server performs its own encryption by combining a copy of the nonce it sent in step 2 with the logon name of the client, then encrypting it with a hash (one-way encryption) of the client’s password (which is stored locally).

6.  The results of this encryption are compared with the response from the client.

7.  If the results of step 5 compare with the response sent by the client, the client is considered valid and is logged on.

Note in step 3 that the client’s password is used to encrypt the response. This password is actually encrypted itself with a one-way function and the results of that encryption are the key. The password is never sent across the wire. Also note in step 6 that the encrypted results are compared. There is no need to decrypt anything.

An important concept to remember for later is that while the logon session is secured using encryption, nonces, and other techniques (once the user is logged on), session information is basically transmitted in the clear. A hacker could eavesdrop on the transmissions, obtain the users ID for this session, and insert his own requests to the server using that ID. To avoid this problem, session encryption is necessary (see Chapter 10 for more information on encryption). Microsoft Internet Information Server (IIS) supports SSL and PCT between server and client to provide secure sessions as discussed later.

Intranet-Related Features in Windows NT

Before going further, you need to know about a few Windows NT system services. These services apply to intranet environments, where you are setting up TCP/IP-based web services for internal use. Specifically, this section will cover the following three possibilities:

•  DNS Servers

•  NetBIOS Name Resolution

•  WINS Servers

Using a DNS Server in an Intranet

One problem in any network environment is providing a way for users to access servers by using easy-to-remember names rather than cryptic numeric network addresses. For example, to access a web server on the Internet, you type the domain name of the web server (that is, http://www.whitehouse.com) rather than the IP address (that is, 186.37.65.3). The underlying network, however, can only use IP addresses. The DNS (domain name system) makes this possible by converting the domain name into an IP address. DNS servers are located all over the Internet and, when you sign up with an Internet service provider, they usually give the IP address of the nearest DNS server that your web browser can use to “resolve” DNS names to IP addresses. Internal networks can also have DNS servers to resolve names and addresses for internal systems. Organizations that have set up internal TCP/IP based web services often install their own DNS servers. That way, internal users can use the DNS server to resolve a friendly server name into the appropriate internal IP address. Microsoft has its own DNS server that you can choose to install internally to perform name resolution.

Using NetBIOS Name Resolution in an Intranet

However, DNS servers are hard to configure and maintain. In addition, Windows networks already have their own naming service that uses the NetBIOS naming scheme. With this scheme, a user can access an internal web server from his web browser by simply typing the NetBIOS name of the web server in the browser’s address field. When you install any Windows computer on a network, you are asked to supply a name for the computer. This name becomes the NetBIOS name that is used to identify that computer on the network.

NetBIOS name resolution is automatically handled by a broadcasting technique in which systems announce themselves on the network. The problem with this base-level scheme is that it is clunky and slow. An alternative is to use a static mapping scheme in which names are associated with computers in a file called LMHOSTS. But the LMHOSTS file is hard to configure.