cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

362
Views
0
Helpful
2
Replies
Highlighted
Beginner

Radius Authentication users being unexpectedly escalated to priv15

I'm working on rolling out M$ NPS for RADIUS auth. On my NPS I've got two network policies, one each for privileged (Cisco AV Pair - shell:priv-lvl=15) and unprivileged (Cisco AV Pair - shell:priv-lvl=1). Both are Service-Type Administrative.

I was using an old C3750 running 12.2SE5 for testing my configs. I've got that machine running so I can use either local or RADIUS users. Users in the unprivileged group or localdb users must enter the enable password to enter EXEC, where users in the privileged group login direct to EXEC mode.

I took those settings and pushed them over to a non-production C2960X running 15.2E1. Even though they're the same settings (except for the radius server host syntax change) all users login direct to EXEC mode on this box. I was seeing dropping service type, "radius-server attribute 6 on-for-login-auth" is off in the radius auth debugs so I pushed

radius-server attribute 6 on-for-login-auth

with no change. The correct AVpairs seem to be getting pushed by the RADIUS server properly,  however - on both machines - AAA debug shows  that the machine is processing two AV rules for the user, one with priv-lvl=15 and one with priv-lvl=1.  I'm wondering where it's pulling the priv15 AV rule from since it's not receiving it from RADIUS (according to the debugs).  It looks like the difference in behavior is due to the "working" host processing the priv15 before the priv1, with the reverse being true on the "non-working" host.  That's all superseded in the mystery that is why they're even processing the priv15 at all.  A sample login with RADIUS, AAA Authentication, AAA Authorization, and AAA Admin debugs below.

Feb 14 15:31:59.764: RADIUS: Received from id 1645/24 <NPS Server>:1645, Access-Accept, len 132
Feb 14 15:31:59.764: RADIUS:  authenticator 78 F1 BF 43 BD 14 32 5B - A0 77 C6 79 0F 71 35 CD
Feb 14 15:31:59.764: RADIUS:  Idle-Timeout        [28]  6   900
Feb 14 15:31:59.764: RADIUS:  Service-Type        [6]   6   Administrative            [6]
Feb 14 15:31:59.764: RADIUS:  Session-Timeout     [27]  6   3600
Feb 14 15:31:59.764: RADIUS:  Class               [25]  46
Feb 14 15:31:59.768: RADIUS:   9D 28 09 A5 00 00 01 37 00 01 02 00 0A 64 0A 40 00 00 00 00 09 AA 58 19 5D 7E DF 75 01 D2 83 E0 DE 28 E2 FA 00 00 00 00 00 00 00 46        [ (7d@X]~u(F]
Feb 14 15:31:59.768: RADIUS:  Vendor, Cisco       [26]  24
Feb 14 15:31:59.768: RADIUS:   Cisco AVpair       [1]   18  "shell:priv-lvl=1"
Feb 14 15:31:59.768: RADIUS:  Vendor, Microsoft   [26]  12
Feb 14 15:31:59.768: RADIUS:   MS-Link-Util-Thresh[14]  6
Feb 14 15:31:59.768: RADIUS:   00 00 00 32                 [ 2]
Feb 14 15:31:59.768: RADIUS:  Vendor, Microsoft   [26]  12
Feb 14 15:31:59.768: RADIUS:   MS-Link-Drop-Time-L[15]  6
Feb 14 15:31:59.768: RADIUS:   00 00 00 78                 [ x]
Feb 14 15:31:59.768: RADIUS(00000172): Received from id 1645/24
Feb 14 15:31:59.778: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: <username with priv1 only>] [Source: <user access client IP>] [localport: 22] at 08:31:59 Ari Tue Feb 14 2017
Dunlap_SW02#
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): processing AV idletime=900
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): processing AV timeout=3600
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): processing AV priv-lvl=1
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): processing AV priv-lvl=15
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): processing AV service-type=6
Feb 14 15:31:59.796: AAA/AUTHOR/EXEC(00000172): Authorization successful

What might I be missing with the C2960X? Relevant config template is below.

aaa authentication login admins local group radius
aaa authorization exec admins group radius if-authenticated
ip radius source-interface <appropriate interface>
line vty 0 15
 login auth admins
 author exec admins
 no priv level
 exit
radius server <servername>
 address ipv4 <RADIUS Server IP> auth-port 1645 acct-port 1646
 key <RADIUS key>
  ------ OR -------
radius host <RADIUS Server IP> auth-port 1645 acct-port 1646
radius key <RADIUS key>
2 REPLIES 2
Highlighted
Enthusiast

Can you post the same debug

Can you post the same debug output, from a switch showing the correct behavior, please?

Also, are you able to collect a packet capture, so we can see what's being put on the wire by the RADIUS server? I realize the output of "debug radius" suggests that only shell:priv-lvl=1 is being sent, but just to cover all bases.

Finally, is the username being used to test RADIUS also exists as a local user on the switch?

Highlighted
Beginner

Below is the debug from the

Below is the debug from the working switch.  All RADIUS users are unique from local users.  The packet capture may take a little bit as I don't have an RSPAN set up.

30w0d: RADIUS: Received from id 1645/21 <NPS Server>:1645, Access-Accept, len 132
30w0d: RADIUS:  authenticator D9 73 B2 DC 76 A0 BF 48 - 4D 79 F9 AC 6C 21 5B 48
30w0d: RADIUS:  Idle-Timeout        [28]  6   900
30w0d: RADIUS:  Service-Type        [6]   6   Administrative            [6]
30w0d: RADIUS:  Session-Timeout     [27]  6   3600
30w0d: RADIUS:  Class               [25]  46
30w0d: RADIUS:   9D 2A 09 A7 00 00 01 37 00 01 02 00 0A 64 0A 40  [?*?????7?????d?@]
30w0d: RADIUS:   00 00 00 00 09 AA 58 19 5D 7E DF 75 01 D2 83 E0  [??????X?]~?u????]
30w0d: RADIUS:   DE 28 E2 FA 00 00 00 00 00 00 00 48              [?(?????????H]
30w0d: RADIUS:  Vendor, Cisco       [26]  24
30w0d: RADIUS:   Cisco AVpair       [1]   18  "shell:priv-lvl=1"
30w0d: RADIUS:  Vendor, Microsoft   [26]  12
30w0d: RADIUS:   MS-Link-Util-Thresh[14]  6
30w0d: RADIUS:   00 00 00 32                                      [???2]
30w0d: RADIUS:  Vendor, Microsoft   [26]  12
30w0d: RADIUS:   MS-Link-Drop-Time-L[15]  6
30w0d: RADIUS:   00 00 00 78                                      [???x]
30w0d: RADIUS: saved authorization data for user 346B6A0 at 34F5B40
30w0d: AAA/AUTHEN (2808552002): status = PASS
Feb 14 17:07:42.591: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ] [Source: <user access client IP>] [localport: 23] at 10:07:42 MST Tue Feb 14 2017
30w0d: tty2 AAA/AUTHOR/EXEC (3362944516): Port='tty2' list='admins' service=EXEC
30w0d: AAA/AUTHOR/EXEC: tty2 (3362944516) user='<username with priv1 only>'
30w0d: tty2 AAA/AUTHOR/EXEC (3362944516): send AV service=shell
30w0d: tty2 AAA/AUTHOR/EXEC (3362944516): send AV cmd*
30w0d: tty2 AAA/AUTHOR/EXEC (3362944516): found list "admins"
30w0d: tty2 AAA/AUTHOR/EXEC (3362944516): Method=radius (radius)
30w0d: RADIUS: cisco AVPair "shell:priv-lvl=1"
30w0d: RADIUS: unrecognized Vendor code 311
30w0d: RADIUS: unrecognized Vendor code 311
30w0d: AAA/AUTHOR (3362944516): Post authorization status = PASS_ADD
30w0d: AAA/AUTHOR/EXEC: Processing AV service=shell
30w0d: AAA/AUTHOR/EXEC: Processing AV cmd*
McDowell_iSCSI#
30w0d: AAA/AUTHOR/EXEC: Processing AV idletime=900
30w0d: AAA/AUTHOR/EXEC: Processing AV priv-lvl=15
30w0d: AAA/AUTHOR/EXEC: Processing AV timeout=3600
30w0d: AAA/AUTHOR/EXEC: Processing AV priv-lvl=1
30w0d: AAA/AUTHOR/EXEC: Authorization successful

EDIT:  I went ahead and set up another test machine to check the RADIUS packets. Priv1 is the only Cisco-AVpair being sent.  Screenshot attached.