RSA SecurID token access integration with Cisco ASA VPN?

Hey guys,

I thought of posting this in the CCSP/CCNP-Security forum but figured this is applicable beyond that scope.

Does anyone have direct experience with implementing RSA SecurID tokens for multi-factor access to Cisco ASA55xx VPN systems? I basically got a boatload of RSA appliances and need to develop a proof of concept sometime over the next two weeks. The RSA documentation is pretty straight forward and so is the Cisco documentation, but I wanted to know more about potential pitfalls or implementation problems that some of you may have experienced. I don't have a whole lot of time to get a working proof of concept so I'd like to find out more about other people's successful deployments to improve my chances of success.

The goal is to implement multi-factor auth using RSA SecurID tokens and the RSA SecurID appliances. I understand that I can use on-box RADIUS on the SecurID appliance or I can integrate with the ASA / ACS RADIUS server. Currently I’m testing the RSA Built-in RADIUS as it appears to be easier to configure. Is this true? I have Cisco ACS in my lab as well so if that is a better option than I’m all about that. I haven’t set up anything other than importing tokens, setting up an on-box radius server, creating an admin account for myself, and installing in my lab. All options are on the table at this point. I literally just got a pallet full of appliances and tokens like the other day.

Basically I just want to engage in a dialogue about integrating Cisco VPN with RSA. I have very little working knowledge of Cisco ASAs when it comes to VPN configuration so any help or insight would be appreciated. What has worked for you? What hasn’t? If you could re-do your implementation what would you do differently? If you love your config, how is it set up?

Thanks guys!

Paul B.

Find more posts tagged with

Comments

Hypntick

I've got a pitfall for ya. The user is going to input the code incorrectly a few times, lock themselves out and have to call the help desk.

/end help desk rant.

cisco_trooper

I'd like to know as well. I'm currently looking at this for Q4. I currently have IPSec VPN deployed with VPN Clients on remote machines. I'm currently deploying certificates to the individuals with a need for remote access. So each user has a certificate that is password protected that only they have and only they know, but they also have to enter their LDAP credentials once the certificate is authenticated by the CA.

docrice

My experience is with the RSA server software, not the appliance, but here goes...

I haven't set up RSA Authentication Manager with an ASA, but I have with the older 3000 series concentrators. You have the option of using either the RSA SDI auth or RADIUS (the latter being that the RADIUS traffic goes over the wire in clear; even though it's on the internal network and the user password is hashed out, all other attributes are in plaintext).

The RSA RADIUS is essentially licensed code from Juniper (formerly Funk) SBR, and I'm assuming that's the case with the appliance version. I'm speaking from experience on the 5.x and 6.x versions of RSA Auth Manager, however, as the 7.x series got me scared with the amount of apparent overhead required (server system requirements-wise) to install and get running a simple token management system. One thing I didn't care for regarding the 6.x Auth Manager interface is the logging. The interface is really dated as well.

As Hypntick, pin resets can present a bottleneck, as well as token-reissuing when it expires. In the long run for production, I think the more common scenario is to utilize ACS or NPS to centralize user credentials, but this depends on environment needs.

cisco_trooper

docrice wrote: »

As Hypntick, pin resets can present a bottleneck, as well as token-reissuing when it expires. In the long run for production, I think the more common scenario is to utilize ACS or NPS to centralize user credentials, but this depends on environment needs.

So the token's have to be reissued? How often does this have to happen, and how long does it take? One of the things I was hoping to get away from was having to reissue certificates all the time. It's a hassle for my users and I certainly have better things to do.

docrice

I'm assuming we're talking about hard tokens, not soft tokens. But yes, the tokens themselves come with an expiration date (usually a few years). After that, they're decorative accessories for your key fob.

Paul Boz

150 hard tokens and 500 soft tokens... I've got the RSA audit log showing that hosts are being authenticated via token access to the RSA radius but the VPN session fails. When I try to test a user's creds within the ASDM I get AAA authentication errors even though RSA says its authenticating fine. I suspect there's something to do with the node secret but I can not find anywhere that mentions how to install a damn node secret on an ASA.. it mentions where in flash it is so that you can delete it if you need to, but if its not there to begin with I don't know what to do. anyone?

docrice

Let me try and comb past the spiderwebs in my brain for a moment...

If memory serves, the node secret is a file generated on the RSA server side, which is then copied over to the VPN gateway's file system. For some reason I also recall this being auto-copied over from the RSA to the VPN device's file system on the first auth attempt. The file ends up being called something like C0A8005A.SDI. In the older 3000 series gateway, the tunnel group profile would have a mapped authentication server setting with the type of "SDI" (not RADIUS). I think this caused this relationship to sprout spontaneously and this SDI file to magically appear on the gateway.

I'm not sure if you have filtering devices between the RSA and the ASA, but this runs over UDP 5500.

Not sure if you've seen this already, but here's a guide to help define the AAA group:

http://www.rsa.com/rsasecured/guides/imp_pdfs/Cisco_ASA_AuthMan7.1.pdf

shednik

Hi Paul,

I have this setup at my company for about 10,000+ remote access users.

As you mentioned it can be setup to either authenticate directly off of the RSA server or use ACS in the middle. For our setup we have the ASA or VPN 3000 in one case talking directly to our RSA environment. Overall I can't think of any major pitfalls with this implementation, other than making sure your node secrets are matched up. The annoyances like others have said are the users locking themselves out due to pin issues and the like. I haven't dealt much with the issuing side of it since that is done by another group but it doesn't seem to be that much of an issue. I could go into more detail if you have any questions but figured this would be enough of an overview.

Paul Boz wrote: »

150 hard tokens and 500 soft tokens... I've got the RSA audit log showing that hosts are being authenticated via token access to the RSA radius but the VPN session fails. When I try to test a user's creds within the ASDM I get AAA authentication errors even though RSA says its authenticating fine. I suspect there's something to do with the node secret but I can not find anywhere that mentions how to install a damn node secret on an ASA.. it mentions where in flash it is so that you can delete it if you need to, but if its not there to begin with I don't know what to do. anyone?

if you look in the flash it should be a file name like this - xxx-xxx-xxx-xxx.sdi where the x's are the IP address of the AAA server you configured for SDI.

joe

shednik

I would add though that using ACS in the middle is something I wouldn't like to do just for the fact you are going to be managing user accounts in both systems. The only benefit of using ACS would be if you were making use of the role based features for VPN access but that can all be managed on the ASA.

the-UK-BOFH

First pitfall is using the ASDM GUI - it has bugs in it

Config issues - basically the gui parses in the config on the router - if you have some values in the config that are allowed, but the GUI Java does not understand then it will reset them to what the java program thinks they should be - in particular around the handling of certifictes.

If possible use CLI to update configs - if not possible always turn on the option to view config lines before they are sent by the GUI.

Specifically to the use of cerificates first first stage auth and SecurID for second stage - I have an implementation of 24K devices using this now.

Certificate management should be part of your AD or device management process - do NOT take this on board - get a cert from the AD guys to make the ASA part of the same root CA as the PC devices - simple deployment then.

I use SDI to communicate directly with the RSA service, this is simple to configure - but I have found the test function (in the GUI) is sometimes problematic. i.e. it responds with a success even though I have entered invalid details and the Firewall is blocking traffic anyway !

The biggy is the ip.ad.dr.ess.sdi file that is downloaded into flash - if you re-connect to the RSA service (after rebuild of rsa or in some cases reconfig on the ASA) it is godd practice to delete this file and force the download of a new one - else the one time you don't it errors (and does not log !)

bit late, but hope this helps.

Roberto_

Hi,

I'm also trying to configure RSA as second factor authenticator. We have a Cisco ASA followed by a Cisco ACS before the authentication request is done to the RSA. But we can't find how ACS can be configured with two authentication methods simultaneously, we tried to use Identity Store Sequences to authenticate against AD and RSA... but when one of the methods suceded, the process ended as success. We are looking to use Active Directory AND RSA Authentication methods at the same time.

Anyone has any idea why this can be happening?

BR,