Network access control authentication: Are you ready for 802.1X?

If you care about authentication of users, be careful about this category of product, because their mechanism for detecting authentication information can be unreliable, due to the nature of the protocols they are trying to sniff. Capturing 802.1X and Kerberos logins as they fly by sounds elegant, but you can't necessarily get all the information you need out of what you see on the wire. This is why Trustwave technicians installed their software agent on our Windows server — they are afraid that one day soon Microsoft will start encrypting the communications during login and the authentication information will be unavailable.

The question of authentication

The question of authentication and NAC has other dimensions than just deciding whether you want to use 802.1X or not. In our testing, we looked at three special cases that may be important to many networks: domain devices without users in front of them (such as a domain-connected PC which is not logged in, but which should be accessible for remote management and patching), browserless/userless devices (such as VoIP phones and printers) that generally require media access control (MAC)-based authentication, and guest users.

A common problem in NAC deployments is dealing with userless and browserless devices, such as printers and VoIP phones. Of course, if you want to avoid the problem, you can make sure the ports these devices are plugged into are not part of your NAC deployment — but then you've got ports that people can walk up to and borrow for a few evil moments. That scenario frightens some network managers, but not all, since those ports would normally be restricted to a well-firewalled printer subnet. In our testing, we wanted to look at a common difficult case, a network with edge switch ports that could be used just as easily by end users as by printers.