This document describes how to integrate a Cisco Access Control System (ACS) Version 5.x with RSA SecurID authentication technology.
The Cisco Secure ACS supports the RSA SecurID server as an external database.
RSA SecurID two-factor authentication consists of the user's personal identification number (PIN) and an individually registered RSA SecurID token that generates single-use token codes based on a time code algorithm.
A different token code is generated at fixed intervals, usually every 30 or 60 seconds. The RSA SecurID server validates this dynamic authentication code. Each RSA SecurID token is unique, and it is not possible to predict the value of a future token based on past tokens.
Thus, when a correct token code is supplied together with a PIN, there is a high degree of certainty that the person is a valid user. Therefore, RSA SecurID servers provide a more reliable authentication mechanism than conventional reusable passwords.
You can integrate a Cisco ACS 5.x with RSA SecurID authentication technology in these ways:
Cisco recommends that you have basic knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
This procedure describes how the RSA SecurID server administrator creates authentication agents and a configuration file. An authentication agent is basically a Domain Name Server (DNS) name and an IP address of a device, software, or service that has rights to access the RSA database. The configuration file basically describes RSA topology and communication.
In this example, the RSA administrator must create two agents for the two ACS instances.
This procedure describes how the ACS administrator retrieves and submits the configuration file.
Use this section in order to confirm that your configuration works properly.
In order to verify a successful login, go to the ACS console, and review the Hit Count:
You can also review the Authentication Details from the ACS logs:
In order to verify successful authentication, go to the RSA console, and review the logs:
This section provides information you can use in order to troubleshoot your configuration.
In order to configure an RSA SecurID token server in ACS Version 5.3, the ACS administrator must have the sdconf.rec file. The sdconf.rec file is a configuration record file that specifies how the RSA agent communicates with the RSA SecurID server realm.
In order to create the sdconf.rec file, the RSA administrator should add the ACS host as an agent host on the RSA SecurID server and generate a configuration file for this agent host.
After the agent initially communicates with the RSA SecurID server, the server provides the agent with a node secret file called securid. Subsequent communication between the server and the agent relies on the exchange of the node secret in order to verify the other's authenticity.
At times, the administrators might have to reset the node secret:
The RSA SecurID agent automatically balances the requested loads on the RSA SecurID servers in the realm. However, you have the option to manually balance the load. You can specify the server used by each of the agent hosts. You can assign a priority to each server so that the agent host directs authentication requests to some servers more frequently than others.
You must specify the priority settings in a text file, save it as sdopts.rec, and upload it to the ACS.
When an RSA SecurID server is down, the automatic exclusion mechanism does not always work quickly. Remove the sdstatus.12 file from the ACS in order to speed up this process.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
13-Feb-2014 |
Initial Release |