Perhaps this is not a good way to go about it/it is not supported, but I am trying to configure RADIUS such that only specific users can enable past privilege level 1 and all others are blocked, even if they know the enable password (in practice they won't, but still). This is for my homelab, so not an actual production environment, I am just trying to learn about different things such as AAA. I'm testing this on a Catalyst 2960-X, IOS 15.2(7)E9.
I am using the built-in Windows NPS on Windows Server 2022 for AAA. I have two AD groups, one for network administrators, and one for network auditors/read-only users. I have configured two policies:
aaa authentication login default group radius local
aaa authentication enable default group radius
radius server MDC_RADIUS
address ipv4 10.0.0.3 auth-port 1812 acct-port 1813
key 7 XXX
aaa new-model
aaa session-id common
I also had to create an '$enab15$' user on the server, since the AAA enable operation pushes '$enab15$' as the username. For authentication to work at all, I had to assign this user group membership in either the admin or the auditor group.
The issue is that users in the network auditors group are permitted to enable to full privilege 15 if they know the password. The expected behavior would be for the switch to throw the '% Error in authentication.' message and refuse the command. Instead the user is authenticated without issue:
Feb 12 08:57:44.294: AAA/AUTHEN/START (621195504): port='tty2' list='' action=LOGIN service=ENABLE
Feb 12 08:57:44.294: AAA/AUTHEN/START (621195504): using "default" list
Feb 12 08:57:44.294: AAA/AUTHEN/START (621195504): Method=radius (radius)
Feb 12 08:57:44.294: AAA/AUTHEN (621195504): status = GETPASS
Feb 12 08:57:46.629: AAA/AUTHEN/CONT (621195504): continue_login (user='read-only-user')
Feb 12 08:57:46.629: AAA/AUTHEN (621195504): status = GETPASS
Feb 12 08:57:46.629: AAA/AUTHEN (621195504): Method=radius (radius)
Feb 12 08:57:46.629: RADIUS: Authenticating using $enab15$
Feb 12 08:57:46.629: RADIUS: Pick NAS IP for u=0xF6763C4 tableid=0 cfg_addr=0.0.0.0
Feb 12 08:57:46.629: RADIUS(00000000): Config NAS IPv6: ::
Feb 12 08:57:46.632: RADIUS: ustruct sharecount=1
Feb 12 08:57:46.632: Radius: radius_port_info() success=1 radius_nas_port=1
Feb 12 08:57:46.632: RADIUS: added cisco VSA 2 len 4 "tty2" "tty2"
Feb 12 08:57:46.632: RADIUS/ENCODE: Best Local IP-Address 172.16.0.2 for Radius-Server 10.0.0.3
Feb 12 08:57:46.632: RADIUS(00000000): Send Access-Request to 10.0.0.3:1812 onvrf(0) id 1645/100, len 97
Feb 12 08:57:46.632: RADIUS: authenticator F8 0E 8B 8B 9C 20 8A 70 - 80 BD E2 99 EA 02 C2 F5
Feb 12 08:57:46.632: RADIUS: NAS-IP-Address [4] 6 172.16.0.2
Feb 12 08:57:46.632: RADIUS: NAS-Port [5] 6 2
Feb 12 08:57:46.632: RADIUS: Vendor, Cisco [26] 12
Feb 12 08:57:46.632: RADIUS: cisco-nas-port [2] 6 "tty2"
Feb 12 08:57:46.632: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
Feb 12 08:57:46.632: RADIUS: User-Name [1] 10 "$enab15$"
Feb 12 08:57:46.632: RADIUS: Calling-Station-Id [31] 13 "172.16.0.21"
Feb 12 08:57:46.632: RADIUS: User-Password [2] 18 *
Feb 12 08:57:46.632: RADIUS: Service-Type [6] 6 Administrative [6]
Feb 12 08:57:46.632: RADIUS(00000000): Sending a IPv4 Radius Packet
Feb 12 08:57:46.636: RADIUS(00000000): Started 5 sec timeout
Feb 12 08:57:46.649: RADIUS: Received from id 1645/100 10.0.0.3:1812, Access-Accept, len 97
Feb 12 08:57:46.649: RADIUS: authenticator AE 30 DB 8B B7 B4 9F 87 - 38 FE 71 25 C2 51 3F 96
Feb 12 08:57:46.649: RADIUS: Service-Type [6] 6 Administrative [6]
Feb 12 08:57:46.649: RADIUS: Class [25] 46
Feb 12 08:57:46.653: RADIUS: 7C 7D 07 E0 00 00 01 37 00 01 02 00 0A 00 00 03 00 00 00 00 65 C1 12 17 CB 5D 74 CE 01 DA 59 2D C4 56 2D 72 00 00 00 00 00 00 00 C4 [ |}7e]tY-V-r]
Feb 12 08:57:46.653: RADIUS: Vendor, Cisco [26] 25
Feb 12 08:57:46.653: RADIUS: Cisco AVpair [1] 19 "shell:priv-lvl=15"
Feb 12 08:57:46.653: RADIUS: saved authorization data for user F6763C4 at EEED77C
Feb 12 08:57:46.653: AAA/AUTHEN (621195504): status = PASS
Feb 12 08:57:46.653: AAA/MEMORY: free_user (0xF6763C4) user='read-only-user' ruser='NULL' port='tty2' rem_addr='172.16.0.21' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)
Then over on the NPS server, it is logged as Access-Accept:
02/12/2024 08:27:10.541 Access-Request MINION-DC1-TEST 172.16.0.2 172.16.0.21 MDC\$enab15$ Access-Accept The connection request was successfully authenticated and authorized by Network Policy Server.
Does anyone have any ideas on how to go about fixing this? Or, is this just a bad idea, and I should do something else?
Unfortunately that isn't quite what I'm looking for–non-admin users would still be able to enable, if they knew the enable password. I guess I could disable the $enab15$ user on AD to prevent this, but that seems like a rather janky workaround.
I'm just more confused as to why I'm pushing all of the correct attributes with the audit policy, but the switch ignores that and puts the read only user in full privilege 15.
Perhaps this is not something possible with NPS, and I'd have to look into a RADIUS server instead.
