Recently I have been playing around with RSA SecurID which is commonly used to authenticate VPN users using 2 part authentication, which is great. Although I am way more concerned about using 2 part authentication on admins logging into network devices, luckily its really easy to setup.

The RSA authentication is managed by an RSA application called the RSA Authentication Manager which is currently on version 7.1, this handles replication between servers in a primary to replica’s fashion. Each Authentication Manager can have the RSA “Steel Belted RADIUS” server installed which allows RADIUS clients to authenticate against it. If you are using 2 part authentication you really need to have build in redundancy as if the devices are at a remote site from the RADIUS server they will not be able to perform 2 part authentication in the case of a network or server failure, but we all know that single points of failure are a bad idea?

Authentication Manager Configuration

I wont go to much into how to install and manage the RSA Authentication Manager as there is loads of documentation from RSA on that matter, but there is not much on getting it to authenticate console or vty line users, but luckily its really simple. For each Cisco device that you wish to authenticate users on add it as a RADIUS client in the Authentication Manager, with the model set to “IOS11.1 or later” and then add an associated RSA agent. After this you will need to remember to force replicate the information to the replica RADIUS servers as it does not do this automatically (authentication on the replicas will fail if you don’t do this!)

IOS Configuration

As like most AAA things make sure the aaa new-model is on

aaa new-model

Next we should have sure we have a local user name and password on the system, if the RADIUS servers does not send back a response then we can login using this account. If the response from the RADIUS server comes back as failed from the RADIUS server it will NOT check the local username and password, so this will only be used if the system receive an invalid or no response form the RADIUS server.

username cisco privilege 15 password 0 cisco

Now to enable the RADIUS servers group to be used for the authenticating users on login.

aaa authentication login default group radius line enable local

Now to configure the RADIUS servers, add a separate line for each additional server. It defaults to the standard ports 1645 for authorisation and 1646 for accounting. If there are multiple RADIUS servers it will do a full set of timeouts and retransmits to each one before moving onto the next server.

radius-server host 10.0.0.10 auth-port 1645 acct-port 1646 key password

As I mentioned if anything goes wrong with the RADIUS servers it will fail back to using the locally set username and password, using the default time outs, as waiting for the default timemouts this feels like an eternity so we should change them.

radius-server retransmit 3
radius-server timeout 10

Now give it a test, it even happily support next tokencode mode (see the image), this is where the Authentication Manager can ask you to enter your next token if it thinks your token is starting to drift time abit or it just wants to make sure you actually have the token.

Troubleshooting
#show radius statistics is a good show command to check the response times and make sure everything is singing along well

DistSwitch#show radius statistics
       Maximum inQ length: 1
     Maximum waitQ length: 1
     Maximum doneQ length: 1
     Total responses seen: 53
   Packets with responses: 53
Packets without responses: 17
   Average response delay: 3336 ms
   Maximum response delay: 35048 ms
Number of Radius timeouts: 73
     Duplicate ID detects: 0

  Elapsed time since counters last cleared: 1w2d6h22m

Troubleshooting is pretty simple with #debug radius

User Access Verification

Username: exampleuser
Password:

1w1d: RADIUS: ustruct sharecount=1
1w1d: RADIUS: Initial Transmit tty0 id 45 10.10.0.10:1645, Access-Request, len 66
1w1d:         Attribute 4 6 0A0A34A0
1w1d:         Attribute 5 6 00000000
1w1d:         Attribute 61 6 00000000
1w1d:         Attribute 1 10 62722164
1w1d:         Attribute 2 18 DC6BDD95
DistSwitch>
1w1d: RADIUS: Received from id 45 10.10.20.158:1645, Access-Accept, len 80
1w1d:         Attribute 25 60 53425232
1w1d: RADIUS: saved authorization data for user 80E96540 at 80E95D30
DistSwitch>
DistSwitch>ena
DistSwitch#

If that’s not enough information and your getting alot of timeouts try using Wireshark with a port filter on UDP 1645 will allow you to see the RADIUS rejects, accepts, and challenges.

If the server appears to be rejecting some requests using the real time authentication activity monitor on the RSA Authentication Manager will provide much more detailed information of the reason for the reject or accept.