This week I installed a fresh vSphere 5.1 Update 1 environment and I wanted to configure it will real world certificates to get rid of all those “Do you really really reeeeeally accept this insecure website” messages. Using the VMware SSL Certificate Automation Tool I generated all the new certificates and then started changing the certificate on the VMware SSO server. When doing this, you’ll be asked for the Master password. Since I learned a while ago in a very painful way that the Admin@System-domain password is not equal to the Master password, I had written down the Master password and was 100% sure I had the correct Master password. But updating the certificate failed with the error: Incorrect master password. Tried it a few times but it kept failing. Logged in with admin@system-domain in the vSphere Web Client and this was the correct password.
I switched to command line and tried to run some SSO Util commands to make sure my password worked and then everything became very clear. I have a bad character in the password. In the password I set during install, there is an “&” (ampersand) and in many console languages this has a special meaning. When running some rsautil commands using the master password VMware&77 I get messages like: “77” is not recognised as a command.
In my homelab I installed a fresh new SSO just for this test. During installation I set the master password to: VMware@55. Then I tested my rsautil command: rsautil manage-secrets -m VMware@55 -a list. This worked, I got a list of … well things.
I then changed the master password using this command: rsautil manage-secrets -m VMware@55 -a change -N VMware&77. This should set the old password to the new password “VMware&77”. Check the output below and notice that the rsautil did perform the change, but also reports an error. Trying the list command with the ‘new’ password, didn’t work.
What had happened is that the master password was changed to “VMware” and everything behind the & was lost. Proof would be if the rsautil command would work with the “VMware” password and it did: rsautil manage-secrets -m VMware -a list.
I did a new test. I removed SSO and the SQL Express database and again installed SSO using the master password “VMware&123” to see what would happen. Login through the Web Client works using the user admin@system-domain and password VMware&123 but the command line tools don’t work.
As long as you don’t have to use the command line tools to change anything in SSO or to recover a password, you’re fine and using the & ampersand in your password won’t hurt you. But if you ever need to change anything with the help of the command line tools, for example when you lost your admin@system-domain password, then you’re lost.
My advice is to use a master password that doesn’t have the & in it. I tested with @ and that works fine. Using the exlamtion point ! also has some issues sometimes, so I would stay away from that too. And the release notes already mention that a space in the password will also get you into trouble.
Seems my friend Christian Mohn is better in using Google than me. He found a mention of this issue in the following KB: “vSphere 5.1 Single Sign On (SSO) installation fails with error: Error 29133. Administrator login error. (2035820)“. The KB article mentions that this issue is resolved now, but as you can see, it isn’t.
In some situations it can be fixed with: rsautil manage-secrets -a change I’ve also tested this in my home lab and somehow it didn’t work, later on I tried it in production because everything else had failed and it worked !!!
5 thoughts on “Be carefull with VMware SSO Master password bug”
A simple fix would be escape the special character in the password. For example, type ‘VMware&77’ instead. Otherwise, the ampersand symbol is seen by shell and interpreted as a shell special character. I suspect single quote the entire password string will work as well.
Unfortunately that doesn’t work. Tried many combinations of escape characters but nothing worked.
Fantastic – excellent post – saved us much heartache :)
I don’t see ! mentioned in the KB 2035820. What kind of issues did you experience with ! in the password?
Haven’t tried that, but I just went back to a character and numbers only loooooon password.
Comments are closed.