|
Troubleshooting Checklist for 802.1X on Your WLAN
By Eric Geier (NoWiresSecurity Founder
& CEO) - originally published on
EnterpriseNetworkingPlanet
WPA/WPA2-Enterprise with 802.1X
authentication provides secure and robust Wi-Fi security for
businesses. Though 802.1X isn't the easiest protocol to implement,
it should be a must for all organizations with more than a couple of
employees using the wireless network. In this tutorial, we'll
discuss how to troubleshoot 802.1X client issues.
Verify Client Settings
The 802.1X settings on the client is a
frequent trouble spot and is likely the cause if the problem is
isolated to a single client. You should verify all encryption and
authentication settings are correctly configured.
If the client is using Windows with a third-party wireless
connection manager and/or 802.1X supplicant, you might want to
disable or uninstall them and revert to using Windows. If the client
is another OS or mobile device, you should verify settings similar
to those discussed here.
In Windows, bring up the network profile or properties window
(figure 1 shows an example) and start by verifying you have selected
the right authentication and encryption settings. For instance, WPA
with TKIP or WPA2 with AES, depending upon which is supported by
your access points (APs).
In Windows 7, you'll also find an Advanced button on the Security
tab of the Wireless Network Properties window. Click it and verify
those settings, such as seen in figure 2. One key setting is the
authentication mode. If you're unsure about it, select User or
computer authentication.
Next verify the right authentication method: Protected EAP (PEAP) or
Smart Card or other certificate for EAP-TLS. If you're using a
third-party supplicant instead of the one built into Windows, make
sure it's selected.
Next, open the Protected EAP (PEAP) or Smart Card or other
certificate settings by clicking the Settings button in Windows
Vista and 7 or clicking the Properties button in Windows XP. Figure
3 shows an example of the Protected EAP (PEAP) settings and figure 4
of the Smart Card or other certificate settings.
For either authentication method, verify the selected server
certificate. Double-click on it to verify it's the right one and not
expired. If you have a server specified in the Connect to these
servers field, consider disabling that option for now to see if that
might be the issue. Furthermore, you might uncheck the Validate
server certificate option temporally to see if the problem might be
related to the server certificate. Just remember to re-enable it
later for security reasons.
If using Protected EAP (PEAP), ensure the Secured password (EAP-MSCHAP
v2) option is selected on the Properties dialog. Then click the
Configure button to verify the setting (see figure 5), which should
only be selected if the user credentials on the RADIUS server match
the Windows account credentials.
If using EAP-TLS with a Smart Card or certificate, verify the
settings on the Properties dialog. If using certificates, make sure
it's properly installed on the computer via the Microsoft Management
Console (MMC).
After you've verified the settings, you might try connecting again.
If using PEAP, be sure to use the correct username and password, and
domain if required.
One last client setting you might want to check is the system date
and time in Windows. An incorrect date or time can be a problem
since the server and user certificates are time-sensitive.
Check RADIUS Server
If you've verified the client settings
and are still having problems you might want to check the RADIUS
server, whether you're running IAS or NPS on a Windows Server,
FreeRADIUS, or another authentication server. Verify it's up and
check the logs to see if there are any clues. Also verify that the
user database and any other required databases are running.
If all or many clients are having issues, the problem likely is with
the authentication server. If you have a smaller network it may take
awhile to see issues with more clients, as they will at least remain
connected to the wireless LAN until they try to authenticate with
the server again.
Check Access Point or Switch
You may want to check the wireless
access point (AP) or switch that the problem client is connecting
through. If the problem seems to be through a particular AP or
switch, double check the IP address to what you have setup in the
RADIUS server. Remember you must assign static IPs to the APs and
switches since that is how the RADIUS server identifies them. Also
verify the corresponding Shared Secret and other authentication
settings on the AP or switch.
General Network Issues
Sometimes the problem might not even
be related to 802.1X and just be a basic networking issue.
Double-check that the problem client is connecting to the correct
SSID. If you're connecting an older 802.11b client to an 802.11n
network, it might not work even though the two standards to suppose
to be compatible. Also ensure the compatibility of the network
adapter and operating system with WPA or WPA2 encryption.
If it's an older adapter, you can try to download and install an
updated driver that might give you better interoperability and/or
WPA/WPA2 support.
You may also find that the operating system is lacking WPA or WPA2
support. For Windows XP without any Service Pack installed, an
update is available for adding WPA support. For Windows XP or
Windows XP Service Pack 2, an update is available for adding WPA2
support. Windows XP Service Pack 3 contains both of these updates
already.
Review User Settings and Attributes on RADIUS Server
If you've already verified the client
settings and think this is an isolated issue, you might want to
review the settings and attributes assigned to that specific user on
the RADIUS server.
If you've assigned any custom attributes, you may want to disable
them to see if they might be causing an issue. For example, you may
have limited access to specific access points or switches with the
NAS-Identifier or Called-Station-Identifier, or limited access from
specific network adapters with the Calling-Station-Identifier. Most
RADIUS servers also let you set login-times and an expiration
date/time, which might cause an issue. If using VLANs, you might see
if there are any problems there.
Perform Tracing and Review Client Logs
If the client is running Windows, you
can use the tracing features of the Netsh command-line tool to help
identify the underlying issue. For tracing of various networking
components in Windows XP or later, you can use the netsh ras
commands. In Windows Vista or later, you can perform wireless
tracing with the netsh wlan commands.
If you're using a third-party 802.1X supplicant, you might check any
available logs.
Conclusion
We discussed the key methods of
troubleshooting 802.1X client issues. If you're now questioning
802.1X, keep in mind these 15 reasons to use 802.1X. You might also
want to check out another piece that discusses overcoming the common
802.1x deployment issues including simplifying client configuration. |
