cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9777
Views
0
Helpful
15
Replies

Cisco Switch Authentication with Microsoft NPS Case Sensitive Issue.

Samuel Caunt
Level 1
Level 1

Hi All, 

 

I'm a little confused and i need someone to check over my configuration as i am experiencing a few issues when authenticating to switches using Microsoft NPS. To set the scene I have a number of switches as follows:

 

1. WS-C3850-24XS 16.6.5

2.  C9300-48T 16.12.4 

 

I have configured both with the following NPS configurations (some details have been removed IP Address and replaced with test ones)

 

aaa new-model

 

radius server NPS-01
address ipv4 10.10.10.11 auth-port 1812 acct-port 1813
key REMOVED

 

radius server NPS-02
address ipv4 10.10.10.10 auth-port 1812 acct-port 1813
key REMOVED

 

aaa group server radius NPSGroup
server name NPS-01
server name NPS-02

 

aaa authentication login userAuthentication local group NPSGroup
aaa authorization exec userAuthorization local group NPSGroup if-authenticated
aaa authorization network userAuthorization local group NPSGroup
aaa accounting exec default start-stop group NPSGroup
aaa accounting system default start-stop group NPSGroup
radius-server deadtime 1


line vty 1 4
authorization exec userAuthorization
login authentication userAuthentication

 

line vty 5 15
authorization exec userAuthorization
login authentication userAuthentication

 

I have setup all the relevant NPS policies accordingly and CAN authenticate to them...........however 

 

when i try to authenticate to these switches i require to use either lowercase credentials for login for 1. WS-C3850-24XS or UPPERCASE credentials for login for 2. C9300-48T 16.12.4 

 

1. WS-C3850-24XS 16.6.5 (lowercase only credentials)

2.  C9300-48T 16.12.4  (uppercase only credentials)

 

Although my AD Account is lowercase If i don't use the right UPPERCASE or lowercase credentials this doesn't appear to authenticate me to the switch although it does if i use vice verse. 

 

What config is missing/causing this and how do i fix it? 

 

Do i need to provide any other details?.

 

Thanks

Sam

 

1 Accepted Solution

Accepted Solutions

Samuel Caunt
Level 1
Level 1

Ok so i found the issue and its my own fault for not checking the basics first, 

 

On switches that were working intermittently i.e worked on uppercase but not lowercase the following config

 

line vty 0
transport input ssh
transport output ssh
line vty 1 4
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none
line vty 5 15
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none

My theory I think and the reason why it wasn't working initially is because i was connecting on line vty 0 (the first connection to the switch) i was trying to authenticate without the  authorization and login configuration applied to this connection. 

 

Then when i tried to connect again but this time using uppercase it worked which was at this stage connecting on line vty 1 4  where the correct configuration is applied. 

 

This basically gave me the weirdness i experienced when connecting.  

 

The fix was to apply the correct configuration to line vty 0 so that the initial connection has the right configuration applied to use the correct auth and login settings

 

line vty 0
 exec-timeout 120 0
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output ssh
line vty 1 4
 exec-timeout 120 0
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output none
line vty 5 15
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output none

This is a lesson learned for me to check the configuration is consistent between my switches and to pay more attention to the VTY lines when configuring!.

 

Thanks for everyone's input!

View solution in original post

15 Replies 15

balaji.bandi
Hall of Fame
Hall of Fame

I have not seen this issue when i was testing Long back, enable to debug and check both the sides. Windows side event logs and ans device side enable debug ?

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

I´ve been dealing with Cisco switches but using ACS or ISE and I never saw this behavior. Which leads me to believe that this may be  something on the NPS side. 

 

   If you look at cisco docs for passwork requirements, it says:

"For password , specify a string from 1 to 25 alphanumeric characters. The string cannot start with a number, is case sensitive, and allows spaces but ignores leading spaces. It can contain the question mark (?) character if you precede the question mark with the key combination Crtl-v when you create the password;"

 

 

 

Samuel Caunt
Level 1
Level 1

Hi Balaji, 

 

The weird thing is that when i enable TERM MON or look at show logging i only ever see the accepted connections i see nothing when the authentication issue occurs during failure. When looking at the NPS Event Viewer side again i only see Successful attempts. 

 

An example of the debug which (i thought)  in theory should show me the successful and failure only shows me the successful attempt. 

 

334997: May 9 15:38:55.138: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: SC^] [Source: 10.10.10.178] [localport: 22] at 16:38:55 BST Mon May 9 2022

 

What specifically can i do to troubleshoot (I'm not an expert on this).

 

Thanks

Sam

marce1000
VIP
VIP

 

                                         >...Do i need to provide any other details?.

 - Check the NPS(/radius) logs too for these and or the failing authentications, check if you 1) can find more info 2) that the username 'comes in' as expected or not.

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Hi Marce, 

 

There is no failed authentication attempts recorded in NPS or Event Viewer. I see no "Failed" attempts or denied access events (6273). 

 

When a successful NPS radius connection occurs the username comes in as expected (i.e sent as UPPERCASE received as UPPERCASE and i see event (6272) "Network Policy granted access to this user" . 

 

What i do not understand is why when i use lowercase credentials i see nothing on the switch or in NPS logs/Event viewer no failed attempts etc.

 

Just putting it out their but could this be packet loss?

 

Regards

Sam

 

 - Not much more inputs for me , only advising to use current advisory software versions on both platforms :

        https://software.cisco.com/download/home/284455428/type/282046477/release/3.3.3SE

        https://software.cisco.com/download/home/286313950/type/282046477/release/Amsterdam-17.3.5

 M.

        



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Samuel Caunt
Level 1
Level 1

Ok so i did some wiresharks tests and i could see the radius packet going out. I doublechecked all the configs on the switches and i have noticed that the two switches i have problems with have slightly different configuration to every other switch that i do not have a problem with. 

 

Working switches (without issue)

 

line vty 0 4
 authorization exec userAuthorization
 login authentication userAuthentication

exit

line vty 5 15
 authorization exec userAuthorization
 login authentication userAuthentication

 

Switches with issues

 

line vty 0
transport input ssh
transport output ssh
line vty 1 4
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none
line vty 5 15
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none

I havent had chance to tweat but could it be something to do with the VTY lines 0 ?

 

                 - Can't see direct need for : 

line vty 0
transport input ssh
transport output ssh

    - Normal syntax directives and configurations usually use you working example(s) for vty-lines. Perhaps this can confuse the device ?

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Hello,

 

on a side note, aaa authentication has the 'local-case' option, although I think it is only for local authentication. You might want to test the below:

 

aaa authentication login userAuthentication local-case group NPSGroup

Morning George, Yes no problems with local authentication to add. Only with Radius authentication. 

 

Local-Case is also my understanding that this enforces the use of case sensitive usernames for local accounts which i do not want. 

 

I'm going to tweak the VTY config today and see if this makes a difference. 

 

Thanks for the reply. 

Sam

Hello,

 

are your clients Windows 10/11 or Mac ? Or Linux ?

Samuel Caunt
Level 1
Level 1

Ok so i found the issue and its my own fault for not checking the basics first, 

 

On switches that were working intermittently i.e worked on uppercase but not lowercase the following config

 

line vty 0
transport input ssh
transport output ssh
line vty 1 4
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none
line vty 5 15
authorization exec userAuthorization
login authentication userAuthentication
transport input ssh
transport output none

My theory I think and the reason why it wasn't working initially is because i was connecting on line vty 0 (the first connection to the switch) i was trying to authenticate without the  authorization and login configuration applied to this connection. 

 

Then when i tried to connect again but this time using uppercase it worked which was at this stage connecting on line vty 1 4  where the correct configuration is applied. 

 

This basically gave me the weirdness i experienced when connecting.  

 

The fix was to apply the correct configuration to line vty 0 so that the initial connection has the right configuration applied to use the correct auth and login settings

 

line vty 0
 exec-timeout 120 0
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output ssh
line vty 1 4
 exec-timeout 120 0
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output none
line vty 5 15
 authorization exec userAuthorization
 login authentication userAuthentication
 transport input ssh
 transport output none

This is a lesson learned for me to check the configuration is consistent between my switches and to pay more attention to the VTY lines when configuring!.

 

Thanks for everyone's input!

 

 - But the question still remains why use a separate directive for vty 0 ? Since it's all the same line vty 0 4 , would be the way to go or not.... ?

 M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Hi Marce, 

 

Historical config and not sure on the answer however yes i definitely agree on your point!, something for me to tidy up on another day. 

 

Thanks

Sam

Review Cisco Networking for a $25 gift card