Network Devices to use RADIUS Shared Secret or PAC ?

[Arne Bier]

Hello

When Cisco DNAC is integrated with ISE, it will automatically add Network Devices into ISE - very nice indeed. But it doesn't configure the RADIUS client using the shared secret - it uses PAC (Protected Access Credential). I have to confess I don't understand (yet) how PAC works and why this method is any better than using a regular shared secret.

I would like someone to explain this in their own words and not throw a link at me - I have read the Cisco links and it makes no sense to me.

In a Non-SDA deployment, what are the benefits of using PAC rather than the non-PAC method (if any)?

radius server $ISE-PSN1-NAME
 address ipv4 $ISE-PSN1-IP auth-port 1812 acct-port 1813
 timeout 5
 retransmit 3
 automate-tester username radius-test ignore-acct-port idle-time 5
 pac key 0 $RADIUS-PSK-HERE$

versus

radius server $ISE-PSN1-NAME
 address ipv4 $ISE-PSN1-IP auth-port 1812 acct-port 1813
 timeout 5
 retransmit 3
 automate-tester username radius-test ignore-acct-port idle-time 5
 key 0 $RADIUS-PSK-HERE$

[Greg Gibbs · Accepted solution]

DNAC configures the RADIUS server using the 'pac key' method to facilitate TrustSec. In older code, it was necessary to configure separate RADIUS servers and groups; one using 1812/1813 with a non-pac key for standard RADIUS auth, and another using 1645/1646 with a pac key for TrustSec. The different groups would then be configured in the respective 'aaa authorization network' settings; one for default and one for the CTS authorization list.

For example:

aaa authorization network default group ISE_Auth 
aaa authorization network CTS-LIST group ISE_Auth+PAC 
!
cts authorization list CTS-LIST

The way DNAC configures the switch using the 'pac key' allows the single RADIUS server to be used for both purposes. Configuring the RADIUS server using 'pac key' in an environment that does not have SDA/TrustSec would provide no value.

More details on how the PAC works with TrustSec can in the IOS-XE documentation.

[Arne Bier]

thanks Greg. Makes sense now. And DNAC will always use the PAC method, whether or not the customer is doing CTS/SDA. I could not find a switch in DNAC to tell it that I am not doing CTS/SDA. It's probably the default and DNAC is being hopeful that customers will use CTS

I noticed that immediately after ISE 3.1 and DNAC 2.3.3.4 integration, DNAC populates the Network Devices into ISE. And along with that I say hundreds of CoA failures in LiveLogs because ISE tried to push a Re-auth to the switches to force them to fetch some CTS stuff. But since the switches were not enabled for CTS, the CoAs were never answered. 

I am hoping that once the switches are provisioned in DNAC, that the TACACS+ config will be pushed.

And then the RADIUS aaa config will have to be done via templating (since we're not doing SDA) - it would be nice to have DNAC push all the RADIUS config along with port configurations in NON-SDA deployments.