aaa/RADIUS issue on SDWAN cEdge ISR4431

[Minnesotakid]

We're testing one of our ISR4431's on SDWAN and we've hit an issue where we can't get aaa to work properly. 

ISR4431 - SDWAN code version 16.10.4
Controller version - 18.4.302

RADIUS/TACACS+ server we're using is Cisco ISE version 2.3 patch 5

We are using feature templates specific to our ISR's for this work. We do not use CLI templates. 

I believe it might be a vmanage configuration bug but curious if anyone here has hit this issue. Below I've included the configuration that gets pushed. Notice the quotes. Those quotes are included on the ISR side but I do not put quotes in the key field in Vmanage. 

!
aaa group server tacacs+ tacacs-1
server-private 10.51.90.100 timeout 5 key "testRadiusKey"
server-private 10.61.90.100 timeout 5 key "testRadiusKey"
ip vrf forwarding 1
!
aaa group server radius radius-1
server-private 10.51.90.100 auth-port 1812 timeout 5 retransmit 3 key "testRadiusKey"
server-private 10.61.90.100 auth-port 1812 timeout 5 retransmit 3 key "testRadiusKey"
ip radius source-interface Loopback0
ip vrf forwarding 1

[Minnesotakid]

If anyone is familiar with it, I'm thinking we might be hitting this bug:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn38487

Symptom:
vManage does not generate proper configuration for Cisco XE SD-WAN Router, TACACS authentication is not working

Conditions:
vManage AAA feature template is used to configure TACACS authentication

Workaround:
none

Further Problem Description:
- Currently vManage produce the following config:

aaa group server tacacs+ server-10.2.3.4
server-private 10.2.3.4 timeout 5 key $8$bc9w03rV0NRYX/jsZJ0/73KDZVOqEO2stQrLvHtVI4Q=
ip vrf forwarding 1
!
aaa group server tacacs+ server-10.3.4.5
server-private 10.3.4.5 timeout 5 key $8$/ILyhN49+Ll1W6dg862j4I2+ix5R8ORzjjPxWKu2rwM=
ip vrf forwarding 1
!
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa session-id common

- Here is how it should look like:

aaa group server tacacs+ tacacs-servers
server-private 10.2.3.4 key test
server-private 10.2.3.4 timeout 10
server-private 10.2.3.4 port 49
server-private 10.3.4.5 key test
server-private 10.3.4.5 timeout 10
server-private 10.3.4.5 port 49
ip vrf forwarding 1
ip tacacs source-interface Loopback172
!
aaa authentication login default group tacacs-servers local
aaa authorization exec default group tacacs-servers local
aaa session-id common

If multiple servers defined and all of them are in the same VRF/VPN and reachable via same source interface, then we should combine them in the same server group.

For Radius server, radius server group should look like below:

aaa group server radius radius-servers
server-private 10.2.3.4 key test
server-private 10.2.3.4 auth-port 1812
server-private 10.2.3.4 acct-port 1813
server-private 10.2.3.4 retransmit 10
server-private 10.2.3.4 timeout 12
ip vrf forwarding 1
ip radius source-interface Loopback172

[gilbert.aispuro1]

I can confirm this issue as well. I have 4431's and 4451's

[hawaii]

Tacacs aaa is working since upgrade to 19.2.1 for us. Not sure about 18 software line...They add new feature template called aaa-cisco. 

[Minnesotakid]

Thank you for your notes guys! I have a TAC case open for this issue and will pass on the word that others are seeing this. 

@hawaii were you also seeing this issue on a 4431 on 18.4? 

[Minnesotakid · Accepted solution]

Wanted to update everyone here. 

We got around this issue by doing 2 things:

1. We updated our ISE side configuration for this device to include quotes in our key. (I'd call this a "workaround" for now)

2. Per TAC's recommendation, we verified an authorization policy was needed to allow our accounts to login with privilege level 15 rights. It was previously getting us in with priv level 1. We confirmed this by doing a show privileges after logging in. 

After doing those 2 things, we were able to successfully get into our cEdge.