Note A FAIL response is significantly different from an ERROR. A FAIL means that the user has not met the criteria contained in the applicable authentication database to be successfully authenticated. Authentication ends with a FAIL response. An ERROR means that the security server has not responded to an authentication query. Because of this, no authentication has been attempted. Only when an ERROR is detected will AAA select the next authentication method defined in the authentication method list.
I would equate the verbage "not met criteria contained in the applicable authentication database to be successfully authenticated" to encompass being absent from a database - including the local. This tells me that the command, "aaa authentication login default local tacacs enable," would fail if anything did not exist in the local database. However, according to a Cisco engineer who is an expert on dial and ISDN, this command would *not* FAIL, but would go to the next authentication type (tacacs). So, according to the expert, the semantics are incorrect or at best unclear when faced with reality.
This leaves me with the question(s):
What does "met the criteria" mean when using local authentication?
What does "met the criteria" mean when using tacacs authentication?
Or to be less pedantic - when do you get a FAIL and when do you get an ERROR from each of the types of authentication? Maybe (returning to the pedantic) the local authentication *doesn't respond* to the authentication query if it isn't in the database, which would be the behavior described for an ERROR.
That is a very good question, and the CCO docs are not very clear on this point. First let's take a look at that method of "local." This one stands out, and its failover behavior is not like any other method. When the method of "local" is used and the user provides a username that does not exist in the local database (in the config), it will move on to the next method, instead of failing the user. But the method "local" is the ONLY one that will do this. With all other methods, if the user provides a username that does not exist in said database, the authentication will fail.
Just to clarify, here is an example:
aaa authentication login default local group radius
With this in the config, let's say user george telnets it. He does not have his username listed in the config, but he does have his username in the radius server. So the router begins with the method "local," and the user provides "george" as the username. The router recognizes that this name does not exist in the local database, so it will move on to the next method, which is "group radius." This is the exception; only the method of "local" behaves like this.
In contrast, we have this command:
aaa authentication login default group radius local
With this config, let's say user jim is trying to authenticate. He does not have his username on the radius server, but he does have his username in the router config. The router begins with the method "group radius," jim provides his username which does not exist in the radius database, and at this point the authentication fails. It does not move on to the next method, since the username does not exist in the method's database, it stops right there and goes no further. This is the normal behavior.
So it is true that the only three responses you will receive from a radius or tacacs+ server are pass, fail, or error. Pass and fail are obvious, but "error" will ONLY be returned if the device (e.g. router) does not receive a response from the AAA server - that is, a response to its authentication request. If the AAA server receives the authentication request and does not have the username in its database, it will return "fail" and the authentication will fail.
On a side note, this was not always the case. Travel back to earlier code around 11.1 to 11.3 and you had to add the command "aaa local-override" to get it to behave this way. Now it is just automatic, and no way to turn it off.
I apologize if this was a bit lengthy, I want to make sure that not only you understand, but also anyone else who may peruse this forum. If anything is not clear, please reply and I would be happy to clarify.
BenefitsDocumentationPrerequisiteImage Download LinksLimitationsSupported PlatformsLicense RequirementsTopologyStep-By-Step ConfigurationConfigure Virtual ServiceActivate the virtual service and configure guest IPsConfiguring UTD (Service Plane)Configurin...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...