VMware ESXi and vSphere Cluster Management

Configure vCenter Single Sign-On Password, Lockout, and Token Policies

Learn how to configure vCenter SSO password, lockout, and token policies, including local-account scope, security tradeoffs, validation, and troubleshooting.

vCenter Single Sign-On (SSO) is the vCenter Server authentication service that validates identities and issues authentication tokens for vSphere components. Its policy settings centralize important authentication controls for the vCenter SSO domain, commonly named vsphere.local.

This lesson explains how to view and modify the three SSO policy categories: password, lockout, and token policies. The examples apply to local SSO accounts. They do not replace the password and lockout policies enforced by an external identity provider such as Active Directory.

Policy categories and scope

Policy category — Primary purpose — Main settings — Affected identities or workflows

Password policy — Controls local password construction, age, history, and repetition — Lifetime, history, length, character classes, repeated characters — Local SSO users

Lockout policy — Limits repeated failed sign-ins — Failed-attempt threshold, observation interval, unlock duration — Local SSO accounts

Token policy — Controls token validation, renewal, delegation, and lifetime — Clock tolerance, renewal count, delegation count, token lifetimes — SSO-authenticated services, integrations, and automated workflows

Choose values that balance security, availability, administrator usability, and compliance requirements. A restrictive setting can reduce attack exposure but may also interrupt automation or make recovery harder. A permissive setting can improve compatibility while increasing the time or opportunity available to an attacker.

Permissions and preparation

Changing these settings requires an account with vCenter Single Sign-On administrative privileges. Before editing a policy:

1. Confirm that you have an authorized SSO administrator account.
2. Maintain another authorized administrator account or a documented recovery path before testing restrictive lockout controls.
3. Record the current values and the approved target values.
4. Use your organization's change-management and security-review process.
5. Confirm that time synchronization is healthy before changing token clock tolerance.

In the vSphere Client, sign in to the vCenter Server management interface and open Administration > Single Sign-On > Configuration > Policies. The page provides separate entries for Password Policy, Lockout Policy, and Token Policy.

Configure the password policy

A password policy defines how local SSO users create and maintain passwords. It can enforce password age, prevent recent-password reuse, require a minimum or maximum length, require several character categories, and limit adjacent repeated characters.

Password-policy workflow

1. Open Administration > Single Sign-On > Configuration > Policies.
2. Select Password Policy.
3. Select Edit.
4. Enter the required policy description.
5. Configure the password settings according to the approved standard.
6. Review the intended effect, then save the policy.
7. Verify that the save completes successfully and that the displayed values match the approved configuration.

Setting — Meaning — Unit or value type — Security and usability consideration

Policy description — Identifies the purpose or standard represented by the policy — Text; required — Use a clear description so later administrators understand the setting's intent.

Maximum password lifetime — Determines how long a password can be used before it expires — Days — Shorter lifetimes can reduce exposure after a credential compromise, but frequent expiration can encourage unsafe workarounds and increase support effort.

Password reuse restriction — Prevents a user from reusing a configured number of recent passwords — Count or history value — A useful history prevents cycling immediately back to an old password.

Minimum password length — Sets the fewest characters allowed — Characters — Longer passwords or passphrases generally improve resistance to guessing.

Maximum password length — Sets the most characters accepted — Characters — Make the limit compatible with administrative tools and password managers.

Character-type requirements — Requires multiple categories such as uppercase letters, lowercase letters, digits, and symbols — Number of required classes — Strong complexity can help meet policy requirements, but overly complicated rules can reduce usability.

Adjacent repeated-character limit — Limits how many identical characters may appear consecutively — Character count — Reduces simple patterns such as repeated digits while avoiding unnecessary rejection of usable passphrases.

For example, a local SSO hardening standard might require an approved expiration period, a minimum length, several character classes, password-history protection, and a limit on consecutive identical characters. These rules affect vsphere.local users, not Active Directory users.

After saving, test the rules with a noncritical local SSO test account where feasible. Test both an intentionally invalid password and an approved password. Do not use the only SSO administrator account for exploratory testing.

Configure the lockout policy

A lockout policy limits repeated failed sign-in attempts for SSO accounts. It helps resist password-guessing attacks, but an overly aggressive policy can lock accounts because of typing errors, outdated saved credentials, or scripts that repeatedly submit an old password.

Lockout-policy workflow

1. Open the Policies page through Administration > Single Sign-On > Configuration > Policies.
2. Select Lockout Policy.
3. Select Edit.
4. Enter the required policy description.
5. Set the failed-attempt threshold, failure observation interval, and unlock duration.
6. Save the policy and verify the displayed values.

Setting — Meaning — Unit — Operational impact

Policy description — Identifies the purpose of the lockout configuration — Text; required — Document the intended security and recovery behavior.

Failed-attempt threshold — Number of failed sign-ins that triggers account lockout — Attempts — A lower threshold resists guessing more quickly but increases the chance of accidental lockouts.

Failure observation interval — Time window in which failed attempts must occur to count toward the lockout condition — Seconds — Attempts outside the window do not contribute to the same lockout event.

Unlock duration — Time an account remains locked before it becomes usable automatically — Seconds — A nonzero value supports automatic recovery; a zero value requires administrator action to unlock the account.

Compare a temporary automatic unlock with an unlock duration of zero. Automatic recovery can reduce administrative workload, while zero can provide tighter control when account compromise is a serious concern. If using zero, document the authorized administrative procedure for restoring access.

Test lockout behavior carefully with a test account. Never risk losing access to the only SSO administrator account. Also check clients, scripts, password managers, and integrations for stale credentials before concluding that a user caused the lockout.

Configure the token policy

A token policy governs SSO authentication-token validation, renewal, delegation, and lifetime behavior. A token is a credential issued after authentication so that a vSphere component or service can continue making authorized requests without repeatedly collecting the user's password.

Token-policy workflow

1. Open the Policies page through Administration > Single Sign-On > Configuration > Policies.
2. Select Token Policy.
3. Select Edit.
4. Configure clock tolerance, renewal count, delegation count, bearer-token lifetime, and holder-of-key token lifetime.
5. Save the policy.
6. Verify that the save succeeded and that every displayed value matches the approved configuration.

Setting — Applies to — Meaning — Unit — Potential integration impact

Clock tolerance — Token validation between clients and the SSO domain-controller time source — Permitted time difference before clock skew can invalidate a token — Milliseconds — Too little tolerance can reject valid requests when clocks drift; too much can hide a time-synchronization problem.

Maximum token renewal count — Clients renewing an existing token — Maximum number of times continued validity can be obtained from the existing token — Count — A low value can require a client to obtain a new token sooner than an integration expects.

Maximum token delegation count — Holder-of-key tokens used through service chains — Maximum number of permitted delegation steps — Count — A low value can break workflows in which multiple services act for the original principal.

Maximum bearer-token lifetime — Bearer tokens — Maximum validity period for a possession-based token — Time value — Short lifetimes reduce exposure if a token is copied, but may interrupt long-running operations.

Maximum holder-of-key token lifetime — Holder-of-key tokens — Maximum validity period for a token bound to embedded security material — Time value — A longer value may support integrations but leaves the associated authorization valid for longer.

Token concepts

A bearer token is accepted primarily because the requester possesses it. It is intended for short-duration use and is not cryptographically bound to the requester in the same way as a holder-of-key token.

A holder-of-key token is associated with security material. The holder must demonstrate possession of the related material, giving the token stronger binding characteristics during delegated operations.

Token delegation allows a service to act for the principal represented by a delegated authentication token. A delegation request can identify a DelegateTo target represented by a solution token or a reference to one. A solution token is a token identity used by a vSphere solution or service and can be the target of delegated work.

Token type — Authentication characteristic — Typical use — Delegation capability — Lifetime control

Bearer token — Accepted based on possession — Short operations and service requests — Depends on the workflow and policy — Maximum bearer-token lifetime.

Holder-of-key token — Bound to embedded security material — Delegated service-to-service operations — Supports delegated operations subject to the delegation limit — Maximum holder-of-key token lifetime.

Changing token lifetimes, renewal limits, delegation limits, or clock tolerance can affect vSphere integrations and automated workflows. Before making a change, identify which token type the integration uses, how long operations run, whether tokens are renewed, and how many services participate in the delegation chain.

Applying and validating changes

1. Save one policy at a time and verify successful completion.
2. Compare the displayed values with the approved change record.
3. Use a noncritical local SSO test account to validate password rules where feasible.
4. Test lockout controls cautiously and retain an independent administrator recovery path.
5. Confirm synchronized time on vCenter Server, clients, domain controllers, and supporting infrastructure before modifying clock tolerance.
6. After token-policy changes, test authentication for integrated vSphere services, scheduled jobs, and automation.
7. Record the final values, test results, and any exceptions.

Security and operational guidance

• Prefer properly synchronized time sources over broadly increasing token clock tolerance.
• Avoid excessive token lifetimes or delegation counts unless a documented integration requires them.
• Review SSO policies periodically and after changes to identity sources, security standards, or integrated solutions.
• Keep at least two authorized SSO administrator accounts, or maintain a tested recovery path.
• Distinguish SSO policy enforcement from directory-native password and lockout policies used by external identity providers.
• Align policy values with the organization's security baseline, availability objectives, and compliance obligations.

Troubleshooting

A local SSO account is unexpectedly locked

• The failed-login threshold may have been reached within the configured observation interval.
• A client, script, or integration may still be submitting an outdated password.
• An unlock duration of zero may require an authorized SSO administrator to unlock the account.

Review the lockout values, identify failed-login sources, correct stale credentials, and follow the approved administrative unlock procedure.

A password change is rejected

Check the minimum and maximum length, required character categories, password-history restriction, and adjacent repeated-character limit. Choose a new password that satisfies every active rule.

Token validation fails after a time change

Clock skew may exceed the configured tolerance because NTP or another time source is misconfigured on a client, domain controller, vCenter-related system, or supporting host. Restore consistent time synchronization first. Review clock tolerance only after resolving the underlying time-source problem.

An integration stops authenticating after token-policy changes

Determine whether the workflow uses bearer or holder-of-key tokens. A lifetime may be too short, the renewal count may be insufficient, or the delegation limit may not support the service chain. Validate the integration in a controlled environment and adjust only the relevant setting before retesting.

Exam-relevant notes

• Password policy applies to local SSO-domain accounts, not automatically to external identity-provider accounts.
• The lockout observation interval is measured in seconds, and attempts must occur within that interval to count toward the threshold.
• An unlock duration of zero means administrator action is required.
• Clock tolerance is measured in milliseconds and should not be used as a substitute for reliable time synchronization.
• Token renewal count limits renewal of an existing token; it does not simply define password validity.
• Token delegation allows a service to act for a principal and can identify a DelegateTo solution identity.

For related administration, review assigning vCenter Server permissions, the vSphere access control system, and broader VMware ESXi administration topics.