Windows Computer Authentication

When the Windows authentication subsystem was designed, it used a network connection to send user credentials to the domain controller for validation. When the network subsystem started, it would obtain a network address, if necessary for the protocol in use, and contact the domain controller. Besides validating user credentials, the domain offered several other services. Network administrators could define domain policies to control the behavior of any system in the domain, or login scripts to customize the user environment as part of the login process.

In the wired world, domain services are not a problem. Users attach to the network, and the system itself starts sending packets. When the Windows startup process was designed, there was no way of authenticating wired network connections. In the wireless world, though, where users must authenticate to active a wireless connection, network authentication can be a bit of a chicken and egg problem. Users can certainly authenticate to the wireless network once they supply credentials to the login box, but how can those credentials be validated without a network connection to send packets to the domain controller? Windows NT, 2000, and XP provide a partial solution in terms of credential caching. Once a user has successfully logged in to a computer that is a member of a Windows domain, credentials are cached for the future.

Credential caching is only part of the solution because it depends on logging in to the computer on a wired connection first. Microsoft has developed a much better solution called computer authentication or machine authentication. When the system first starts up, the computer authenticates to the wireless network as itself. With the wireless network up and operational, the computer can then download any required information from the domain and validate the credentials of any user against the domain controller. Users who have never logged in to the system and have no cached credentials can log in as well.

A fair amount of functionality depends on having a network connection early in the boot process. In addition to domain services, drive mappings are attempted early enough that they may fail if the computer is not authenticated. In most cases, Windows computer authentication should be considered mandatory for a smooth-functioning network.

To set up Windows computer authentication, you must have an Active Directory back end. Computers must have accounts defined in the Active Directory, and they must be granted Dial-In permission.

How It Works

Computer authentication adds an extra 802.1X authentication process to the boot process. First the computer authenticates as itself. After obtaining user credentials from the login box, a second 802.1X transaction is run to authenticate as the user. The process is shown in Figure 17-15.

The figure identifies several steps in the process. It starts when the computer comes up and starts its networking system. It begins an 802.1X authentication as the computer in parallel to other system start-up tasks.

1. The machine authentication is started. It may be started by an EAPOL-Start from the supplicant, or by a Request/Identity frame from the authenticator.
2. The network collects the identity of the machine. In the first authentication, the "user" identity is of the form host/ComputerName.ActiveDirectoryDomain, where both the ComputerName and the ActiveDirectoryDomain are available from the system properties.
3. The computer authenticates against its computer account on the RADIUS server, or in the back-end database behind the RADIUS server. This process may take several round-trips because of the need to exchange certificates, establish cryptographic keys, and so forth.

   Computer authentication uses the same EAP method as user authentication. If EAP-TLS is employed for user authentication, the computer must also have its own certificate. When PEAP is configured for user authentication, the computer uses EAP-MSCHAP-V2 as its inner method. The "password" used in the inner authentication is generated when the computer joins the domain, and is not available to any other software.

4. When the authentication succeeds, the computer is attached to the network. It receives an EAP-Success frame from the authenticator, and on wireless LANs, EAPOL-Key frames to provide keys for the connection.

   When authentication completes, the computer will be attached to the network, and can send and receive traffic. By sending a DHCP request, the computer can join the network and locate a nearby domain controller by using NetBIOS over

   Figure 17-15. Startup process with Windows computer authentication

    

   TCP/IP. Before user authentication, the computer can establish a relationship with the domain controller. The user presses Control-Alt-Delete to begin the login process. The system uses its connection to the domain controller to load the user login script, configure Windows domain policies, and perform other login tasks.

5. When the user desktop is about to start, the second authentication starts. The end user authentication must be triggered by the operating system. Typically, the machine authentication established at the start of the session is only used for a few minutes until the user authentication begins.
6. The network requests the identity of the end user. On Windows networks, this is typically of the form DOMAINuser, where the two components are the Windows NT-style domain name, and the user account.
7. The supplicant authenticates to the network with credentials from the user. With the Windows supplicant, the same EAP plug-in must be used for both the computer authentication and the user authentication. Like the previous step, it may require multiple round-trips to establish a secure cryptographic channel.
8. The user authentication succeeds, and keys are provided for the connection. These keys will be different from the computer keys because they are derived from a different TLS session.

Computer authentications can be treated separately from user authentications. Authorization of the two authentications may occur separately. For example, in a network that performs dynamic VLAN assignment, it may be possible to assign the computer account to a different VLAN from the user account. Early versions of the Microsoft supplicant did not trigger DHCP requests upon successful authentication, which prevented the user from sending and receiving traffic. Patches are available to fix this problem.