GUI - https - WLC 9800 local Autentication when ISE Fail

[lacemi]

Hi every one, I have tipical aaa for login, enable and commnads. It´s applied to interfaces VTY and Console and Its work fine
when ISE fail I can login with local user, the config is right:
aaa authentication login LOGIN group Tacacs local
aaa authorization exec LOGINEXEC group Tacacs enable local if-authenticated 
etc ...
All works fine.
I also have http configuration with tipical config:
ip http server
ip http authentication aaa login-authentication LOGIN
ip http authentication aaa exec-authorization LOGINEXEC
ip http secure-server
etc ...
but if ISE fail I can not login fot HTTPS in GUI with my local user.

I can't find a clear document that I can see how to configure, in case the ISE goes down, access it through the local user.
If I configured "ip http authentication local" Logically, the prevoius triple-a http configuration is lost.

Do you know where there is a CISCO document with these configurations?

Thanks a lot

[marce1000]

                                               >...aaa authentication login LOGIN group Tacacs local
  You may try to switch that into : aaa authentication login LOGIN group local Tacacs 

 M.

[lacemi]

Hi Marce, 
First, Very thanks for replay!!!!!!!!!!!
Second, I thinks if I Without doing a test I couldn't tell you for sure but I don't think it will affect the order.

If you are trying to change the authentication order to help me, in this case it would not be the most correct way. The normal validation is to have the ISE (tacacs) working. So I would always try to validate first locally as it will fail because it should go through ISE, then I would send it to ISE, which would waste time in authentication.

On the other hand, if the ISE fails, I do not think this order will affect HTTP, since now if the ISE fails it works correctly if you validate yourself locally through VTY and through the Console, which is also configured although I did not include the line for resume.

[marce1000]

 - In any case and according to my first reply , you should have setups where local authentications , either CLI or GUI remain possible if ISE fails , because of the importance to be able to access the controller for wireless management, therefore you may try my suggestion too , 

 M.

[lacemi]

When ISE fails, only GUI authentication fails for https, but I'm going to try changing the order as you suggest, although I don't understand the reason.
Since it is a production system, I cannot turn the ISE down and I cannot do an AAA debug and see the logs.
Thanks MARCE for your time !!!

[marce1000]

                 >...Since it is a production system, I cannot turn the ISE down 
  - On the long run that is a reason more to make local authentication always work too and or have priority.
     Testing could for instance be done on the cloud version of the 9800 (can be downloaded for free) which you could deploy as a VM and play as much as you want to get the desired settings!

 M.

[Rich R]

aaa group server tacacs+ management
 server name ise1
 server name ise2
 [ip vrf forwarding management] <- we have it in VRF
 ip tacacs source-interface vlXXX
aaa authentication login ise_authentication group management local
aaa authorization exec ise_authorization group management local
ip http authentication aaa login-authentication ise_authentication
ip http authentication aaa exec-authorization ise_authorization

Always try ISE first - if no response fall back to local.

[lacemi]

Thanks Rich !!!
This is my config, the config is good to VTY and CONSOLE, That's why I think that changing the order of writing first local and then group, will not serve any purpose, But I haven't tried it yet.
If it works fine for VTY and CONSOLE, it should also work fine for HTTP GUI.
I understand that the configuration I have is fine.
I will try to do a new test as is and debug triple A in the WLC

[MHM Cisco World]

Correct by Mr @Rich R 

MHM

[Rich R]

@MHM Cisco World if the ISE is down (failed)  - which is why the WLC must fall back to local auth - how could the ISE config possibly cause that problem?

[lacemi]

Thanks Rich !!!
This is my config, the config is good to VTY and CONSOLE, That's why I think that changing the order of writing first local and then group, will not serve any purpose, But I haven't tried it yet.
If it works fine for VTY and CONSOLE, it should also work fine for HTTP GUI.
I understand that the configuration I have is fine.
I will try to do a new test as is and debug triple A in the WLC

[MHM Cisco World]

show aaa server <<- share this 
debug aaa authC <<- share this 

MHM

[Rich R]

note that "debug aaa auth" is ambiguous.  I believe you'll need both:
debug aaa authentication
debug aaa authorization

[lacemi]

I didn't want to leave this thread hanging without an answer, since you've taken the trouble to try to help, but I think I've found the solution, after doing some debugging.

Hi MHM CISCO WORLD:
show aaa server <<- share this --> only show radius server, my problems is tacacs and local. 
debug aaa authC <<- share this  --> yes interesting and it is important debug aaa authoR, Sometimes the authentication works and the authorization fails and other times they both work, but normally they both fail .

For all people,
I have reviewed the configuration again and another technician must have entered dot1x configuration and I think the old configuration has interfered. Above the normal aaa lines but below aaa-new model,:
"aaa local authentication default authorization default"
which I understand in turn calls:
"aaa authentication dot1x default group Radius1 local"
This makes me try with Radius and it fails. It tries to logon by entering the user as a radius user and not as a local user when tacacs fail.

 I have seen in the debug that it seems that sometimes it authenticates but does not authorize and other times it authorizes and authenticates but these are the least frequent, normally the authorization fails.
When sometimes it succesfully I can see in the log two different behaviors for the same user,  a messagge of radius dead and not responding, maybe it is casual when radius is dead, then I imagine it already uses local authentication and works.

Other time when authenticates it is follow radius user and process, I dont understand how to go to loggon but it is successfully, I don't understand how it manages to authenticate with the same user that fails other times by radius. I would need to capture more logs and analyze the Radius configuration that I do not know right now, but the important thing is why it doesn't work as I said, normal behavior is that it fails, because it tries to logon by entering the user as a radius user and not as a local user.

g 13 11:05:36.906: %SEC_LOGIN-5-WEBLOGIN_SUCCESS: Login Success [user: ciscotest] [Source: 192.168.1.1] at 13:05:36 UTC Mon Aug 10 2024

WLCISCO#

Aug 13 11:06:08.063: AAA/BIND(000010C5): Bind i/f

Aug 13 11:06:08.063: AAA/AUTHEN/LOGIN (000010C5): Pick method list 'LOGINTEST'

Aug 13 11:06:28.209: AAA/BIND(000010C6): Bind i/f

Aug 13 11:06:28.209: AAA/BIND(000010C7): Bind i/f

Aug 13 11:06:28.209: AAA/AUTHOR: auth_need : user= 'copyrightbanneruser' ruser= WLCISCO 'rem_addr= 'async' priv= 15 list= '' AUTHOR-TYPE= 'commands'

Aug 13 11:06:28.261: AAA/BIND(000010C8): Bind i/f

Aug 13 11:06:28.261: AAA/AUTHEN/LOGIN (000010C8): Pick method list ' LOGINTEST '

Aug 13 11:06:28.083: %WEBSERVER-5-LOGIN_FAILED: Chassis 2 Login Un-Successful from host 192.168.1.1

Aug 13 11:06:48.406: AAA/BIND(000010C9): Bind i/f

Aug 13 11:06:48.406: AAA/BIND(000010CA): Bind i/f

Aug 13 11:06:48.407: AAA/AUTHOR: auth_need : user= 'copyrightbanneruser' ruser= WLCISCO 'rem_addr= 'async' priv= 15 list= '' AUTHOR-TYPE= 'commands'

Aug 13 11:06:48.459: AAA/BIND(000010CB): Bind i/f

Aug 13 11:06:48.459: AAA/AUTHEN/LOGIN (000010CB): Pick method list ' LOGINTEST '

Aug 13 11:06:48.281: %WEBSERVER-5-LOGIN_FAILED: Chassis 2 Login Un-Successful from host 192.168.1.1

But there is a log that I don't understand and it is this user, maybe it doesn't have much to do with it but I don't know. and  I don't know if it's something internal: "copyrightbanneruser":
13 10:34:35.169: AAA/AUTHOR: auth_need : user= 'copyrightbanneruser' ruser=...........

I didn't have time for more tests but the other quiestion for me,  why via SSH it uses the local ones and does not do the same as in the attempts via https if both call the same method. Maybe another time I can do more debugging and test the ssh and look for differences.

[Rich R · Accepted solution]

copyrightbanneruser is a known bug ...  There are actually 3 opened for it:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw28460 - says fixed but doesn't list any fixed versions - very irritating when they do this!
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwe57808 - showing as a duplicate of CSCvs94910
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs94910 - classified as "Enhancement" They are treating it as a new feature request and it will only get fixed if a big, important customer makes a big enough fuss and business case for getting it fixed.  You'll notice there's already 38 cases attached to it!  Suggest you open a TAC case to get yours attached to it too, and ask TAC for the status of getting it fixed.  The bug notes have more detail on the workaround.  Basically command authorization is not supported at all on 9800 GUI.

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214490-configure-radius-and-tacacs-for-gui-and.html#toc-hId-2036691447
"When TACACS+ or RADIUS is used for 9800 WebUI authentication, these restrictions exist:

• Users with privilege level 0 exist but have no access to the GUI

• Users with privilege levels 1-14 can only view the Monitor tab (this is equivalent to the privilege level of a read-only locally authenticated user)

• Users with privilege level 15 have full access

• Users with privilege level 15 and a command set that allows specific commands only are not supported. The user can still be able to execute configuration changes through the WebUI

These considerations cannot be changed or modified."