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.
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.
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.
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.
Introduction to Wireless Networking
Overview of 802.11 Networks
11 MAC Fundamentals
11 Framing in Detail
Wired Equivalent Privacy (WEP)
User Authentication with 802.1X
11i: Robust Security Networks, TKIP, and CCMP
Contention-Free Service with the PCF
Physical Layer Overview
The Frequency-Hopping (FH) PHY
The Direct Sequence PHYs: DSSS and HR/DSSS (802.11b)
11a and 802.11j: 5-GHz OFDM PHY
11g: The Extended-Rate PHY (ERP)
A Peek Ahead at 802.11n: MIMO-OFDM
Using 802.11 on Windows
11 on the Macintosh
Using 802.11 on Linux
Using 802.11 Access Points
Logical Wireless Network Architecture
Site Planning and Project Management
11 Network Analysis
11 Performance Tuning
Conclusions and Predictions