RADIUS and Authentication Woes
Network World Magazine recently ran a review of Cisco’s new ASA 5500 SSL VPN technology. Nestled in the review are a couple great tidbits about why direct integration between user directories and network infrastructure devices is a bad idea, and why the flexibility of your authentication infrastructure is key to allowing user AAA to work as promised by the tenets of NAC.
In our authentication and authorization tests, we discovered that while the ASA claims to support Active directory and Sun’s Lightweight Directory Access Protocol server, it didn’t support our schema of the Sun LDAP server. When we tried switching over to our SecurID RADIUS server, we discovered that Cisco fully supports the additional RADIUS messages required to integrate with SecurID.
However, Cisco had no flexibility in mapping users to groups, and would have required us to change our existing RADIUS schema, breaking all the other applications plugged into SecurID.
The two critical bits of learning here are first that in real-world deployments, schemas are rarely designed to support the network infrastructure device and often they are non-standard. This is one of the many reasons why direct integration from the network infrastructure device to the directory is architecturally a bad idea. The fact that this was exposed even in a test environment simply magnifies the concern. Second, many current RADIUS servers simply lack the capability to integrate the directories and network devices with the flexibility required by today’s deployments. Interconnecting between ethernet switches, firewalls, VPN gateways, wireless APs, dial-up servers, and Microsoft Active Directory, LDAP, and token servers requires approaching the policy-based AAA problem in a new way.