In the network access control products we tested, authentication varies from very strong to very weak, and every point in-between. When starting down your path of evaluating NAC products, decide very early what kind of authentication mechanism you want, if any.
In some cases, such as McAfee NAC, ForeScout CounterACT and Trustwave NAC, authentication is de-emphasised as part of the product philosophy, the emphasis is in some other area, typically endpoint security controls.
For example, Trustwave NAC includes an agent that runs on Windows Active Directory servers that can send user login/logout information to the Trustwave NAC appliance. This lets a particular device be associated with a user, assuming that the device was a Windows client workstation connected to the correct domain and the user logged into the device.
But this bit of authentication information is just one of many pieces that Trustwave NAC collects about each device on the network. The authentication detection is entirely passive, and not part of the lock-step workflow of getting a user on the network.
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.
We found other issues with these products when we were using them outside of their comfort envelope. For example, we set up McAfee NAC using 802.1X, and found that it uses incorrect information in the 802.1X transaction to detect user identity. That's the kind of bug that can only exist in a product where most of the organizations deploying the product are not focusing on authentication.
If you do care about authentication, you will find that the remaining products fall into two major categories: ones that encourage you to use 802.1X on wired switches and wireless networks, and ones that avoid it or work around it.
While 802.1X is acknowledged as the most secure way to do NAC authentication, the fear factor accompanying 802.1X is so great that there are more products in our test that avoid 802.1X than work well with it. The fear factor — that 802.1X will be too hard to manage on the network side and too hard to configure on the client side — is only slowly being overcome by improvements in switch software and Microsoft Windows.
The 802.1X category products (Avenda eTIPS, Enterasys NAC, HP ProCurve Identity Driven Manager, Juniper UAC, and to a lesser extent, Microsoft NAP and Symantec NAC) all actively participate in the authentication dialog and use 802.1X as a way of pushing access control to edge devices such as switches and wireless controllers.
In other cases, including Alcatel-Lucent Safe NAC, Bradford Network Sentry and Cisco NAC Appliance, the products all support 802.1X authentication, but the most common deployment path uses some other kind of authentication. For example, in Cisco NAC Appliance, if you want to avoid having users be interrupted by a web-based captive portal every time they sit down at their workstation, you can install a client on user workstations that will transparently pass authentication to the Cisco NAC Appliance.
However, don't get the idea that you can easily segment the world of NAC into 802.1X vs. non-802.1X, or that you should use one or the other exclusively. For example, in our testing, Juniper UAC worked well when users authenticated with their client over an IP network (for example when they were behind a VPN tunnel) or using 802.1X directly connected to a switch.
Bradford Network Sentry, Enterasys NAC and Juniper UAC offered the most options for different types of authentication scenarios. These would be on our short list if you wanted the widest array of authentication options.
Although 802.1X authentication has a reputation for being particularly difficult, we didn't find setting up NAC with 802.1X to be any more or less difficult than using other protocols. For example, we had one vendor who would only work with our Cisco 3750 switch in 802.1X mode when it had been upgraded to a particular version, while a different vendor recommended another version.
On the other hand, we experienced problems with multiple vendors, one on our Aruba wireless controller and one on our HP switch, when their SNMP management of the devices wouldn't control them correctly. So while we ran into issues, the 802.1X issues were no worse than the SNMP issues on the infrastructure side. Of course, since we focused on Windows 7 and Mac OS X, both 802.1X-ready clients, we didn't run into client headaches making 802.1X work.
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.