We also tested the ASA CX's ability to use user- and group-based identification as part of application controls. Anyone who has tried to deploy identity-based networking or NAC knows that one of the hardest parts is gathering the identity from the user or device. The ASA CX has two mechanisms available to it: one is a captive portal approach, which works in certain guest user environments where people don't have much opportunity to complain. The other is called "passive authentication" and it depends on installing a Cisco agent on Windows domain controllers in a network. When a Windows user logs onto their domain-connected PC, this generates an incidental log entry in the Windows Event Logs which happens to have the apparent IP address of the PC as well as the user name used to login. We installed this agent on our lab's domain controllers very easily and were able to link the ASA CX authentication controls to user identity. Sort-of.
It happens that our lab has some internal NAT going on to simplify routing when we build networks quickly for tests like this and this confounded the ASA CX, as the user-to-IP mappings were not correct. The same issue would happen in any network with NAT between the PC and the domain controllers. Of course, there are also scalability issues — if one domain is all you need, that's great, but some enterprises have dozens or even hundreds of domains running around on their wide area network. Of course, this only works for domain-attached Windows PCs — still a dominant force in enterprise networks, but not the only way to deliver computing nowadays. And let's not even mention that there's no real tracking of when someone disconnects from the LAN.
None of this is Cisco's fault — any vendor who tries the hokey pokey of sniffing Windows logins or capturing the information from the logs is going to have the same problem. There are other tricks and techniques various NAC vendors have created to work around this fundamental problem, but the only 100% real solution is having a client tool on the connecting PC which collects authentication information and interacts actively with enforcement devices.
And this brings us to a serious problem in the ASA CX: all of Cisco's products for NAC, and all of Cisco's products for Secure Mobility, don't interact with the ASA CX. The problem is especially ludicrous when it comes to remote access VPN — even if the remote access tunnel is connected to the ASA CX, it stubbornly won't pass user identity information up to the CX.
Failing to make this obvious link even in a v1.0 product like the ASA CX is poor product management.
Sign up for CIO Asia eNewsletters.