Wireless Access

Hello,

I am wondering if there is an alternative way to reset the "admin" password on the Aruba Airwave (AMP) web GUI such as a CLI or API?

Can I just SSH into the device via the "root access" and run a command to reset it?

Thank you!

Any user who has an administrator role and who can successfully log in could update the password from the gui.  If there's not another admin user, then the cli is the only way to do it.  This article describes the process: http://www.airwave.com/support/knowledge-base/?sid=50140000000Meqe .

Thanks! that was very helpful!

Just to add to that helpful knowledbase, do you know HOW thehash is generated? If there is a command, or if it is a standard hash (ie. MD5, SHA-1, etc).  

Thanks,

It's an MD5 hash.

Thanks for your help.

I know this is an old thread, so I'm sorry for the zombie action, but I ran into this problem recently and this was one of the top threads that Google returns, and my question is specific to this thread (more or less).

At one point in this thread, dancomfort said the password is stored in the database as an md5 hash, and that does jive with the password_format field in each user's record.  Later in the thread Rob Gin (re)posts instructions on using dbc to reset the Admin password, and it includes an MD5 hash (2cf94blahblah) for "admin". Why does the hash Rob posted not match the hash from md5sum (21232blahblah)?  Rob's hash DOES work as the admin password in the GUI, whereas the one from md5hash does not.  Is there a way on the CLI to generate a hash that does work?

Thanks,
Dave

While the password is kept in an MD5 hash, I've never been able to decrypt it without the AMP code.  Without digging to far into the code, there's probably additional steps run to make the hash unique to AMP only.  This is intentional to protect the security of the password.  If your end goal is to create a new hash, you can do so by creating a new user and give that user the desired password, and then copy that password hash from the db.

The admin hash should only be used as a temporary rescue hash if all users are locked out of the UI.  Once you've regained GUI access, go to Home -> User Info, and then update the password to a new password.  From there, you can do 'select * from users;' to see the new password's hash value.

Generally, we're steering customers away from using the CLI when possible.  This is just the only way to reset a user from the CLI when all GUI access is lost.

Hi Rob,

Thanks for the reply.  This was mostly just curiosity since I spent an hour or so chasing my tail with a non-AMP hash last week (when I forgot the new password from I'd set a few weeks ago), then used the properly hashed admin password today and it worked like a charm.

OTOH, I now know to also reset the login_attempts and is_enabled fields when resetting that password.

Thanks again,
Dave

Hey, i have locked myself out of my airwave gui and the link you posted goes to a 404 error.  do you know what it was titled? 

Thanks 

From (http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Airwave-Password-Recovery/td-p/34149)

-----------------

If you've lost the password you use to log in as admin to AMP's web interface, you can update it from the command line with this command which stores a hashed version of 'admin' as the password in our database:

From the CLI:

# dbc "update users set password='2cf94b0aea63ebf7bf41c90fe500603e' where username ='admin';"

If you use a name other than admin, you can change your user's password by modifying the where clause above. For example, to change joemontana's password to admin, this would work:

# dbc "update users set password='2cf94b0aea63ebf7bf41c90fe500603e' where username ='joemontana';"

This is not working for me to change password back to admin, when I run the command it says update 1, but login doesnt work.

Although you reset the password, you also need to re-enable the account.  There's 2 additional fields to check.

Blanket command to enable all accounts and reset login attempts

#dbc "update users set login_attempts = '0', is_enabled = 1;"

note that login attempts is an integer string, so needs single quotes.  if you want to be more specific, you can add where username=<insert user> at the end like so:

#dbc "update users set login_attempts = '0', is_enabled = 1 where username = 'rgin';"

Referencing article: http://community.arubanetworks.com/t5/Network-Management/Airwave-Password-Recovery/m-p/34149/highlight/true#M351

Keep in mind that in AMP 8+, there's an additional column 'is_enabled' that should be set to 1.  You may also need to reset 'login_attempts' as well (by default, the max login attempts is 10 tries before account is disabled).

# dbc "select * from users where username='admin';"

-[ RECORD 1 ]---+-------------------------------------------------------------------------------------------------------------------------------
id | 1
username | admin
password | 2cf94b0aea63ebf7bf41c90fe500603e
role_id | 5
full_name |  admin
email |  admin@blank.com
phone |  555-555-5555
notes |
password_format | md5
login_attempts | 0
is_enabled | 1

Hi,

it looks like I´m also having that problem - meaning that the WebGUI User (admin/admin) is locked after 10 wrong attemps... what I don`t understand is the thing, that when I login on the CLI with the ampadmin user I can only access the $mode (menu point 10 and/or 11) in which I can`t run the command

#dbc "update users set login_attempts = '0', is_enabled = 1;"

This is an older thread.  Since 8.2.4 (the introduction of AMPCLI), the way to reset a web user from the CLI has changed.  There's no longer direct DB access, so you'll have to login to the CLI with the ampadmin acct (ampadmin is default, you might have chosen something different).  Under Security -> there's the option to 'Reset Web admin Password.  This operation will also return the user to active state (unlocking the user from password locked state by enabling and resetting login attempts).

AirWave Management Platform 8.2.6.1 on qav6-mb4.corp.airwave.com
1 Upload File
2 Download File
3 Delete File
4 Backup
5 Restore
6 Support
7 Upgrade
8 Advanced
9 Security
10 Custom Commands
11 Enter Commands
q >> Quit
Your choice: 9
Security
1 Reset Web admin Password
2 Change OS User Password
3 Add SSL Certificate
4 Add DTLS Certificates
5 Enable FIPS (requires reboot)
6 Show EngineID
7 Module Key
8 Apply STIGs
9 Set MaxAuthTries value for sshd
10 Make OCSP Optional
11 Generate Certificate Signing Request
12 Install Signed Certificate
b >> Back

Your choice: 1

Running Reset Web admin Password
Choose Web admin account
1 admin
c >> Cancel
Your choice: 1

Resetting the password for 'admin' to "admin"
Are you sure? (y/n): y
Password reset.

This option sets the password to 'admin'.  Once you login, go to Home -> User Info to change the password to something more secure.

Hi Rob,

thank you very much - it worked fine :))

the only thing which I´m still struggling is, that I cannot access the AMP with this (WebGUI) credentials via SSH?!

---

@whistleblower14 wrote:

Hi Rob,

 

thank you very much - it worked fine :))

the only thing which I´m still struggling is, that I cannot access the AMP with this (WebGUI) credentials via SSH?!

 

---

That's expected because the WebGUI creds are only for the WebGUI.  The WebGUI creds live in the database whereas the CLI is governed by Unix level acct permissions.  The AMPCLI should only be accessible from the 'ampadmin' acct and 'amprecovery' accts.  The limited AMPCLI is there to protect the system and the code from attacks.

hm, that`s strange... because in a another deployment I can access the AMP via SSH and the WebGUI user without a problem - is there a way to configure an own access for SSH?

You might be recalling having access to the root shell from older versions.  The AMPCLI was introduced fairly recently (within the last year).  While root shelling of the box is possible, we discourage it.  We have a list of items that we're tracking to improve the AMPCLI.  If there's an operation you're trying to perform and currently can't, please open a support case so that we can track the action that the CLI is lacking.

There's also support implications to root shelling.  Nothing has been determined yet since AirWave is the only software product that had ever provided root shell access in the software group.