VMware ESXi and vSphere Cluster Management

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

Learn how to review and configure vCenter SSO password, account lockout, and authentication token policies, including permissions, time synchronization, validation, and troubleshooting.

vCenter Single Sign-On (SSO) is the vCenter Server authentication component that manages authentication for vSphere services and identities in an SSO domain. Its policy settings help administrators enforce password hygiene, resist password-guessing attacks, protect accounts, control token lifetimes, and support organizational security requirements.

This lesson covers the three configurable SSO policy categories: password policy, lockout policy, and token policy. The settings described here govern identities managed by the vCenter SSO domain. They do not automatically replace the password rules of an external identity source such as Active Directory.

SSO policy categories

Policy category: Password policy. Primary purpose: Control password lifetime, history, length, complexity, and repeated characters. Applies to: Local SSO-domain accounts. Security outcome: Stronger passwords and reduced reuse. Operational consideration: Expiration and complexity rules must be workable for administrators and service accounts.

Policy category: Lockout policy. Primary purpose: Lock accounts after repeated failed authentication attempts. Applies to: SSO accounts subject to the SSO lockout mechanism. Security outcome: Reduced exposure to password guessing. Operational consideration: Stale credentials and automation errors can lock legitimate accounts.

Policy category: Token policy. Primary purpose: Control token timing, renewal, delegation, and lifetime. Applies to: SSO authentication tokens used by vSphere clients and services. Security outcome: Limits the duration and reuse of authentication artifacts. Operational consideration: Values that are too restrictive can interrupt legitimate workflows.

Permissions and navigation

Changing these settings requires SSO administrator privileges. A vCenter role that permits ordinary inventory administration is not necessarily sufficient to administer SSO policies.

1. Sign in to the vSphere Client with an account that has SSO administrative privileges.
2. Open Administration.
3. Open Single Sign-On.
4. Select Configuration, then open Policies.
5. Select Password Policy, Lockout Policy, or Token Policy.
6. Choose Edit, change the required values, and save the configuration.

Before editing production settings, record the existing values, requested values, rationale, approver, expected impact, and change window. Test changes in a nonproduction environment when possible.

Configure the password policy

A password policy defines the rules for password format, complexity, reuse, and expiration. These controls are intended for local SSO-domain users rather than automatically for externally managed identities.

Password policy settings

Description: Administrative text explaining the purpose or ownership of the policy. Unit or value type: Text. Security impact: Improves documentation and auditability. Planning consideration: Record the business reason, scope, and change reference.

Maximum lifetime: The number of days a password remains valid before it must be changed. Unit or value type: Days. Security impact: Limits how long a compromised password can remain useful. Planning consideration: Plan password changes for local SSO administrator accounts and maintain a secure recovery process.

Restrict re-use: The number of recent password values that cannot be selected again. This is also called password history. Unit or value type: Number of previous passwords. Security impact: Prevents cycling between a small set of passwords. Planning consideration: Ensure administrators can manage the required history without unsafe workarounds.

Maximum length: The greatest permitted password length. Unit or value type: Characters. Security impact: Defines the upper boundary for passphrases and password managers. Planning consideration: Check compatibility with administrative procedures and integrated tools.

Minimum length: The fewest characters a password may contain. Unit or value type: Characters. Security impact: Longer minimum passwords generally make guessing more difficult. Planning consideration: Prefer a length that supports strong passphrases while remaining operationally manageable.

Character requirements: The minimum number of distinct character categories required, such as uppercase letters, lowercase letters, numbers, or special characters. Unit or value type: Category count. Security impact: Increases password complexity. Planning consideration: Document which categories the implementation counts and verify the result with a test account.

Identical adjacent characters: The permitted limit for consecutive identical characters. Unit or value type: Character count. Security impact: Reduces repetitive patterns such as several copies of the same character. Planning consideration: Avoid a setting that rejects reasonable passphrases or creates confusion during password changes.

To change these settings, select Password Policy, choose Edit, enter the description and required password values, and save. A stronger policy must be balanced against administrator usability and the operational needs of service accounts or tools that use local SSO credentials.

Example: strengthening local SSO passwords

An organization may require a longer minimum password, several character categories, a defined maximum lifetime, and a history that blocks reuse of several recent values. Apply the approved settings, then test a noncritical local SSO-domain account with compliant and noncompliant passwords.

Configure the lockout policy

An account lockout policy protects an SSO account after repeated authentication failures. It is a defense against password guessing, but an overly aggressive policy can deny access to legitimate users.

Lockout policy settings

Description: Administrative text describing the policy. Unit: Text. Effect: Adds documentation without changing lockout behavior. Special behavior: Use it to identify the owner, purpose, or change record.

Maximum failed login attempts: The number of failed attempts allowed before the account is locked. Unit: Attempts. Effect: A lower value reacts more quickly to guessing but increases the chance of accidental lockouts. Special behavior: The threshold works with the failure interval.

Time interval between failures: The period during which failed attempts are counted toward the threshold. Unit: Seconds. Effect: A broader interval allows failures spread over more time to contribute to lockout; a narrower interval focuses on rapid failures. Special behavior: Attempts must occur within this interval to trigger the configured threshold.

Unlock time: How long the account remains locked before it becomes usable again automatically. Unit: Seconds. Effect: A longer value increases protection during an attack but delays legitimate access. Special behavior: A value of zero requires an administrator to unlock the account manually.

To edit the policy, select Lockout Policy, choose Edit, configure the description, failed-attempt threshold, failure interval in seconds, and unlock duration in seconds, then save.

Consider stale browser credentials, saved passwords, scripts, monitoring systems, and integrated tools when selecting values. A low threshold can reduce brute-force exposure while also locking users because of an old password stored in automation.

Automatic and manual unlock examples

For ordinary administrative accounts, a temporary automatic unlock period can reduce support intervention after accidental failures. For highly sensitive accounts, manual release may be preferable. Pair a zero unlock value with a documented identity-verification and emergency-access process.

Configure the token policy

An SSO token is a time-limited authentication artifact used by vSphere clients and services after authentication. Token policy controls how these artifacts tolerate clock differences, renew, delegate authority, and remain valid.

Token policy settings

Clock tolerance: The permitted time difference between a client and the relevant SSO or directory infrastructure during token validation. Unit: Milliseconds. Tradeoff: A larger value can tolerate minor clock differences but broadens the time window in which a token may be accepted. Fix time synchronization before increasing it.

Maximum token renewal count: The maximum number of times an existing token can be renewed. Unit: Count. Tradeoff: A higher value supports longer workflows with fewer full authentications but can extend the practical use of an authentication chain. After the limit is reached, the client must obtain a new token.

Maximum token delegation count: The maximum delegation depth for holder-of-key tokens. Unit: Count. Tradeoff: A higher value supports more service-to-service delegation but permits longer delegation chains.

Maximum bearer token lifetime: The maximum validity period for a bearer token. Unit: Time duration. Tradeoff: A shorter lifetime limits the risk from possession of a stolen token but may require more frequent authentication.

Maximum holder-of-key token lifetime: The maximum validity period for a holder-of-key token. Unit: Time duration. Tradeoff: A shorter lifetime reduces exposure while a longer lifetime can support long-running authenticated operations.

To edit these values, select Token Policy, choose Edit, configure clock tolerance in milliseconds, renewal and delegation limits, and bearer and holder-of-key token lifetimes, then save.

Bearer and holder-of-key tokens

Token type: Bearer token. Authentication characteristic: Authentication relies on possession of the token. Delegation support: Not the primary characteristic for controlled delegation. Typical intended use: Limited-duration client or service activity. Relevant setting: Maximum bearer token lifetime.

Token type: Holder-of-key token. Authentication characteristic: Includes security material that ties use of the token to its holder. Delegation support: Supports controlled delegation. Typical intended use: Service operations acting for an authenticated principal. Relevant settings: Maximum holder-of-key token lifetime and maximum token delegation count.

Token delegation allows a service to perform actions for an authenticated principal using delegated authority. A solution token is a token identity associated with a vSphere solution or service and may be referenced during delegation. Set delegation limits only as high as documented workflows require.

Time synchronization dependency

Token validation depends on correct time across vCenter Server, directory infrastructure, and connecting clients. Excessive clock skew can make a valid token appear too old, too new, or outside the accepted validation window, producing login or token-validation failures.

Maintain reliable Network Time Protocol (NTP) configuration through the approved design for all relevant systems. Check synchronization status and current time on the client, vCenter Server, and directory services before changing clock tolerance. Increasing tolerance can hide an infrastructure time problem and weaken token timing controls.

Change management and validation

1. Record the current configuration before making changes.
2. Document requested values, the security or compliance rationale, approver, affected identities and services, rollback approach, and change window.
3. Test the change in a nonproduction environment when possible.
4. Apply one policy category at a time so that unexpected behavior is easier to identify.
5. Confirm that an authorized local SSO-domain user can authenticate.
6. Verify expected password length, character, history, expiration, and repeated-character behavior.
7. Test the lockout threshold with a noncritical test account, not an emergency administrator account.
8. Confirm that normal vSphere client and service operations continue.
9. Record the final values and review the settings periodically and after identity-source, directory, or compliance changes.

Troubleshooting common problems

Local SSO user cannot sign in after a password change

• Confirm that the account belongs to the SSO domain governed by the changed policy.
• Check minimum and maximum length, character-category, identical-adjacent-character, and password-history requirements.
• Check whether the password reached its maximum lifetime.
• Reset the password through an authorized administrative process.
• If an SSO administrator account is affected, use the documented emergency-access procedure rather than weakening policy without approval.

SSO account locks unexpectedly

• Look for mistyped credentials and cached credentials in browsers, scripts, automation, or integrated tools.
• Review the failed-attempt threshold and failure interval.
• Wait for automatic unlock when enabled, or use an authorized administrator for manual release when unlock time is zero.
• Remove or update stale stored credentials before testing again.

Token validation fails even though credentials are correct

• Compare current time and synchronization status on the client, vCenter Server, and directory infrastructure.
• Correct NTP or other approved time-source problems.
• Change clock tolerance only after confirming that time is already synchronized and reviewing the security impact.

Users or services authenticate more often than expected

• Identify whether the workflow uses bearer or holder-of-key tokens.
• Review the relevant token lifetime and maximum renewal count.
• Determine whether the renewal limit has been reached and a new token is required.
• Adjust values conservatively, then validate the workflow without making tokens valid longer than necessary.

Delegated service operations fail

• Review the holder-of-key token lifetime and maximum delegation count.
• Confirm that the delegated token has not expired.
• Confirm the service identity and expected solution-token or delegated-token design.
• Increase delegation limits only when a documented workflow requires it and security review approves the change.

External directory users are unaffected by the expected password policy

• Identify the account's identity source and domain.
• Manage password rules for Active Directory or another external directory in that system.
• Use vCenter SSO password policy settings for accounts governed by the local SSO domain.

Key points for administrators

• SSO password, lockout, and token policies solve different security problems and should be reviewed together.
• Local SSO-domain password settings do not automatically govern external directory identities.
• Lockout values must protect against guessing without making stale automation credentials an availability incident.
• Token lifetime, renewal, delegation, and clock-tolerance settings affect both security and operational continuity.
• Reliable NTP is a prerequisite for dependable token validation.
• Always preserve an approved recovery path for SSO administrator access before enforcing expiration or manual unlock behavior.

For the complete navigation and policy workflow in one place, see Configure vCenter SSO Policies.