vCenter Server 6.0 SSO Policies – Where To Change Password Maximum Lifetime etc…

In VMware vSphere 6.0, after default installation of vCenter Server and SSO, there are some vCenter Server 6.0 SSO policies that will most likely interest you. Note that the password policy applies only to users in the vCenter Single Sign-On domain (vsphere.local). If yo just leave the default values you'll be supprised the 91st day you can't login with [email protected] account … This does NOT apply to AD integrated accounts when you add your AD as an Identity source.

Some admins might want to just leave as-is, but I guess that most people will most likely want to match their existing organization password policy. It can be organized many ways. One of those (a very popular one) is set-it and forget-it. Which basically means that the domain admin password policy in your DC is set to never expire…. vCenter SSO for the vSphere.local domain does not allow such a setting, but instead you can just put a number which is very high (like 999999).

vCenter Server 6.0 SSO Policies

Password Policy

You can configure the following parameters:

• Description – Password policy description. Required.
• Maximum lifetime – Maximum number of days that a password can exist before it has to be changed.
• Restrict re-use – Number of the user’s previous passwords that cannot be set again.
• Maximum length – Maximum number of characters that are allowed in the password.
• Minimum length – Minimum number of characters required in the password.
• Character requirements – Minimum number of different character types required in the password.
• Identical adjacent characters – Maximum number of identical adjacent characters allowed in the password.

To get to this screen You must click Administration > Single Sign-On > Configuration

By clicking the Edit button you are able to change values there…

If you leave the default values and after 90 days you will want to log-in you might end up with messages saying that:

• User Account is locked.
• User Account is disabled.

Update: As Leny just commented, the “0” will actually enables the “never expire” option…  Thanks -:).

Those SSO policies are pretty much the same as in vSphere 5.5, but with a difference that in vSphere 5.5 we also had an administrator password expiry on the vCenter server appliance (VCSA). The VCSA 6.0 is pretty much locked out and the GUI we use to manage VCSA accessible via the port 5480 is no longer available.

Lockout Policy

Specifies the condition under which a vCenter SSO account is locked when the user attempts to log in with incorrect credentials. Five login attempts and three minutes between failures are set by default. This policy also specifies the time that must elapse before the account is automatically unlocked.

• Description – Description of the lockout policy. Required.
• Max. number of failed login attempts – Maximum number of failed login attempts that are allowed before the account is locked.
• Time interval between failures (seconds) – Time period in which failed login attempts must occur to trigger a lockout.
• Unlock time (seconds) – Amount of time that the account remains locked. If you enter 0, the account must be explicitly unlocked by an administrator.

To see the lockout policy parameters, click on the Policies tab and select Lockout Policy:

Then there is also a Token Policy… which is also interesting as for example the Clock tolerance shows time difference, in milliseconds, that vCenter Single Sign-On tolerates between a client clock and the domain controller clock. If the time difference is greater than the specified value, vCenter Single Sign-On declares the token invalid.

Other configuration options:

• Maximum token renewal count – Maximum number of times that a token can be renewed. After the maximum number of renewal attempts, a new security token is required.
• Maximum token delegation count – Holder-of-key tokens can be delegated to services in the vSphere environment. A service that uses a delegated token performs the service on behalf of the principal that provided the token. A token request specifies a DelegateTo identity. The DelegateTo value can either be a solution token or a reference to a solution token. This value specifies how many times a single holder-of-key token can be delegated.
• Maximum bearer token lifetime – Bearer tokens provide authentication based only on possession of the token. Bearer tokens are intended for short-term, single-operation use. A bearer token does not verify the identity of the user or entity that is sending the request. This value specifies the lifetime value of a bearer token before the token has to be reissued.
• Maximum holder-of-key token lifetime – Holder-of-key tokens provide authentication based on security artifacts that are embedded in the token. Holder-of-key tokens can be used for delegation. A client can obtain a holder-of-key token and delegate that token to another entity. The token contains the claims to identify the originator and the delegate. In the vSphere environment, a vCenter Server obtains delegated tokens on a user’s behalf and uses those tokens to perform operations. This value determines the lifetime of a holder-of-key token before the token is marked invalid.

Again, your domain admin accounts are not affected by those policies.

Check this page on the blog: vSphere 6.0 Release and updates – vSphere 6.0 page.