RADIUS and VRF

In my earlier post "Setting up RADIUS authentication for Cisco devices", there is a set of example Cisco IOS commands to define the RADIUS server for Cisco authentication. However, it can't work if you apply VRF, even if you use the "ip radius source-interface" command.

If you have Cisco devices using Multi-VRF and/or MPLS related commands, you have to define "aaa group server" instead. Other advantages include server load-balancing and grouping them for different purposes, such dot1x and login etc. Below are the example commands.

(config)# aaa authentication login NetworkLogin group NetworkRadius local
! group up the servers
(config)# aaa group server radius NetworkRadius
(config-sg-radius)# server 1.1.1.1 auth-port 1812 acct-port 1813

! define VRF and source interface
(config-sg-radius)# ip vrf forwarding YOUR_VRF
(config-sg-radius)# ip radius source-interface Loopback 0
! define the radius server
(config)# radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 timeout 5 key ****
! apply the RADIUS authentication list
(config)# line vty 0 4
(config-line)# login authentication NetworkLogin

To verify the configuration, do "show radius server-group all" on the exec mode.

RADIUS Shared Key Template

In one of the comments in my earlier post "Setting up RADIUS authentication for Cisco devices", someone asked whether he should have all network devices having different radius keys. Don't get it wrong, this is the shared key between the RADIUS server and the client (e.g. Cisco or other network security devices), which is a RADIUS requirement. We are not referring to the individual user credential used to gain administrative access into the Cisco devices or the network resources. Note that the same RADIUS protocol is also commonly used for other applications, such IEEE 802.1x, WPA2, remote dial-in etc. These applications would also face similar issue of having shared secret between the security device and the RADIUS server. See this RADIUS overview on Wiki.

I felt that might poised another more serious security issue. Imagine there can be hundreds of devices under his care, what if he lost or accidentally leaked that long password list?

To strike a good balance between manageability and security, I would advise that those less critical devices can share a common key while applying another common key for more sensitive/critical devices (fewer in number). For highly sensitive/critical devices, a unique key may be applied.

Fortunately, Microsoft RADIUS or the Network Policy Server (NPS) in Windows 2008 R2 provides shared secret template feature to facilitate that. A group of devices belonging to similar security level can share a common shared secret template.

To create a new template, open up NPS server console, expand on "Template Management", right-click on "Shared Secret" and add "New". A small windows would pop up:



Give it a name and add in the shared secret. Click "Ok". On the properties of RADIUS client, select the relevant template on the drop-down box.