Wireless Access

In ArubaOS 6.4.x we would like to have a couple generic Management Users defined on the Aruba Controller.  These generic users will fail authentication on our Radius server and so we do not want the Controller to look there.  However, we have a number of other users who we want to have "Management" access but only after authenticating through the Radius server.

At Configuration > Management > Administration, under "Management Users" we created two accounts, MUSER1 and MUSER2.  We never see any "Management User Statistics" displayed for these accounts even though they are used regularly.  Why not?

Under "Management Authentication Servers" we checked "Allow Local Authentication", we set "Default Role" to "no-access", we checked "Enable", and left "MSCHAPv2" unchecked.  What impact do these settings have?  The ArubaOS 6.4.x User Guide tries to explain it on page 787 but fails miserably.

And we have defined a "Server Group" that contains our Radius server and selected it in the "Server Group >" drop-down box.  Directly to the right of that, notice that the "Show Reference" button will report "None found."  What is the purpose of this "Show Reference" button and why does using a server group in this location not count as a "Reference"?

And we have a set of "Server Rules," one for each User-Name allowed access.

When MUSER1 or MUSER2 logs in to the system, the authentication process includes a check of the Radius server, which makes an LDAP inquiry and logs a failure.  How do we prevent the request for Radius authentication when the user has already been authenticated as a "Management User"?

This is not unique to Radius.  If I substitute a Tacacs server in place of the Radius server I get the same result.

What is the authentication process for "Management Users"? In what order do things happen and how can we configure it to behave like this:  If USER is authenticated as a "Management Users", stop the authentication process and grant RBAC as defined by the assigned Role.  If USER is not authenticated as a "Management Users", try to authenticate the user as defined by our "Server Group" and "Server Rules".

You should use the internal database (not the management user list) to configure your management users.  When you configure the internal database for your users, they must have a management role like root or read-only, otherwise they will not be able to get in.

In the server group, put the internal database first, the radius server second and enable fail through.

Thank you, cjoseph.  It looks like this solves my problem.  However, I am a little uneasy about one thing.  I now have "admin" defined as a "Management User" (and "admin" cannot be deleted from there) and I also have "admin" defined in my Internal DB.  What is the relationship between these two identities and what is each used for?  When is one referenced as opposed to the other?  Exactly what is a "Management User" and when is it referenced?

If an admin attepts to login to a controller and there is no server group on the management screen, only management users will be checked.

If you add a server group and make sure "enable" is checked, the server(s) in the server group will be checked first and the "management users" will be checked second.

If "Allow local authentication" is unchecked, ONLY the servers in the server group will be checked UNLESS the servers are listed as "down".  That way ONLY users in the server group will be checked, unless there is no connectivity to the radius server.  Local Management Users will not be checked under these circumstances.

What I proposed to you is to put users into the internal database, add the internal database to the server group above your radius server and enable "fail through".  The internal database will be checked first.  If your users are not there, fail through will go to the radius/tacacs server.  If they are not there, then they will go to the management users, third.

I hope this gets you going.  Please test this throughly in the lab, as there is the potential to get yourself locked out, of course.

Thank you, Mr. Joseph!  That is what I wanted to understand.  Everything is now working AND we understand why, AND we understand how to modify it if needed.  I appreciate your very quick replies!

Doug