“Your login attempt was not successful. The username/password combination is incorrect or the account specified has been locked.”
Not being able to login to NSX-T 3.0 can be caused by different reasons. There’s the obvious of bad username/password, or locked out account after you hit the timeout values. From my research I’m not seeing a lockout for the UI, just API and CLI. Let me know if that is incorrect. The CLI for example is set to 900 seconds by default.
There is also the scenario where you no longer remember the local admin password. This blog does not cover that scenario as others have already documented it.
Here I want to talk about what happens when you don’t change the default expiration of 90 days for a local account and try to login after it has expired. This shouldn’t happen to most because there are multiple alarms in NSX to let you know passwords are expiring. I shared those at the end of this blog.
I came across this in a lab environment where I was deploying a vApp (vCloud Director) that had NSX T 3.0 within it. The NSX-T Managers were clearly installed over 3 months (90 days) ago and when I deployed it I couldn’t login and received the message displayed at the top. There is a KB article that hits right to the point of resolving this, but I figured I’d share some screenshots and other observations while going about resetting an expired password in NSX-T.
** This explanation assumes you still know the latest password for the expired local user account.
Reset NSX-T Local User Expired Password
Start by connecting to your NSX-T Manager via an SSH session.
Next, Enter the password for the local Admin user.
Here is the nice part, the manager knows the password expired and is giving you a chance to reset it. Start by entering the current (expired) password. You will then enter the new password twice. Be aware the minimum password length is 12 characters.
Interestingly after entering the new password twice my putty session closed. Not sure if this is normal behavior or putty specific. I guess it forces you to re-initiate an SSH session using the new credentials.
You should now be able to login to both the CLI and UI using the Admin account and the new password. Done, but let’s talk about adjusting that policy if you don’t want this to happen again.
Changing the NSX-T Local User Password Expiration Policy
Be aware this is my lab environment and it doesn’t stay live long so I’m not worried about the security of it. Therefor I disable most password policies in case I shut it down for a few weeks or months. In a production environment you want to match your security policies for passwords, especially for root/admin accounts
From the CLI using putty we can view the password expiration for each local account.
| Description | CLI Command |
| Display admin expiration time | get user admin password-expiration |
| Display root expiration time | get user root password-expiration |
Below you can see I just reset the admin password so it now shows 90 days until the password expires.
Next, running the same command for the root user account I can see the password expired 29 days ago.
There are two options for changing the policy. Either remove the policy so the password never expires or set it to any time frame 1-9999 days. Below I removed the policy for root and increased the admin expiration to 999 days.
| Description | CLI Command |
| Remove the password expiration policy | clear user root password-expiration |
| Change the password expiration | set user admin password-expiration 999 |
Clear the root password expiration:
Set the admin password to expire in 999 days:
Once you have the passwords reset and your policy adjusted be sure you can log in with the appropriate accounts.
NSX-T Password Expiration Alarms
If you click on Alarms you can see there were alarms triggered for the expiring/expired passwords. Of course I couldn’t login before to see this, but it’s nice to know they do trigger in advance should you be actively monitoring the environment. Adding email alerts or other log utilities can help ensure you don’t miss alarms.
Here you see entries for both the root and admin account passwords expiring.
What’s nice is how clear the status is. Open, meaning still active and not resolved. Resolved, meaning the alarm trigger has reset and is no longer experiencing the issue. They did a nice job with this view.
You can see in my screenshots the root account hasn’t resolved even though I changed the policy moments ago. It did update and show resolved after I hit the Refresh button in the lower left.
You may notice the top widgets did not change. Clicking the Refresh in the upper right appears to refresh the whole Alarm Dashboard which now shows resolved for everything. Pay attention to which Refresh you click as they apply to different objects on the dashboard.
If you made it this far on what should be a simple fix I hope you found some value in it. Thanks for reading!