Academy/VCP-VCF 9.0 Administrator (2V0-17.25)/Password & Secrets Management via VCF 9 Password Manager
This lab targets VCF 9.0

Password & Secrets Management via VCF 9 Password Manager

VCF 9.0Intermediateadminarchitectvcdx⏱ 90 min

Core credential architecture applies to VCF 9.0.0 through 9.0.2. Comparison with VCF 5.2 password manager available in Extension 1. Focus is on the integrated Password Manager for service account and root password lifecycle.

Objectives

  • Understand VCF 9 credential architecture: where passwords are stored (NSX Manager, SDDC Manager, vCenter SSO), rotation policies, and audit trails
  • Configure and execute automated password rotation for common service accounts (vCenter SSO admin, ESXi root, NSX admin)
  • Implement manual rotation for break-glass accounts and validate recovery scenarios
  • Integrate VCF Password Manager with external vault systems (HashiCorp Vault, Azure Key Vault) for enterprise compliance
  • Interpret password rotation failure scenarios and audit compliance gaps using SDDC Manager logs

Prerequisites

VCF 9.0.x management domain deployed and operational. SDDC Manager accessible. All four management domain ESXi hosts commissioned and showing Active status. vCenter and NSX Manager fully initialized. Lab account must have SDDC Manager Administrator role.

Prior labs: holodeck-02

Required skills:

  • SDDC Manager navigation (Inventory, Security, Operations sections)
  • Understanding of VCF credential hierarchy (root accounts, service accounts, SSO passwords)
  • Basic understanding of PKI and certificate rotation (optional but helpful)
  • Command-line tools: PowerShell/PowerCLI for vCenter, NSX API access via curl or Postman
  • Familiarity with audit logging concepts and compliance requirements

Lab Environment

VCF 9.0.x management domain with 4x ESXi hosts, SDDC Manager, vCenter Server, NSX Manager. All components deployed and healthy from a prior lab (holodeck-02 or equivalent). No workload domains required for this lab.

IP Addressing

NetworkPurposeVLAN
Management (SDDC Manager, vCenter, NSX)1644

Credentials

SystemUsernamePassword
SDDC Manageradministrator@vsphere.localSet during VCF bring-up
vCenter Serveradministrator@vsphere.localSynced with SDDC Manager SSO password
NSX ManageradminSet during VCF bring-up; managed by SDDC Manager
ESXi Hosts (root)rootSet during host commissioning; rotatable via SDDC Manager

Tasks

Task 1 Audit current credential inventory and rotation policies

manageability

Map the complete credential landscape in VCF — which passwords are managed by SDDC Manager, which are external, and which cannot be auto-rotated. This is a VCDX-critical foundational step: before you can architect a secure credential model, you must understand the current state.

Step 1

Open SDDC Manager UI: https://10.0.0.4. Navigate to Administration > Security > Credentials.

Credentials page displays a list of all managed credentials grouped by component (ESXi Hosts, vCenter, NSX Manager, SDDC Manager)
This view is the source of truth for password inventory. In production, export this list regularly for audit compliance.
Step 2

Expand the ESXi Hosts section. Verify that all 4 hosts show a root credential entry. Click on one host entry to view: credential username, last rotation date, next rotation date (if automated), and rotation policy (manual vs automated).

ESXi host credentials visible with rotation metadata. Example: 'esxi-01.sddc.lab root — Last rotated: 2026-04-01 — Next rotation: 2026-07-01 (Auto, 90-day policy)'
If 'Last rotated' is blank or older than 180 days, the account may have accumulated unauthorized access — flag for investigation. Document the rotation age for each host.
Step 3

Expand the vCenter section. Verify the vCenter SSO admin credential (administrator@vsphere.local). Note: this password is also the SDDC Manager administrator password (they are synced). Verify the rotation policy and compare with ESXi policy — they may differ.

vCenter SSO admin credential shown with rotation policy. Example: 'administrator@vsphere.local — Policy: Manual only (no auto-rotation) — Reason: SSO password affects multiple services'
Step 4

Expand the NSX Manager section. Verify the NSX admin credential (admin@nsx-manager.local or equivalent). Check if the rotation is managed by SDDC Manager (auto) or if it requires manual intervention.

NSX admin credential visible. Policy may show 'Managed by SDDC Manager' (auto, 60-day default) or 'Manual' depending on SDDC Manager version.
In VCF 9.0.x, NSX admin password is typically auto-rotated every 60 days by SDDC Manager. If manual, document the reason — it may indicate a custom integration.
Step 5

Scroll down to view Service Account Credentials (e.g., service accounts for vRealize, vSAN, vMotion, etc.). Document which service accounts are credential-managed vs hardcoded.

Complete list of service accounts. Example: 'vmotion-sync@vsphere.local — Policy: Auto-rotated weekly', 'vsan-health-user@vsphere.local — Policy: Manual'
Step 6

Export the credential inventory to a CSV file for compliance auditing. In SDDC Manager, click the export icon (if available) or manually document: Component, Account Username, Rotation Policy, Last Rotated Date, Next Rotation Date. Save to your lab notes.

CSV file or documented spreadsheet with all credentials and rotation metadata

Validation Gate

Check: SDDC Manager Credentials page: all 6+ credentials visible and documented (4x ESXi root, vCenter SSO, NSX admin, service accounts). Export or manual inventory complete with rotation dates.

Expected: Complete credential map with no missing entries. Rotation ages documented.

Common Errors

Credentials page shows 'insufficient permissions' or is blank
Cause: Lab account lacks SDDC Manager Administrator role or Credentials read permission
Fix: Log in as the SDDC Manager administrator (administrator@vsphere.local). If you are already logged in as admin, verify the role assignment: Administration > User & Group Management > Local Users, verify your account has 'Administrator' role.
📋 KB: SDDC Manager Security — Role-Based Access Control (RBAC) Best Practices
Export button is grayed out or not present
Cause: SDDC Manager version does not support built-in export. Create manual spreadsheet instead.
Fix: Manually copy credential entries from the UI into a spreadsheet (System, Username, Last Rotated, Next Rotation, Policy). This is acceptable for lab purposes.
Some ESXi hosts missing from Credentials list despite being shown as Active in Inventory
Cause: Host was added to SDDC Manager inventory but credential management is not yet synchronized, or the host is in 'Pending' status
Fix: In Inventory > Hosts, verify each host status is 'Active' and 'Configured'. Manually trigger credential synchronization: Administration > Security > Sync Credentials. Wait 5 minutes and refresh.

Task 2 Configure automated password rotation for service accounts

security

Establish a baseline rotation schedule that balances security (frequent rotation) with operational stability (not too disruptive). This mirrors production change management: you'll learn how SDDC Manager coordinates rotation across dependent services.

Step 1

In SDDC Manager, navigate to Administration > Security > Password Policies. Review the default rotation schedule.

Password Policies page shows: ESXi root — 90 days (default), vCenter SSO — Manual only (default), NSX admin — 60 days (default). Click each policy to view the detailed settings.
These defaults are conservative and lab-appropriate. Production policies often use 30-day or even 15-day cycles for highly sensitive accounts. The longer the interval, the larger the window an exposed password could be used.
Step 2

Select the ESXi root credential policy. Modify the rotation interval from 90 days to 30 days (simulating a more aggressive production policy). Click 'Save Policy'.

ESXi root password rotation policy updated to 30-day cycle
Shortening rotation intervals increases automation complexity. In a production environment, you must ensure the rotation automation is rock-solid before tightening the schedule. A failed rotation on a 15-day cycle is worse than a 90-day cycle — the account can lock before the next successful rotation.
Step 3

Verify the vCenter SSO password policy is set to 'Manual only' (not auto-rotated). Confirm this is intentional: the vCenter SSO password is complex to rotate because it affects multiple services (SDDC Manager, NSX Manager integration, vRealize, etc.). Click 'Edit Policy' and note the reason field: 'Multi-service dependency — requires coordinated rotation'.

vCenter SSO policy confirmed as Manual with documented reason
Many production environments do auto-rotate vCenter SSO, but they invest heavily in testing the coordinated rotation. For a VCDX candidate, be able to articulate the risk/benefit: Pro = higher security, Con = increased failure risk.
Step 4

Set the NSX admin password rotation to 45 days (from the default 60 days). Save the policy.

NSX admin rotation policy updated to 45-day cycle
Step 5

Navigate to Administration > Security > Scheduled Tasks. Verify a 'Password Rotation' task exists and is scheduled to run at a safe time (typically off-hours, e.g., 2:00 AM). Check that it's configured to send notifications on success/failure.

Scheduled rotation task visible with execution time and notification settings
Rotation failures should trigger alerts — they are security-critical. Confirm email/webhook notifications are configured.
Step 6

For each credential you modified (ESXi root, NSX admin), click 'Preview Next Rotation' to view which accounts will be affected and in what order. This is the rotation sequence — SDDC Manager rotates them serially to avoid cascading failures.

Preview shows rotation order: (1) ESXi-01 root, (2) ESXi-02 root, (3) ESXi-03 root, (4) ESXi-04 root, (5) NSX admin (all hosts rotated before NSX, to avoid service interruption)

Validation Gate

Check: Password Policies: ESXi root = 30 days, vCenter SSO = Manual, NSX admin = 45 days. Scheduled rotation task visible and configured with notifications.

Expected: All policies configured and documented. Rotation order confirmed (serial, no parallels).

Common Errors

Cannot modify password policy — 'Save' button is disabled
Cause: SDDC Manager is running a rotation operation. Policies cannot be edited during active rotation.
Fix: Wait for the rotation to complete (check Administration > Operations > Recent Tasks for 'Password Rotation' task status). Retry policy modification.
Scheduled rotation task shows 'Not Configured' for notification email
Cause: SDDC Manager SMTP is not configured, or the mail relay is unreachable
Fix: Configure SMTP: Administration > System Configuration > Email. Provide mail relay IP/hostname, sender address, and test with 'Send Test Email'. Verify firewall allows outbound SMTP (port 25 or 587).
Cannot find NSX admin password policy — NSX section is missing
Cause: NSX Manager is not fully integrated with SDDC Manager, or initialization is incomplete
Fix: Verify NSX Manager status in SDDC Manager Inventory > Networking. If NSX status is 'Unhealthy', re-initialize: Administration > System Configuration > NSX Configuration > Refresh. Wait 10 minutes.

Task 3 Execute a manual password rotation and validate the rotation sequence

availability

Understand the mechanics of rotation: the order (why hosts before NSX), the validation checks (ensuring service availability post-rotation), and the recovery path if rotation fails mid-sequence. This is hands-on expertise VCDX panelists will probe.

Step 1

In SDDC Manager, navigate to Administration > Security > Credentials. Select one ESXi host (e.g., esxi-01). Click 'Rotate Now' to manually trigger an immediate rotation (not waiting for the scheduled task).

Confirmation dialog appears: 'Rotate password for esxi-01.sddc.lab root account? This will generate a new password, update it on the host, and update the local credential vault. Estimated time: 2-3 minutes.'
A password rotation temporarily increases the risk of service disruption if the ESXi host is already stressed. In production, coordinate rotations during maintenance windows.
Step 2

Click 'Confirm' to start the rotation. A progress indicator appears. Watch the status update: 'Generating new password... Applying to esxi-01... Verifying SSH connectivity... Rotation complete.'

Rotation completes successfully. Status shows 'Last Rotated: [current time]'. New password is stored in SDDC Manager's encrypted vault.
If you have SSH access to the ESXi host, you can verify the rotation was successful by attempting to log in with an old password (should fail) and then with the new password from SDDC Manager (should succeed). For security, SDDC Manager never displays the actual password — it only stores it encrypted and uses it for automated operations.
Step 3

Verify connectivity to the rotated ESXi host. In SDDC Manager, navigate to Inventory > Hosts. Click on esxi-01. Verify Status = 'Active' with no new warnings or errors. If the host shows any connectivity issues, rotation may have failed mid-way.

ESXi-01 remains Active with no new errors. Connectivity is uninterrupted.
Step 4

Now manually rotate the vCenter SSO admin password (the only manual credential). This requires more care because vCenter, SDDC Manager, and NSX Manager all depend on this password being synchronized. Click Credentials > vCenter > administrator@vsphere.local > 'Rotate Now'.

Confirmation dialog: 'This account is a multi-service dependency. Rotation will: (1) Generate new password, (2) Update vCenter SSO, (3) Update SDDC Manager local admin, (4) Notify NSX Manager of the change. This operation requires all three services to be online. Estimated time: 5-10 minutes.'
If any service (vCenter, SDDC Manager, NSX) is down, this rotation will fail and may leave the services in an inconsistent state. This is why the default policy is Manual — it requires pre-planning and validation.
Step 5

Before proceeding with vCenter SSO rotation, verify all three services are healthy: SDDC Manager dashboard (already open), vCenter: navigate to https://10.0.0.6 and confirm login works, NSX Manager: navigate to https://10.0.0.10 and confirm login works. Document timestamps.

All three UIs are responsive and accepting credentials
Step 6

Proceed with vCenter SSO rotation. Click 'Confirm'. Monitor the progress. SDDC Manager will: (1) Generate a new 32-character password, (2) Update vCenter SSO, (3) Update SDDC Manager local admin, (4) Perform a test login to each service to confirm the new password works.

Rotation completes. Status shows 'Last Rotated: [current time]'. SDDC Manager confirms 'Validation: 3/3 services successfully authenticated with new password.'
The validation step is critical — it proves the rotation succeeded end-to-end. If only 2/3 services validate, the rotation is partially successful but at risk (one service will be out of sync).

Validation Gate

Check: SDDC Manager Credentials: ESXi-01 shows new rotation timestamp. vCenter SSO shows new rotation timestamp. Inventory > Hosts: ESXi-01 status Active. Inventory > Workload Domains: vCenter connectivity shows Active.

Expected: Two rotations (ESXi and vCenter) completed successfully with full connectivity validation.

Common Errors

ESXi rotation succeeds, but SSH to the host fails with 'Permission denied'
Cause: The new password was generated but not actually applied to the ESXi host. This happens if SSH connection is lost during the rotation.
Fix: SDDC Manager stores the new password, but the host still has the old one. Contact the ESXi host directly (vSphere Client > Host > Summary > Edit Settings) or break glass and reset the host root password manually. Manually update SDDC Manager's stored password to match.
📋 KB: VCF Password Manager — ESXi Rotation Failure Recovery
vCenter SSO rotation hangs at 'Updating SDDC Manager local admin'
Cause: SDDC Manager and vCenter are in a deadlock trying to update each other's credentials simultaneously, or network timeout occurred
Fix: Wait 10 minutes (the rotation operation has a 15-minute timeout). If it's still stuck, cancel the operation: Administration > Recent Tasks > right-click rotation task > Cancel. Then: (1) Manually reset vCenter SSO password via vCenter recovery steps, (2) Manually update SDDC Manager local admin password to match, (3) Retry rotation with SDDC Manager primary node first.
vCenter SSO rotation fails: 'Validation: 2/3 services authenticated'
Cause: NSX Manager did not update successfully. This happens if NSX is temporarily unavailable or has network issues.
Fix: The services are now out of sync. Manually fix NSX admin password: Navigate to NSX Manager > Administration > User Management > admin > Change Password (set it to the new password from SDDC Manager). Then retry rotation.

Task 4 Simulate a rotation failure and execute break-glass account recovery

recoverability

Prepare for the failure scenario you'll face in production. When automated rotation fails (account locks, service unavailable, network timeout), you need a documented recovery path. This task builds operational resilience.

Step 1

Intentionally lock an ESXi root account to simulate a failed rotation. SSH into ESXi-02 (use SDDC Manager credentials from Task 3). Run: 'passwd -l root' to lock the account.

ESXi-02 root account is now locked. Attempting to SSH will fail: 'Account locked'
This is a simulation of what happens if rotation automation corrupts the account or applies an invalid password. In production, this indicates a critical issue with the rotation process itself.
Step 2

Now attempt to rotate the locked ESXi-02 root account via SDDC Manager. Navigate to Administration > Security > Credentials > ESXi-02 > 'Rotate Now'. Watch the operation fail.

Rotation fails with error: 'Cannot authenticate to esxi-02.sddc.lab via SSH. Credential verification failed. Stored password is invalid for current account state.'
SDDC Manager detects the password is stale but cannot update it because it cannot access the host. This is the chicken-and-egg problem of credential rotation in a locked state.
Step 3

Check SDDC Manager's failure notification. Navigate to Administration > Recent Tasks. Find the failed rotation task. Click it to view the detailed error log. Document: timestamp, error message, affected system, and the recommended recovery action.

Task details show: 'Rotation attempt failed for esxi-02.sddc.lab at 2026-04-17T14:22:00Z. Error: SSH connection authentication failed. Credential is locked or invalid on target system. Manual intervention required.'
Step 4

Initiate break-glass recovery. In SDDC Manager, navigate to Administration > Security > Break Glass. Select ESXi-02. Click 'Reset Credentials' (if available) or document the alternative: you will need to physically access the ESXi console or use a recovery password.

Break glass options are presented: (a) If a recovery/IPMI account exists, reset via out-of-band, (b) If vCenter has vMotion capability, migrate VMs and power-off the host for manual recovery, (c) Document that ESXi-02 requires manual password reset via the DC console.
This is why infrastructure should have out-of-band management (IPMI/iLO) — it breaks the circular dependency. In Holodeck (nested lab), out-of-band is not available, so use vCenter to gate the host into maintenance mode and migrate workloads.
Step 5

In vCenter, navigate to Hosts and Clusters. Right-click ESXi-02 > Enter Maintenance Mode (if VMs are running, vCenter will vMotion them to other hosts first). Once in maintenance mode, the host is safely isolated.

ESXi-02 shows 'Maintenance Mode' status in vCenter
Step 6

Now reset the ESXi root password manually. In the Holodeck environment (nested), this requires SSH access via the HoloRouter or using DCUI. For this lab, document the recovery step: 'In production, call data center staff to reset root password at the console (DCUI Alt-F2, then set password).' Alternatively, if you have DCUI/console access to the nested ESXi VM (via vCenter console), open it: vCenter > Hosts and Clusters > ESXi-02 > Click Console. Log in as root with the old password if it's not locked, or use DCUI (Ctrl-Alt-F2) to reset.

Validation Gate

Check: ESXi-02 is in Maintenance Mode. Failed rotation task is documented with error details. Recovery plan is articulated (manual password reset via console or out-of-band access).

Expected: Break-glass recovery procedure is documented and tested. Understanding of rotation failure modes is demonstrated.

Common Errors

Cannot SSH to ESXi to lock the account — SSH connection refused
Cause: SDDC Manager uses SSH keys (not passwords) to manage ESXi. Locking the password doesn't prevent key-based access.
Fix: This lab step is illustrative — in production, rotation failures happen due to network issues, service unavailability, or bugs, not account locks. Document the scenario conceptually instead: 'If ESXi-02 root password becomes invalid during rotation, the recovery is to use out-of-band (IPMI) or console access to reset it manually.'
Cannot enter Maintenance Mode because critical VMs are pinned to ESXi-02
Cause: SDDC Manager or NSX Manager VM is running on the host and has constraints that prevent vMotion
Fix: Don't use ESXi-01 (management host) for this test. Use ESXi-03 or ESXi-04 instead. If you must use a management host, skip the maintenance mode step and document recovery as requiring a coordinated service restart.

Task 5 Integrate external vault (HashiCorp Vault) and audit credential access

security

Modern enterprise compliance (SOC 2, ISO 27001) requires centralized secret management with audit trails. VCDX-level design means understanding how VCF credentials can be offloaded to external vaults while maintaining operational capability. This task demonstrates that integration model.

Step 1

In SDDC Manager, navigate to Administration > System Configuration > External Vault Integration. Review whether Vault integration is available in your VCF 9.0 version. (Note: This feature may be limited in some lab editions. If not available, document the expected behavior and skip to Step 3.)

External Vault Configuration page shows options to connect to: HashiCorp Vault, Azure Key Vault, or other OIDC-compatible vaults. If integration is disabled, note that requirement: 'VCF 9.0 Enterprise licensing required'. Delivered in VCF 9.1: external vault integration (HashiCorp Vault and other OIDC-compatible vaults) ships in the platform, so on a 9.1 environment this page is populated. Document the observed behavior for your version.
Step 2

If Vault integration is available, review the configuration steps (don't fully complete unless you have a live Vault instance available). Document what would be required: (a) Vault server IP/FQDN, (b) authentication method (AppRole, JWT, or TLS certificate), (c) KV v2 mount path for VCF secrets (e.g., /secret/vcf/), (d) network connectivity from SDDC Manager to Vault. Test connectivity: SDDC Manager > System Configuration > External Vault > Test Connection.

Configuration page shows required fields and expected connection flow. If connectivity test succeeds: 'Connection successful. Vault server reachable. Authenticating as AppRole role_id: [redacted]. Mount path verified: /secret/vcf/'.
Step 3

Even if Vault integration is not deployed in your lab, document the architecture: where credentials would be stored (Vault backend), how SDDC Manager would retrieve them (API call at rotation time), and the audit trail (Vault audit log shows every secret access). Create a design diagram in your lab notes: SDDC Manager <--> Vault <--> Audit Log.

Diagram and written explanation of external vault integration architecture
Step 4

Review SDDC Manager's local credential audit log. Navigate to Administration > Audit Logs. Filter for 'Credential' operations. You should see entries for: password rotations, credential reads (e.g., when SDDC Manager uses a password to authenticate to NSX), and rotation failures.

Audit log shows: 'Credential rotated: esxi-01 root (timestamp)', 'Credential accessed: vCenter admin for NSX connectivity validation (timestamp)', 'Credential rotation failed: vCenter SSO (timestamp, reason)'
In compliance audits, these logs prove who accessed which credentials and when. If a security incident occurs, you can trace all credential access.
Step 5

Export the credential audit log. In SDDC Manager, Audit Logs > Filter for past 7 days > Export CSV. Document the compliance findings: (a) How many times were credentials accessed? (b) Which accounts were rotated? (c) Were there any unauthorized access attempts? (d) Are there any gaps (e.g., accounts that were never rotated)?

Exported audit CSV with 10+ entries showing credential operations over the past week
Step 6

Write a brief compliance summary (1 paragraph) for a hypothetical security audit: 'Based on the credential audit trail from April 10-17, 2026: All managed accounts (4x ESXi root, vCenter SSO, NSX admin) were rotated successfully. No unauthorized access attempts detected. Service account credentials are scheduled for rotation weekly. Recommendation: Investigate any manual credential access outside of SDDC Manager automation.' Document any gaps you notice.

Audit summary document with findings and recommendations

Validation Gate

Check: External Vault integration reviewed (or documented as unavailable). Credential audit log exported for past 7 days. Compliance summary written with findings.

Expected: Understanding of enterprise credential architecture (local SDDC Manager + external Vault option) and audit trail capabilities demonstrated.

Common Errors

External Vault integration page is blank or shows 'Not Supported'
Cause: VCF 9.0 version does not include this feature in your lab edition, or licensing does not enable it
Fix: Document this as a limitation of the VCF 9.0 lab edition. Delivered in VCF 9.1: external vault integration is available, so repeat this step on a 9.1 environment if you have one. For 9.0 labs this is acceptable — focus on demonstrating understanding of the architecture and audit logging.
Audit log is empty or shows no credential operations
Cause: Audit logging may not be enabled by default in some lab configurations, or the filter is too restrictive
Fix: In SDDC Manager Administration > Audit Configuration, verify 'Credential Operations' logging is enabled. Check the date filter — you may have rotated credentials before the start of your date range. Manually rotate a credential (Task 3) and immediately check the audit log.
Vault connectivity test fails: 'Unable to reach Vault server'
Cause: Vault is not deployed in the lab, or network connectivity from SDDC Manager to Vault is blocked
Fix: This is expected in a lab without Vault. Document the architecture conceptually and skip the integration steps. Focus on audit logging (which is available locally).

Final Validation

You have demonstrated comprehensive credential lifecycle management in VCF 9.0: audited all managed accounts, configured rotation policies, executed manual rotations, recovered from failure scenarios, and reviewed enterprise vault integration. You understand the security, availability, and compliance implications of credential management at the VCDX architect level.

✓ Credential Inventory → All 6+ accounts (4x ESXi root, vCenter SSO, NSX admin, service accounts) documented with rotation history

✓ Rotation Policies → ESXi = 30 days, vCenter SSO = Manual, NSX = 45 days. Policies saved and scheduled task configured.

✓ Manual Rotation → Two successful rotations (ESXi-01 and vCenter SSO) with validation checks passed. New passwords functional.

✓ Break-Glass Recovery → Failure scenario simulated. Recovery procedure (console/DCUI reset) documented and practiced.

✓ Audit and Compliance → Credential audit log exported. 7-day compliance summary written with findings and recommendations.

Cleanup / Restore

Snapshot: vcp-admin-07-complete

• Exit ESXi-02 from Maintenance Mode: vCenter > Hosts and Clusters > ESXi-02 > Exit Maintenance Mode

• Document all rotated passwords in your secure password manager (or lab notebook for this lab environment)

• Revert any intentionally-modified policies (e.g., ESXi rotation back to 90 days if desired) to match your lab's baseline

• Take a post-lab snapshot for future reference: 'vcp-admin-07-complete — All rotations executed, audit trails captured'

Design Reflection (VCDX)

A VCDX panelist examining your credential management strategy would ask: How do you balance rotation frequency (security) with operational risk (failed rotations can break services)? Which accounts can you safely auto-rotate, and which require manual coordination? How do you integrate external vaults to comply with SOC 2 / ISO 27001 audit requirements? Why is vCenter SSO password rotation complex? What is the blast radius of a compromised ESXi root password vs a compromised vCenter SSO password? Be prepared to defend your rotation schedule with risk/benefit analysis, not just follow vendor defaults.

Requirements

  • All VCF-managed credentials must be rotatable (manual or automated) at least quarterly
  • Rotation operations must not disrupt service availability to management plane or workloads
  • Audit trail must be maintained for all credential access and rotations for SOC 2 / ISO 27001 compliance
  • Break-glass recovery procedure must exist for accounts that cannot be auto-rotated due to service dependencies

Constraints

  • vCenter SSO password is a multi-service dependency — changing it requires coordinated updates to SDDC Manager, NSX, vRealize, and other integrations
  • ESXi root password rotation requires network access (SSH) to each host — if a host is down, its password cannot be rotated until it comes back online
  • Automated rotation cannot proceed if any dependency service (vCenter, NSX, SDDC Manager) is offline — introduces operational coupling
  • Some legacy service accounts may have hardcoded passwords that cannot be auto-rotated — manual rotation required

Assumptions

  • SDDC Manager has network connectivity to all managed systems (ESXi hosts, vCenter, NSX) for rotation automation
  • All managed systems accept credential updates via secure channels (SSH for ESXi, HTTPS API for vCenter/NSX)
  • Operator has administrative credentials to SDDC Manager and understands the rotation sequence and recovery procedures
  • External vaults (Hashicorp Vault, Azure Key Vault) are optional; local SDDC Manager credential storage is sufficient for most deployments

Risks

  • Failed rotation mid-sequence leaves services in inconsistent state (one has old password, one has new) — IMPACT: authentication failures, MITIGATION: implement rotation validation checks and rollback procedures
  • Rotation policy too aggressive (e.g., daily rotation) increases chance of automation failure and service disruption — IMPACT: operational noise and false alarms, MITIGATION: use 30-90 day cycle with testing
  • Break-glass account unused for 12+ months becomes stale and unusable when needed in emergency — IMPACT: cannot access system in incident, MITIGATION: test break-glass quarterly
  • Compromised SDDC Manager means attacker has access to all stored credentials (ESXi, vCenter, NSX) — IMPACT: lateral movement to entire infrastructure, MITIGATION: use external vault as second line of defense; isolate SDDC Manager network access

Self-Assessment Discussion Prompts

  1. Why is vCenter SSO password rotation set to 'Manual only' in the default configuration? What would need to change to make it safe to auto-rotate?
  2. You discover that automated password rotation failed for ESXi-02 root account. What is the first diagnostic step? (Answer: Check if ESXi-02 is reachable from SDDC Manager via SSH. If unreachable, the host may be offline or network partitioned.)
  3. Compare rotation policies for ESXi root (physical host) vs vCenter SSO (shared service account). Which has a tighter tolerance for rotation failures? Why?
  4. A security audit requires you to rotate all passwords to 15-day cycles (from 30-day). What are the operational risks? What changes would you recommend to make 15-day rotation safe?
  5. External vault integration is expensive and complex. Under what circumstances is it worth the investment? (Answer: When you have multiple VCF instances, need to comply with SOC 2, or have a centralized security team managing secrets across multiple products.)
  6. Design a credential rotation schedule for a production VCF environment with 3 workload domains. Which credentials should be rotated together? Which should be independent?

Extensions

Design and Test a Full Credential Rotation Window

Simulate a production maintenance window where you rotate all credentials (ESXi, vCenter, NSX, service accounts) in sequence. Measure the total time, identify dependencies, and document the rollback procedure if any step fails. Create a runbook for the operations team.

harder

Integrate HashiCorp Vault and Migrate All Credentials

Deploy a HashiCorp Vault instance in your lab (or use Vault Dev mode). Configure SDDC Manager to store all credentials in Vault instead of locally. Verify that rotations are now retrieved from Vault, and audit logs show Vault API calls. This is the enterprise-grade architecture.

harder

Credential Compliance Audit: SOC 2 Readiness

Using the credential audit logs from this lab, prepare a SOC 2 Type II report section: 'Credential Management Controls'. Document: (a) Who can access credentials (RBAC), (b) Rotation frequency and method, (c) Audit trail retention, (d) Break-glass procedures, (e) Encryption in transit and at rest. Compare your implementation to SOC 2 CC-6 and CC-7 controls.

harder

VCF 5.2 vs VCF 9.0 Credential Architecture Comparison

If you have access to a VCF 5.2 lab, repeat the credential audit (Task 1) and rotation (Task 3) in VCF 5.2. Document differences: UI differences, rotation automation maturity, external vault support, audit trail capabilities. Write a 2-page comparison addressing: which version has better credential lifecycle automation, and what was added in VCF 9.0.

same

References

Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.