Our wireless network consists of Wireless LAN Controllers and multiple APs. We require 802.1x authentication on our SSID. We use IAS as our authentication server for both machines and users. Each device connecting to our WLAN is required to have a certificate issued from one of our DCs. Each device and user is also required to be in specific AD Groups, checked by IAS.
Can someone please let me know what the steps are when a Wireless Client tries to connect to this wireless network, from selecting the SSID to being able to communicate on the WLAN? If things happen prior to this, please include those steps as well.
We are occassionally experiencing issues where some clients will stop communicating with the network altogether. To resolve the problem we plug the device into the network and reboot and login to AD.
It sounds like a CA issue. Does it occur to only a few clients occasionally, or all clients occasionally? Is your root CA connected to the network, or do you only have Distribution CAs up and connected to the network?
Does it happen to only a few clients at a time, or all clients? Having to log back into the domain to fix the issue makes it sounds like a CA problem. Is it a stand alone CA, or is it integrated with active directory?
Can you update those clients' adapter drivers? Is it happening to the same clients over and over, or does it work its way around to random clients?
It's recommended that the IAS server runs on a DC. If you have multiple sites, you should have IAS servers running on the local DC. I've had a lot of problems with WL/.1x authentication on IAS server accross WAN links exectly as you describe.
Heres what happens as I see it on capture files:
When a STA wants to access an existing BSS (either after power up, sleep mode or simply just entering the RF BSS domain), the station needs to get synchronisation information from the AP.
It can get this information by one of two ways:
Passive scanning of the RF: STA just waits and received Beacon frames from the AP(s) sent periodically by all APs with the synchronisation information
Active scanning: The STA tries to actively find an AP by transmitting a probe request frame which can either contain the name of the SSID it wants to connect to, or I believe the probe request can be a broadcast to allow all APs to send their SSIDs back in probe responses (Excerpt from the definite guide: Probe Requests: This may be set to the SSID of a specific network or set to join any compatible network. Drivers that allow cards to join any network use the broadcast SSID in Probe Requests.)
Note: The AP responds with its security capabilities in the RSNIE field of the Probe Response frame if you have configure dot1x on the WLAN; this includes all of its enabled encryption and authentication capabilities etc etc etc, if you have a guest WLAN with web-auth, there is no RSN field. Also, the probe response do all the usual 802.11 management stuff like advertised data rates, ssid, QoS etc etc etc
When the STA receives the Probe Response or desire beacon frame, it performs open system authentication
—null authentication—with the AP. The purpose of this frame sequence, which provides no security, is simply to maintain backward compatibility with the IEEE 802.11 state machine, as implemented in existing IEEE 802.11 hardware.
Step 3Now the station sends a the all important packet to try to connect to the selected AP and thus BSS. It sends the association Request. In the frame is contains the RSN tagged data that should match that of the RSNIE in the prevision probe response.
The AP send back an association response. This frame has a field in the fixed parameters that either says Successful Status code 0x0000 and an association ID or some other value which im not sure of at this time.
The STA and AP are Connected.
Optionally, the STA can send an EAPOL start which is fired off to the AP, LWAPPed up to the WLC. This is the STA starting the real authentication process, (not that that is describe in step 2 above). Like I say, this is optional, if the STA does not send this packet, the WLC just sends an EAP-Identity request. Sometimes you see a WLC eap-identity request come into the STA before it has had a chance to send the option al EAPOL start frame to the WLC. EAPOL-start packet contains just a 802.1x start message. The STA is saying lets start the 802.1x handshake. Eap-Reqest ID packets just contain the SSID and WLC identity
STA now has to send its identity to the WLC. Basically, hostname, device name etc etc. Again, this is LWAPPed up to the WLC and now the WLC forwards this packet encapsulated/converted ina Radius access-request packet to the configured RADIUS server on the WLAN.
Radius server sends a Radius packet to the WLC which now converts it into an eap-request packet (just the same as the eap-packet in step 5) and the WLC fires that down to the client. The difference in the eap-reuqest packet in this step as supposed to the one in step 5, is that it is not an eap-request identify (type 1), it is an eap-request protocol packet, ie type code 13 for EAP-TLS.
EAP-Exchange, ei, EAP-TLS, EAP-PEAP between STA and Radius Server via WLC. If good, get an eap-success from Radius server to STA, if bad, EAP-Failure message.
WLC and STA now build session keys and this is the EAPOL Four-way handshake between STA and WLC.
Step10 (at last)
Get a DHCP IP address hopefully