Resetting the Root Password on VMware ESX 4.0

Earlier today, I had to reset the root password on a lab server running VMware ESX 4.0 Update 1. For some reason, the password we assigned yesterday when we built the server from scratch wasn’t working this morning. OK, no big deal, right? Just reboot the server into single user mode and away you go. I won’t bother to repeat the steps for getting into single user mode; go to this article and it will give you what you need (the article is written for ESX 3.5 but it works fine for ESX 4.0).

Because this is a lab environment we just wanted to assign a simple password that anyone on the team could easily remember. (I’m sure the security purists out there are screaming right now.) Unfortunately, once I had the ESX host booted into single user mode, the passwd command insisted on making me use a complex password. There didn’t seem to be any simple way around the restriction.

However, having spent a fair amount of time with PAM (Pluggable Authentication Modules) during my Linux-AD integration experiments, I figured there was a way around it by modifying the PAM configuration. Sure enough, the /etc/pam.d/system-auth-generic file contained a reference to pam_passwdqc.so, the library that is responsible for ensuring complex passwords. The fix, therefore, was to somehow remove pam_passwdqc.so from the PAM configuration so that I could assign a simple password.

The first thing I tried was simply commenting out the line for the module, but the passwd command then failed to work, reporting an error that the authentication token could not be obtained. Strike 1! Next, I leave the pam_passwdqc.so module commented out and try changing the next line to required instead of sufficient. Same error: strike 2!

Finally, I simply replaced the pam_passwdqc.so line with a reference to pam_cracklib.so (after making a backup copy of the original /etc/pam.d/system-auth-generic file, of course—it never hurts to be prepared). Success! I was able to assign a simple password to the lab server.

After putting the original /etc/pam.d/system-auth-generic back in place and rebooting the host, we were back in action! So, what was the lesson learned? You can’t stop someone who’s determined to get around security requirements! No, I’m just kidding…there is no lesson learned. I just thought someone might find this information useful or interesting. Enjoy!

Tags: , , , ,

  1. nate’s avatar

    Another option, what I do for our QA stuff is simply overwrite the password field in /etc/shadow with the encrypted password of choice(taken from another ESX host, or linux host provided it is using the same hash/crypto scheme), of course may not be for the faint of heart if your not famillar with linux or linux-like systems

  2. Michael McNamara’s avatar

    Scott, you did that on your third day of employment at EMC?

    You realize that the ultimate problem was most probably between the keyboard and chair. :)

    Thanks for sharing the fix though!

  3. Peter’s avatar

    openssl passwd -1 y0ur_n3w_pw
    will give you a correct hash that you can put in /etc/shadow per nates description.

    openssl passwd -1
    will prompt you for the password and return the hash if you don’t want to type the password on the commandline.

  4. slowe’s avatar

    Peter,

    Good tips—thanks!

  5. J. Carlos’s avatar

    Any solution for ESXi 4.0?
    Thanks

  6. Chris Edillon’s avatar

    FYI the pam_passwdqc module has an option that will only enforce password checking for users, bypassing the root check. at the end of the pam_passwdqc line, add “enforce=users”. instead of enforcing complex passwords, you’ll get a warning that the password is weak, but you’ll still be able to set it to whatever you want. i’m not at an ESX console at the moment, but there should be documentation on the pam_passwdqc options under /usr/share/doc somewhere.

  7. Gleb’s avatar

    Thanks for linking to my article, Scott!
    Seems like you’ve gone the longer but certainly more educational way about your password change – thanks for sharing!

  8. kopper’s avatar

    I had the same issue today

    I install 2 ESX for testing on my lab using weird password but I want my partner to use the lab too

    so I did this

    password required /lib/security/$ISA/pam_passwdqc.so min=5,0,0,0,0 similar=deny match=0

    basically pam_passwdc.so has some settings for minimum letters – complex characters and so on

    so I only required a minimum of 5 letters and no complex letters

    I was from Pcha┬┐va3i84_- to manager :)

    check this out
    http://articles.techrepublic.com.com/5100-10878_11-6111316.html

  9. Jason Boche’s avatar

    Ed Haletky to arrive on scene in 3…2…1… :)

  10. MaorE’s avatar

    Kopper suggestion correct, just to complete how it should be done…

    first see this lame KB:
    http://kb.vmware.com/selfservice/search.docmd=displayKC&docType=kc&externalId=1012033

    then… just follow Kopper instructions update /etc/pam.d/system-auth-generic

    relevent for ESX 4

Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>