Windows NT Logon and Authentication

Logon to Windows NT systems is handled by a service called NETLOGON and coordinated by the Local Security Authority (LSA). These components are all part of the security subsystem. Understanding the logon process is important because these features are critical to providing secure logon over the Internet.

There are three types of logon as described below:

•  Local logon. Occurs when a user logs into an account stored in the local computer’s user account database.

•  Domain logon. Occurs when a user logs into an account stored in the domain user account database.

•  Trusted Domain logon. Occurs when a user logs into an account stored in the user account database of a trusted domain.

When you first log on to a Windows NT Workstation computer, the dialog box in figure 12.4 appears. This dialog box lets you choose which of the preceding logons you want to do. In the Domain field, you can choose the name of the local Windows NT Workstation computer, a local domain, or a remote domain.

Figure 12.4  The Domain field in the Logon dialog box is where you choose to log on to a local system or a domain.

This initial logon procedure is called interactive logon because you must type information at the keyboard to log on. In contrast, a remote logon procedure takes place after you have already logged on and you attempt to access another computer. In this case, the credentials you already entered are used to run the same logon procedure with the other computer in the background. The details of this procedure are discussed in a moment.

With Windows NT, you always press Ctrl+Alt+Del to log on. This ensures that the system is essentially “rebooted” and removes any Trojan utilities and presents the Windows NT logon dialog box. For example, another employee could create a fake logon utility that is designed to capture your password for later retrieval. Ctrl+Alt+Del will kill the utility.

After pressing Ctrl+Alt+Del, the logon screen in figure 12.4 appears. After you type a user name and password, choose the local server or a domain in the Domain field. If you choose to log on locally, the logon process pictured in the left side of figure 12.5 takes place. Refer to figure 12.2 for an illustration of the security subsystem.

Figure 12.5  The local logon process is shown on the left and a remote log on process is shown on the right

Here are the steps of the local logon process:

1.  The user presses Ctrl+Alt+Del to log on.

2.  The logon process (NETLOGON) calls the LSA and the LSA runs the authentication package in use. As mentioned previously, a third-party authentication scheme such as a token scheme can replace the default authentication scheme.

3.  The LSA contacts the SAM, which in turn looks up the logon name and password in the local user account database.

4.  If it checks out, the SAM returns the SID (security identifier) for the user and the SID for any groups the user belongs to.

5.  The LSA creates an access token with the SIDs and sends the token to the logon process.

The logon process uses the access token to start an initial process for the user (the shell, that is, user desktop) and every time the user accesses resources.

If you have an account on a domain server, you can choose to log on to the domain at the initial interactive logon as pictured in the right side of figure 12.5. In this case, a challenge/response logon mechanism verifies who you are as discussed in the next section and the NETLOGON procedure occurs on the domain server. The domain server goes through the steps described above to validate your account in the user account database, which is stored on the domain server. The SIDs are retrieved and passed back up to the domain server’s NETLOGON service which in turn sends them to NETLOGON on your computer, which creates access tokens.

In some cases, a user might be visiting another division or department, and logs on to a computer in a different domain. In this case, the user can type the name of his or her home domain to log on. The procedure above is executed except that the local domain server passes the credential to the home domain server for verification. The SIDS are then passed back to the workstation where the user is logging in and an access token is created for that user’s current session.