Unlocking and resetting the VMware vCenter Single Sign-On administrator password (vCenter 5.1, 5.5, 6.0)

I ran across this KB article from VMware to resolve this issue caused by a locked SSO password.  I am going to describe the solution specifically for vCenter 6.0 SSO.  For vCenter 5.1 or 5.1, you can go to the KB article link at the bottom of this page to review the other options.

---

Symptoms

• You are unable to log in to the VMware vSphere Web Client using your single sign-on (SSO) administrator credentials.
• Logging in to the vSphere Web Client using your SSO administrator credentials fails.
• The password is incorrectly entered three times (by default).
• You see the error:
  
  User account is locked. Please contact your administrator. 

---

Cause

The SSO Administrator account is automatically locked after too many failed attempts, default is three.

---

Resolution

For VMware Platform Services Controller 6.0

• Wait for 5 minutes. By default, the account lockout policy is set to unlock after 15 minutes. For more information on account lockout policies for the Platform Services Controller (PSC), see vCenter Server Password Requirements and Lockout Behavior in the vSphere Security Guide.
• Unlock the account using another session that is still logged into the PSC server or using another user account with SSO administrator privileges. 
  
  To unlock an account using another session or using another user account with SSO administrator privileges:
  1. Click Home.
  2. Click Administration.
  3. Click Single Sign-On > Users and Groups.
  4. Click the Users tab.
  5. Right-click the affected user account, such as administrator@vsphere.local, and click Unlock.
• In emergency situations or if the default policies are changed, you can also reset the password to unlock the account. 
  
  To reset the administrator@vsphere.local password on a Windows Platform Services Controller or vCenter Server with Embedded Platform Services Controller:
  1. Log in to the vCenter Server with a domain administrator account. If the Platform Services Controller is installed separate from the vCenter Server, log in to the Platform Services Controller server.
  2. Open an elevated command prompt. For more information, see Opening a command or shell prompt (1003892).
  3. Open the vdcadmintool service tool with this command:c:\> "%VMWARE_CIS_HOME%\vmdird\vdcadmintool.exe"
     This console loads:
     
     ===============================
     Please select:
     0. exit
     1. Test LDAP connectivity
     2. Force start replication cycle
     3. Reset account password
     4. Set log level and mask
     5. Set vmdir state
     ===============================
  4. Press 3 to enter the Reset account password option. 
  5. When prompted for the Account UPN, enter:
     Administrator@vSphere_Domain_Name.local
     
     By default, this is:
     
     Administrator@vSphere.local
     
     A new password is generated.
     Note: if you customized your vSphere Domain name, provide the customized domain name.
  6. Use the generated password to log in to the administrator@vSphere.local account.
  7. After the password is regenerated, log in to the vSphere Web Client and change the password.

To reset the administrator@vsphere.local password on the Platform Services Controller or vCenter Server with Embedded Platform Services Controller Appliance:

1. Log in to the vCenter Server Appliance via SSH.
2. Run this command to enable access the Bash shell:
   
   shell.set --enabled true
3. Type shell and press Enter.
4. Open the vdcadmintool service tool with this command:
   /usr/lib/vmware-vmdir/bin/vdcadmintoolThis console loads:
   ================================
   Please select:
   0. exit
   1. Test LDAP connectivity
   2. Force start replication cycle
   3. Reset account password
   4. Set log level and mask
   5. Set vmdir state
   ================================
5. Press 3 to enter the Reset account password option.
6. When prompted for the Account UPN, enter:
   Administrator@vSphere_Domain_Name.local
   
   By default, this is:
   
   Administrator@vSphere.local
   
   A new password is generated.
   
   Note: if you customized your vSphere Domain name, provide the customized domain name.
7. Use the generated password to log in to the administrator@vSphere.local account.
8. After the password is regenerated, log in to the vSphere Web Client and change the password.

---

KB 2034608: http://kb.vmware.com/kb/2034608

Free alternative for backing up VM's for ESXi

William Lam of VirtuallyGhetto.com long ago created a free alternative backup solution for ESXi.  It is distributed as a simple script.  It was developed over 8 years ago for ESX 3.x and continues to be added to and modified today.

Just yesterday William added a post on his site that it is now available in a self installable VIB format.  One of the great things about the VIB is that the program persists now through reboots of ESXi.

The original page for the script GhettoVCB is here: https://communities.vmware.com/docs/DOC-8760

To read more about the latest updates from William and to get to his links for downloading the VIB & offline bundle, click here: http://www.virtuallyghetto.com/2015/05/ghettovcb-vib-offline-bundle-for-esxi.html

Active Directory - Fine-Grained Password Policy

So I have been doing quite a bit of consulting lately and thought I would document some of the more interesting tasks that I run across.  In the last couple of weeks I have dealt with software deployments through GPO and KACE boxes.  Exchange Troubleshooting, VMware Performance troubleshooting, and several other things. 

Got the opportunity to finally implement Fine-Grained password policies.  For those of you that don't know what that is, by default using an AD domain you set one password policy at the domain level and everyone inherits that.  So what if you want to set different policies on different OUs?  No big deal create a couple of GPOs with the policies that you want and apply them to the correct OUs - WRONG!!! That doesn't work.  You can't set password policies on an OU.  You have to set up what they call Fine-Grained Password Policies. 

I found a pretty good TechNet article that pointed me in the right direction.  The problem with a lot of Microsoft's direction is that they point you in the right direction and you are in Los Angeles and want to go to NYC and they say go East.  Now it is on you to figure out how to get there.  This article was exactly that way.  It left out lots of switches and several other things to make sure it was working correctly.

https://technet.microsoft.com/en-us/library/cc754461(v=ws.10).aspx

As I have started to delve more and more back into the Microsoft world I have really come to empower PowerShell quite a bit more than ever.  It started with Exchange where I did a complete migration from Exchange 2010 to Exchange 2013 via PowerShell from Setup to migration to tear down.  Maybe I was bored, maybe I was trying to be cool (As much as computer dorks can be cool).

So I accomplished a lot of this task using PowerShell.  The concept is pretty Easy.  You have to create what is called a PSO (Password Setting Object).  You create this by using the New-ADFineGrainedPasswordPolicy cmdlet.  You then have to specify things like MaxPasswordAge, MinPasswordAge, and a few other parameters.  Not all that hard. 

Once you create the PSO you can view it using ADSI Edit under the Password Settings Container.  You can also modify settings from here if needed.  Once you have gotten this far, it still doesn't work.  Now, you have to assign who is going to have this policy applied to them. 

You would think that you can apply this to an OU, but you would be wrong.  You have to create a Domain Security Group and then grant that group permissions to the PSO.  Now you would think just go to properties and the security tab add it in and you are done.  You are wrong.  You have to go to ADSI Edit, go to that Password Settings Container and locate the PSO you just created.  Click Properties and then click the Attribute Editor tab.  Look for the msDS-PsoAppliesTo attribute.  You then enter the full DN (Distinguished Name) of the Global Security Group.

After that add users to the Group and you are good.

So how do you test.  Well I picked a user (the wrong user) and added him to the group, we then did a bunch of restarts and nothing.  So I found out after some prodding that he changed his password last week but didn't think that would count.  So I checked his expiration date.  It showed a really long number.  Now I had no clue what that number meant.  It showed a regular date in the viewing box but when you tried to modify it (which you couldn't) it showed this long number. 

So what does that long number mean out of curiosity I looked it up.  This attribute is Integer8, a large 64-bit number that represents a date as the number of 100-nanosecond intervals since 12:00 AM January 1, 1601.  1601???  Wow, not quite sure why that number but OK.

Anyway I found a user whose password expired about 2 months ago (He had the password never expires on him, which I had to deselect to see this value).  I added him to the group and did a restart and he had to change his password.  It worked like it should.  So for those of you that want to accomplish this, it isn't really difficult, just play around in a test network like your customers production machines and play around.