"No authorizarion entry found for" router issues, request for help

[nochannel2013]

Hello everybody,  I started having issues with the routers displaying "no authorization entry found for <router ip> <username>".

I can SSH to the routers using the local accounts, the network accounts do not work.  When I do SSH or console in with the local accounts, any and all commands I try return the error mentioned above.  Attached is the AAA config for one such router

aaa new-model
!
!
aaa authentication login default group tacacs+ local
aaa authorization console
aaa authorization config-commands
aaa authorization exec default group tacacs+ none
aaa authorization commands 0 default group tacacs+ none
aaa authorization commands 1 default group tacacs+ none
aaa authorization commands 15 default group tacacs+ none
aaa accounting send stop-record authentication failure
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
!
aaa session-id common

I've read that it was recommended to put the "if-authenticated" but not sure if I need to do this or not, plus even if I should, I cant.  The RADIUS authentication is done via windows 2012 server.

Any and all ideas are welcomed, I have been having this problem for a day and the brass is breathing down my neck.

Thanks!

[Giuseppe Larosa]

Hello nochannel123,

what is inside the server group tacacs+ ?

 A tacacs server or a Radius server ?

I would expect a tacacs server but then you speak of a Radius server on a Windows 2012 box.

However, if you can log in using locally defined accounts this means that the AAA server either Radius or TACACS is not answering to the device.

Cisco routers have no fallback to the next authentication method local in your case.

>> aaa authorization exec default group tacacs+ none

if the server in group tacacs+ is not responsive it tries to go to next authentication method that is none.

You could try to use

aaa authorization exec default group tacacs+ if-authenticated

IF you want to use a Radius server your configuration should be different referring to group radius instead of group tacacs+.

By default group tacacs+ should refer to all tacacs+ servers defined in aaa commands in global config not placed under a named group.

By default group radius refers to all radius servers defined in aaa commands in global config not placed under a named group.

So your aaa commands should refer to group radius if you are using a Radius server.

You need to clarify if you are using Radius or TACACS+ as AAA server and then configure accordingly.

Hope to help

Giuseppe

[nochannel2013]

Giuseppe,

thank your for the reply.  There is no TACACS or TACACS+ Server.  Authentication is done through radius on a windows serer 2012 server.  I can login with the local accounts but I get the "no authorization" error, so I know its not talking to RADIUS or RADIUS is not authenticating the accounts.  Since I cant make any changes, I am having to resort to erase the config and redoing it again.

I will try the if-authenticated tag.  I'll post the results later today.

Many thanks

Joe

[Richard Burts]

I am a bit puzzled. The aaa configs that you post are very specific that they expect tacacs and not radius. But you are specific that the server is radius and not tacacs. This is a significant mismatch.

In the original post you tell us that "I started having issues with the routers". If you started having issues does that mean that the routers did work and then stopped working? Were there changes made at about the time that the issues started? Was there perhaps a config change that changed radius to tacacs?

I agree that you should add the if-authenticated to the config to deal with the immediate issue. But I also think that we need to resolve the underlying problem of the config not matching the server protocol.

HTH

Rick 

[nochannel2013]

Richard,

I inherited this mess about 4 months ago.  I was only clearing out IP routes to sites that no longer exist, and thats all that was deleted (all the routes are static, no OSFP/BGP).  I certainly didn't mess with radius.  The deletion of the routes happened at around 9 AM, and by 3 PM the routers started freaking out, you could ping them, but none of the users could authenticate to the domain, including my domain account.  The local accounts could log in, but I would get the error described".

I agree with you that everything tacacs need to go, since the authentication is all radius (two windows server 2012). 

Thanks for the input, appreciate it.

[Giuseppe Larosa]

Hello Joe,

after the posts you have exchanged with Rick I have changed my opinion about your network.

>> I inherited this mess about 4 months ago. I was only clearing out IP routes to sites that no longer exist, and thats all that was deleted (all the routes are static, no OSFP/BGP). I certainly didn't mess with radius. The deletion of the routes happened at around 9 AM, and by 3 PM the routers started freaking out

You have tacacs servers configured on your devices. Verify if there are running TACACS servers on your network corresponding to those IP addresses.

I mean that you may have RADIUS servers configured, running and ready to use but routers are configured to consult TACACS servers for AAA login authentication and authorization.

The only possible explanation I can find for the fact you have been able for four mounths to access the network devices and make configuration changes is that at least one TACACS+ server is alive in your network.

The configuration changes that you have made can have made the TACACS server not reachable anymore from network devices and the authorization issue with locally defined users has happened.

What is difficult to explain is the few hours delay after the routing change and the start of the issue.

If it was around 4 hours I would think of an ARP entry expiring on some device.

I would suggest you to verify if the configured tacacs servers exist and they can be pinged from a router with an interface on the same subnet.

A possible explanation might be that the TACACS+ server is using a larger (less specific) subnet mask and was relying on proxy ARP of directly connected router(s) to reach all the network devices.

Hope to help

Giuseppe

[nochannel2013]

Richard,

here's the rest of the configuration that is towards the bottom of the running-config:

tacacs-server host <IP>
tacacs-server host <IP>
tacacs-server timeout 1
tacacs-server key 7 <key>
radius-server host <IP> auth-port 1645 acct-port 1646 key 7 <key>
radius-server host <IP> auth-port 1645 acct-port 1646 key 7 <key>
radius-server retransmit 2
radius-server timeout 1
radius-server deadtime 1
radius-server vsa send accounting
radius-server vsa send authentication

[Richard Burts]

Joe

Thanks for the additional information. Are the IP addresses specified for the tacacs servers the same as or different from the IP addresses specified for the radius servers?

It is challenging to see how removing static routes could cause this authentication issue, unless one of the static routes removed impacted access to the authentication server.

I am interested in this part of your response "none of the users could authenticate to the domain, including my domain account."  The original problem described was about executing commands on the routers. So it sounded like an issue just involving the routers. These users who could not authenticate to the domain, are they users who log in to the router for some reason, or are these user PCs etc attempting to use domain resources? If the latter then the problem sounds bigger than just the router.

And I am still puzzled how it could have been working for a while when the authentication/authorization server was radius but the router config was indicating tacacs.

HTH

Rick

[Giuseppe Larosa]

Hello Joe,

you need to rewrite all your  aaa commands like the following:

aaa authentication login default group radius local

and so on.

Replace any occurrence of group tacacs+ with group radius.

Note:

When testing AAA features three useful tips are the following:

a) do not save configuration until you check it is working in all aspects

b) do not close the original vty session in which you are performing configurations, use additional vty sessions to test login and authorization . The new VTY sessions will be processed by the new and current AAA configuration.

c) you can use an ACL with an appropriate deny statement  or a static route to null0 to emulate AAA server failure and to check fallback to local accounts. This is handy as you don't need to isolate the real server from network or to stop the Radius server to make this kind of tests.

Hope to help

Giuseppe

[nochannel2013]

Thank you Giuseppe, I will certainly do this.  A couple of my sites are still down so I'll just do it during the day.