AAA for mgmt access question

[mike.j.gallagher]

Documentation is a bit fuzzy, so I'm looking for a simple explanation on what behavior is expected with the command: "mgmt-user localauth-disable" being on and being off.

I'm suspecting that if it's on, the local-db is only consulted if AAA servers are not available, meaning they timeout on auth requests, not just if an authentication attempt is rejected by an active AAA server.

Another reason I ask is because in production, I can login with local credentials (the "admin" account) or using AAA credentials (via RADIUS servers) whether that command is on or off. With the exact config on a test controller, I get what I would expect, no "admin" user login if the AAA servers are available and the command is on.

Thanks...

[michaelw]

Here is the description from the AOS 3.4 user guide.

Disabling Authentication of Local Management User Accounts

With this release, you can disable authentication of management user
accounts in local switches if the
configured authentication server(s) (RADIUS or TACACS+) are not
available.
In pre-ArubaOS 3.4 versions, if the configured authentication server(s)
returned an invalid role, failed to
authenticate the user, or the authentication request timed out,
management users were not authenticated by
the local database.

In this version of ArubaOS, you can disable authentication of management
users based on the results
returned by the authentication server. When configured, locally-defined
management accounts (for
example, admin) are not allowed to log in if the server(s) are reachable
and the user entry is not found in
the authentication server. In this situation, if the RADIUS or TACACS+
server is unreachable, meaning it
does not receive a response during authentication, or fails to
authenticate a user because of a timeout, local
authentication is used and you can log in with a locally-defined
management account.

[olino]

Mike,

That knob should work as you see it in production. If localauth-disable
is enabled, then the local db is only checked if the other servers in
the server group(s) do not respond. If any server in the list does
respond, even if it is a NAK, the local db is not checked.

What version of code are you running production? I would assume it is
the same as the test controller, but you know what they say about
assumptions.

[mike.j.gallagher]

I'm running 3.3.2.16 on both test and production.

I'm confused by what you said about production. In production, no matter if that command is in or out, the local-db is checked and the "admin" user is allowed in.

On my test controller, if that command is in and the AAA servers are up, "admin" is not allowed in. That is what I expect to see.

[olino]

Oops, sorry. It works as you see it in your lab (not production).

[mike.j.gallagher]

LOL, ok, so I'm not going crazy. Just to be totally clear, when I remove that command from the test controller, I can get in with both AAA and local-db accounts, which is correct behavior, yes?

So, it looks like there's something goofy in production. I already opened a case on this, so we'll see what happens.

[olino]

Yes, if you remove the "mgmt-user localauth-disable" command, the
controller will first check the local db (admin) and then the configured
server group.

However, since you are using 3.3.2.16, if "mgmt-user localauth-disable"
IS configured, the expected behavior is that the mgmt users would not be
authenticated by the local db if the AAA servers did not respond. 3.4
works as I described in the previous message.

From the 3.4 Users Guide:

In pre-ArubaOS 3.4 versions, if the configured authentication server(s)
returned an invalid role, failed to authenticate the user, or the
authentication request timed out, management users were not
authenticated by
the local database.

In this version of ArubaOS, you can disable authentication of management
users based on the results returned by the authentication server. When
configured, locally-defined management accounts (for example, admin) are
not allowed to log in if the server(s) are reachable and the user entry
is not found in the authentication server. In this situation, if the
RADIUS or TACACS+ server is unreachable, meaning it does not receive a
response during authentication, or fails to authenticate a user because
of a timeout, local
authentication is used and you can log in with a locally-defined
management account.

[mike.j.gallagher]

Ok, so that just completely changed everything. From what you said, in 3.3.2.16, if I have "mgmt-user localauth-disable" in the config, local-db users (admin, etc) can NEVER logon, regardless of the AAA server state. Which is not what I see at all.

[mike.j.gallagher]

Hmmm, I think the 3.3.2 user guide says the same thing as the 3.4 user guide regarding this functionality.


From the 3.3.2 UG:

With this release, you can disable authentication of management user accounts in
local switches if the configured authentication server(s) (RADIUS or TACACS+) are
not available.
In pre-ArubaOS 3.3 versions, if the configured authentication server(s) returned
an invalid role, failed to authenticate the user, or the authentication request timed
out, management users were not authenticated by the local database.
In this version of ArubaOS, you can disable authentication of management users
based on the results returned by the authentication server. When configured,
locally-defined management accounts (for example, admin) are not allowed to log
in if the server(s) are reachable and the user entry is not found in the
authentication server. In this situation, if the RADIUS or TACACS+ server is
unreachable, meaning it does not receive a response during authentication, or
fails to authenticate a user because of a timeout, local authentication is used and
you can log in with a locally-defined management account.

[michaelw]

Mike,

Take a look at the security logs. It should provide an indication of
how the admin user is getting authenticated.

-michael