Using RSA SecurID external database with Cisco ACS 5.x

In this blog we saw how to connect our ACS 5.x with Microsoft Active Directory (AD) external database. This way we can use existing usernames and passwords to authenticate our users.

We also saw that in addition to AD external database, Cisco ACS 5.x supports RSA/EMC SecurID, RADIUS and LDAP external data stores. In this article we will cover the RSA SecurID.

We know what this is, but let’s recall. We have Authentication Manager (AM) server software installed and hardware/software tokens imported, set up and assigned to our users. When user needs to authenticate, he/she needs to provide username and a token code or a pass code. The token code is displayed on a token and is changed every sixty seconds. Pass code is a little bit more secure and comprises of token code plus PIN number that is assigned to a token. This is how we achieve OTP – One Time Password. The password is changed every sixty seconds and can be used only once. This should be secure… In this article we will cover version 7.x of RSA AM.

First step in setting the bond between Cisco ACS and RSA SecurID is performed by RSA administrator. He/she needs to create something called “Authentication Agent”. This is basically a DNS name and IP address of a device/software/service that has rights to access RSA database. For our needs, RSA admin has to create two agents for our two ACS instances. Within “RSA Security Console”, under the “Access->Authentication Agents->Add New”…

 

… RSA admin creates two agents. In the “Add New Authentication Agent” window, admin needs to fill just a few fields in:

Both DNS forward and reverse lookups for ACS agents should work. The agent type is “Standard Agent”:

This is what we want to see after adding agents:

There is one more step RSA admin needs to perform: generate and export “sdconf.rec” configuration file. This file basically describes RSA topology and communication:

The default values can be used:

Now admin downloads this configuration file:

This .ZIP file contains actual configuration or “sdconf.rec” file. This file is needed by ACS admin to complete his/hers tasks.

Now ACS admin extracts configuration file and logs to the ACS primary instance. Under the “Users and Identity Stores->External Identity Stores->RSA SecurID Token Servers” admin clicks “Create”:

The name and description should be given and a “Browse” clicked:

After a file is selected, admin clicks “Submit”.

Now first time the ACS contacts token server, another file called a “node secret” will be created for agent (ACS) on RSA AM and downloaded to the ACS. This file is used for encrypted communication.

This completes token server setup. Now we need to configure ACS to utilize this external database.

Under “Access Policies” a new access service is created:

After new access service is created, “Identity” and “Authorization” options need to be setup:

Identity source should be RSA external identity store created previously:

Under authorization at least one rule, one condition and one result should be created. In this example “Rule-1” states that if device type somebody is login in, is a switch, then result is earlier created shell profile called “PRIVILEGE_15”. This basically places any successfully authenticated user in a privilege level 15 on a switch. Of course, a rule could just allow access, without assigning a privilege level:

Now “OK” and “Save Changes” should be clicked.

Finally, a “Service Selection Rule” should be created that will use just created access service. There are already some rules, but a new one will be added:

A rule “Rule-4” is created which calls a “RSA Device Admin” access service. This service created earlier will authenticate users against a RSA token server and place them in the privilege level of 15:

Finally, this “Rule-4” may need to be moved on the top of list, because rules are evaluated from top to bottom until first match:

Hit count is now a zero, which means no authentication/authorization is tried using this rule. It’s time to test this setting. But before we do so, let’s verify that a switch is registered as a network client in the ACS and setup for AAA correctly:

So, switch is registered within ACS. Let’s verify a switch itself:

!
aaa new-model
!
!
aaa group server tacacs+ ACS_TAC
server 10.X.10.151
server 10.Y.14.151
!
aaa authentication login ACS_TAC group tacacs+ local
aaa authorization exec ACS_TAC group tacacs+ local
!
tacacs-server host 10.X.10.151 key somekey
tacacs-server host 10.Y.14.151 key somekey
!
line vty 0 4
exec-timeout 60 0
 authorization exec ACS_TAC
logging synchronous
 login authentication ACS_TAC
transport input ssh
line vty 5 15
exec-timeout 60 0
 authorization exec ACS_TAC
logging synchronous
 login authentication ACS_TAC
transport input ssh
!

If a login is attempted it would be successful. This can be verified on several places. First, in ACS, let’s verify a hit count for created rule:

So, it’s good. From the ACS logs:

Which reflects exactly what has been configured.

Finally, from the RSA token server:

So, there it is. User authentication with ACS 5.x against a RSA SecurID external database.

Thanks for reading!