Authenticating Cisco ASA users using RSA SDI protocol

Anyone still using RSA Authentication Manager (AM) after this infamous break-in? Well, if the answer is yes, read on…

If we are using EMC/RSA Authentication Manager to authenticate our users, we can do so two ways. First, we can use our RADIUS server (we are dealing with Cisco, so hopefully this RADIUS is ACS) to proxy our request to SDI server. SDI is the name of the protocol used for RSA two-factor authentication. In this case we set up our ASA as usual, but the whole fun is on the ACS itself. More about this scenario later on.

The another way is setting up an ASA to “talk” to SDI server directly. This is what we will be exploring this time.

Before we do so, let’s try to give the answer to this question “Why would we use one way over another?”. If we already have an ACS server in place and all users get authenticated against it, we are good candidates for using ACS as a proxy to SDI. This way we have all our users on one place and all logs are on one place as well. On the other hand we may have a dedicated log management solution or using RADIUS that cannot integrate with the RSA AM. In this case we may use SDI directly.

One thing is worth noting before we carry on. Before version 7.2 of code, we could use ASA only to authenticate VPN users. We could not authenticate CTP or administrative sessions (SSH/Telnet/ASDM). This can be verified here. Since version 7.2, we can authenticate all kinds of users. Check this out.

As you can see, the SDI cannot be used for authorization and accounting. For this you have to use other means given in these tables.

With this being said, let’s go and configure both ASA and AM.

First we need to create AAA server group of type SDI:

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# aaa-server RSAAM7x1_SDI protocol sdi
ASAOBR1/pri/act(config)#

Now we add the server called RSAAM7x1 to that group.

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# aaa-server RSAAM7x1_SDI host RSAAM7x1
ASAOBR1/pri/act(config)#

We could use the ip address insted of the name of SDI server.

If we had a replica SDI server, we still need to specify only primary instance. Why is this so? Well, first time a user authenticates, ASA will contact the primary instance, fetch the “sdiconf.rec” file which, among other things, specifies replica instance(s) and cashes this info. Now let’s try to authenticate:

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# test aaa auth RSAAM7x1_SDI host RSAAM7x1 user sasa.poravak pass pppppptttttt
INFO: Attempting Authentication test to IP address (timeout: 12 seconds)
INFO: Authentication Successful
ASAOBR1/pri/act(config)#

“pppppp” is our PIN and “tttttt” is a token code. All together is called a pass code. As we can see, the authentication is successful. But before this could yield a success, AM should be set up to allow our ASA to use it. In AM dictionary, ASA should be registered with AM as an authentication agent. In version 7.x, this is how it looks like:

Our previous log in attempt is listed in AM:

The first log entry (bottom-up) says that user cannot be authenticated because ASA is not listed as a authentication agent in AM. After we fixed this issue, the second log entry is listed. It says that user is successfully authenticated. The third log entry is a cute one: this is when AM sent to ASA the “sdconf.rec” file that contains primary and all replica instances information. Because of this, we don’t need to enlist replica instances in SDI AAA group we created earlier. As long as the node secret file is accurate, of course.

Now let’s see some statistics on ASA:

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# show aaa-server RSAAM7x1_SDI
Server Group: RSAAM7x1_SDI
Server Protocol: sdi
Server Address: RSAAM7x1
Server port: 5500
Server status: ACTIVE, Last transaction at 12:49:14 CEST Wed Jan 11 2012
Number of pending requests 0
Average round trip time 523ms
Number of authentication requests 3
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 1
Number of rejects 1
Number of challenges 0
Number of malformed responses 0
Number of bad authenticators 0
Number of timeouts 1
Number of unrecognized responses 0

SDI Server List:
Active Address: RSAAM7x1
Server Address: RSAAM7x1
Server port: 5500
Priority: 7
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 1
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0

Active Address: RSAAM7x2
Server Address: RSAAM7x2
Server port: 5500
Priority: 0
Proximity: 0
Status: OK
Number of accepts 0
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0

ASAOBR1/pri/act(config)#

We can see that, although we set up only primary instance, there is a replica instance as well. We can also see that primary instance successfully authenticated one user, and failed another one. The replica instance hase not done anything yet, but it is about to change, because we are going to “pull the plug” from it.

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# ping RSAAM7x1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to RSAAM7x1, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ASAOBR1/pri/act(config)#

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# ping RSAAM7x2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to RSAAM7x2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/10 ms
ASAOBR1/pri/act(config)#

As we can see, the primary instance is dead and replica instance should kick-in:

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# test aaa auth RSAAM7x1_SDI host RSAAM7x1 user sasa.popravak pass pppppptttttt
INFO: Attempting Authentication test to IP address (timeout: 12 seconds)
INFO: Authentication Successful
ASAOBR1/pri/act(config)#

We are still able to authenticate users. Let’s dig deeper:

ASAOBR1/pri/act(config)#
ASAOBR1/pri/act(config)# show aaa-server RSAAM7x1_SDI
Server Group: RSAAM7x1_SDI
Server Protocol: sdi
Server Address: RSAAM7x1
Server port: 5500
Server status: ACTIVE, Last transaction at 12:56:46 CEST Wed Jan 11 2012
Number of pending requests 0
Average round trip time 581ms
Number of authentication requests 4
Number of authorization requests 0
Number of accounting requests 0
Number of retransmissions 0
Number of accepts 2
Number of rejects 1
Number of challenges 0
Number of malformed responses 0
Number of bad authenticators 0
Number of timeouts 1
Number of unrecognized responses 0

SDI Server List:
Active Address: RSAAM7x1
Server Address: RSAAM7x1
Server port: 5500
Priority: 7
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 1
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0

Active Address: RSAAM7x2
Server Address: RSAAM7x2
Server port: 5500
Priority: 8
Proximity: 2
Status: OK
Number of accepts 1
Number of rejects 0
Number of bad next token codes 0
Number of bad new pins sent 0
Number of retries 0
Number of timeouts 0

ASAOBR1/pri/act(config)#

Now we can see that the replica instance is doing something and has successfully authenticated previous user.

So, this is how it’s done directly. Some another time we shall see how this is done the proxy way.

Advertisements
This entry was posted in AAA, ASA, Cisco, RSA and tagged , , , , , , , , . Bookmark the permalink.

2 Responses to Authenticating Cisco ASA users using RSA SDI protocol

  1. Integrator says:

    Hello!!

    We need some help trying to get two-factor authentication. Can we get more info about the other way ( ASA “talking” with ACS and ACS “talking” with RSA )?

    The two-factor authentication means: Username + Password ( AD ) + Token ( RSA )

    Thanks in advance

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s