ArubaOS and Controllers

Reply
Regular Contributor II

internal database during code upgrade

Is there anything special that needs to be done with the internal database when performing a firmware upgrade?

I recently tried to upgrade from 5.0.2.0 to 5.0.3.3 (on my way to 6.1.x) and had issues with remote sites no longer being able to login with our "guest" account (created in the internal database).

I now realize there may be issues with not being able to upgrade all controllers simultaneously - but it is what it is. I don't have the resources to upgrade 175 controllers at once.

I guess my main issue is that when I went into the master controller (3600) to find the "guest" account (Security > Authentication > Servers), clicking on the Internal DB yielded no results. It was almost as if the option was grayed out....absolutely nothing populated on the right-side of the screen.

Started to be a problem when the sites started calling saying the account wasn't working.

What could have caused this? We don't have the local account on all the branch/remote controllers, only on the master.

Is there an issue with the internal DB on 5.0.3.3?
Guru Elite

Re: internal database during code upgrade

There should not be an issue on the local database on the master. Did you re-create that account and have the same issue?

By default, all of the remote sites use the guest user in the local database on the master controller. If your local controller is going to be a different code than a master controller, you have the option of creating that guest user locally on the local controller and then configuring that local controller to look at itself for guest user accounts, instead of the master controller. The long-term solution to this is to have the controllers point to LDAP for that guest user so that there is no dependency on the master controller for that guest account. You could create an LDAP connector to active directory where the base-dn field is the top container where you have that guest account, so only users in that container are authenticated by all your controllers.

To point a local controller to itself for the guest account do this:

config t
aaa authentication-server internal use-local-switch

Create the user on the local database of the local controller and it will always use the local controller account,


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Regular Contributor II

Re: internal database during code upgrade

Thanks. That's going to have to be my temporary fix for this issue.

Originally the goal was to change the password on this local account at a fixed interval, so obviously having it on the master made sense - only have to change it in one place. I don't remember why, but we opted to not create a network account - maybe because of certificates, or because we are split-tunneling this account straight from the branch offices? It's been a while!

Is there any chance that this is like a backwards compatibility issue? Did I make a mistake by upgrading the master controllers first? Should I have done all the local controllers first?

Once I get everything up to 5.0.3.3, I have to do this all over again to get up to 6.1.x.

At this point they don't look like they are concerned with changing this local acct password, so adding it locally is fine, but would still like to have an idea on ways to avoid this issue just for future reference.

Something tells me the way to avoid it is to finally get airwave setup and working properly, so that all controllers can be upgraded at the same time!
Guru Elite

Re: internal database during code upgrade

Type "show switches" on the master controller to see what the other controllers are on, and if they have correct connectivity to the master controller, which enables them to authenticate that centralized guest user. Your upgrade is not a major version of code, so it should still work.

The LDAP-to-AD setup does not require any certificates, so it could be something that you definitely want to look into.

Airwave is never a bad idea.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Regular Contributor II

Re: internal database during code upgrade

One more quick one.

Rolled the masters back to 5.0.2.0, but still have users in offices running 5.0.3.3 that say the account isn't working. I'm adding the account locally....and will be doing that going forward.

I noticed in 5.0.2.0 the option (check box) to use local DB is not there - but is in 5.0.3.3. When I upgrade to 5.0.3.3 should I be checking that box? I just want to make sure that doesn't affect our other users that authenticate back here to our RADIUS server.

Also noticed that when I try to add a local user in 5.0.2.0, it doesn't appear to actually stick.

For CLI, these are the commands I should be using?

config t
aaa authentication-server internal use-local-switch
exit $ local-userdb add username "Freeguest" password "Hello" role "guest"



Thank you for all the help. This will be a busy weekend for me!
Guru Elite

Re: internal database during code upgrade

Those are the commands. That command "user-local..." should ONLY exist on a local controller, not a master. type "show switchinfo" to make sure that controller you are dealing with is not a master. Also type "show switches" on the master's commandline to make sure that all of your controllers are accounted for.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Regular Contributor II

Re: internal database during code upgrade





Is there somebody that prevents this command from working via CLI?

I just connected to the 30 or so controllers to add this in, figuring SSH and copy and paste would be much faster than the GUI.

Went back in and checked a couple and see that the user account is not added. The option to use the local DB is checked, but nothing under user account. If I add the acct via the GUI it shows up.

I don't mind adding it via GUI when I'm updating the firmware, since I'm going in there already, but is there a reason the CLI command doesn't work?

Basically it looks like I've wasted all my time doing it, and now will spend 3x as much time going back in via GUI.

Guru Elite

Re: internal database during code upgrade

do a "show audit-trail" to see what commands you put in on the commandline and compare it to the GUI commands and see if there might have been a typo with the commandline.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Guru Elite

Re: internal database during code upgrade


Is there somebody that prevents this command from working via CLI?

I just connected to the 30 or so controllers to add this in, figuring SSH and copy and paste would be much faster than the GUI.

Went back in and checked a couple and see that the user account is not added. The option to use the local DB is checked, but nothing under user account. If I add the acct via the GUI it shows up.

I don't mind adding it via GUI when I'm updating the firmware, since I'm going in there already, but is there a reason the CLI command doesn't work?

Basically it looks like I've wasted all my time doing it, and now will spend 3x as much time going back in via GUI.




Apparently, you need six characters or more in your password, is why it is bombing out:

(3600) #local-userdb add username "Freeguest" password "Hello" role "guest"
Error : Password can not be less than 6 characters long


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Regular Contributor II

Re: internal database during code upgrade

Colin - thank you for the help the other night. You helped fix the issue and saved me a ton of time.


And for anybody else following the thread:

exit $ local-userdb add username "username" password "password1" role "guest" doesn't work. You need to remove the "exit $" from the command.

local-userdb add username "username" password "password1" role "guest" - works like a charm!
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: