Directed AAA authentication

[mcoupe]

Seems like this should work but I'm clearing missing something.  I'm trying to send AAA requests for ssh access from administrative accounts to the M$ radius servers in the group RADAUTH_MFA because they are using the NPS plugin for Azure MFA and AAA request from a service account to the the M$ radius servers in the RADAUTH group because they are not.  The service account is logging in to perform scripted backups of the startup and running configs and obviously can't respond to an mfa prompt.

There is no problem operationally other than the fact that the service account requests are hitting the wrong group of AAA servers.  What I mean by that is NPS/Azure MFA works for the administrative accounts when using the M$ Authenticator app and the push notification.

It seems to me that if the connection request sources from 10.xx.xx.35 (the only place for the service account that it would come from) the access list on vty 0 4 would block it and that on vty 5 15 would allow it, it would then be directed to the AAA login MONITOR which points at the non-MFA NPS servers.  However, when I attempt to run the script, the connection is actively denied which seems like it's hitting the first access list, being dropped and not reaching vty 5 15 (I think I just answered my own question).

Given the restriction on auth-proxy of telnet does anyone have another idea of how I can do this?

aaa authentication login default group RADAUTH_MFA local
aaa authentication login MONITOR group RADAUTH
aaa authorization exec default group RADAUTH_MFA local
aaa authorization exec MONITOR group RADAUTH
username <user> privilege 15 secret 9 $----A
!
!radius-server attribute 32 include-in-access-req format cisco
!
aaa group server radius RADAUTH
server-private 10.xx.xx.21 key 7 1---D
server-private 10.xx.xx.64 key 7 1---D
!
aaa group server radius RADAUTH_MFA
server-private 10.xx.xx.32 key 7 1---7
server-private 10.xx.xx.33 key 7 1---7

======================================

Standard IP access list MANAGEMENT
30 permit 10.xx.xx.0, wildcard bits 0.0.0.63 log (532 matches)

!

Standard IP access list MONITOR
10 permit 10.xx.xx.35 log

======================================

line vty 0 4
access-class MANAGEMENT in
exec-timeout 60 0
logging synchronous
transport input ssh

!
line vty 5 15
access-class MONITOR in
exec-timeout 15 0
login authentication MONITOR

transport input ssh

[mcoupe]

What I'm looking into now is setting up a Connection Request Policy in the M$ NPS servers that are members of RADAUTH_MFA for the specific server account to forward the auth request back to the servers in RADAUTH, acting as a proxy (without adding a whole separate proxy server).

At this point the requests are being forwarded and hitting the first server.  The ssh session from the service account is still failing but I think it's just a matter of getting the conditions right between the two radius servers.

I have a feeling this may end up being the solution.

[mcoupe · Accepted solution]

I was close, rather than send the request to RADAUTH_MFA and proxy just the service account back to RADAUTH, I got it working by sending requests to RADAUTH and proxying the administrative accounts to RADAUTH_MFA.

This was needed because when RADAUTH validated the password for the service account and handed it back to RADAUTH_MFA, the NPS MFA plug-in was kicking in and attempting an mfa secondary authentication on the service account, putting me right back where I started.  So by flipping it on it's head, the service account gets authenticated with it's single factor and the administrative accounts get bounced, first and second factor handled by RADAUTH_MFA and the MFA plug-in and the "allow connection" gets sent back to RADAUTH to be sent along to the swtich.

This means in the end, I didn't need to add the RADAUTH_MFA aaa servers to my switches at all.