Deploy vCenter in VCF 9.0 with Identity Broker Integration

VCF 9.0Advancedadminarchitectvcdx⏱ 120 min

VCF 9.0 uses integrated Identity Broker for federated authentication. vCenter 8.0 in VCF 9.0 requires SAML 2.0 configuration via vSphere Trust Authority or manual configuration. NSX 9.0 uses centralized authentication via Identity Broker.

Objectives

Deploy vCenter Server 8.0 in VCF 9.0 management domain with High Availability (vCenter HA) configuration
Execute vCenter deployment via VCF Operations Installer workflow and validate post-deployment health
Configure Identity Broker federation with external OIDC/SAML IdP (Okta, Entra ID, or AD FS)
Map IdP groups to VCF-native roles (Fleet Admin, Instance Admin, Private Cloud Admin, Read-Only) with SAML assertions
Validate SSO authentication and role-based access control (RBAC) enforcement across vCenter, NSX, and VCF Operations

Prerequisites

VCF 9.0 management domain fully deployed with Fleet Manager and VCF Operations running (from vcp-admin-03 or holodeck-02). Identity Broker already installed as part of VCF 9.0 management domain bring-up. External OIDC/SAML IdP configured and accessible from lab network (Okta trial account, Entra ID tenant, or on-premises AD FS). vCenter OVA 8.0 Update 2+ staged in datastore.

Prior labs: vcp-admin-03 (VCF 9.0 deployment and Fleet Manager understanding), holodeck-02 (if using nested Holodeck environment)

Required skills:

VCF 9.0 architecture (management domain, Fleet Manager, VCF Operations)
vCenter Server deployment and configuration
SAML 2.0 and OIDC authentication concepts
AD/LDAP directory structure and group membership
REST API navigation for vCenter and Identity Broker

Lab Environment

VCF 9.0 management domain with 4x nested ESXi hosts, management cluster, vSAN. Post-lab will have: (1) vCenter Server 8.0 deployed with HA (2 additional vCenter nodes), (2) Identity Broker integrated with external OIDC/SAML IdP, (3) NSX Manager 9.0 integrated with Identity Broker, (4) VCF Operations authenticated via Identity Broker. All components communicate over management network (10.2.0.0/20).

graph TB
  IdP[External IdP: Okta/Entra/AD FS] -->|OIDC/SAML| IB[Identity Broker]
  IB -->|SAML Assertions| VC[vCenter HA Primary]
  IB -->|SAML Assertions| VCR1[vCenter HA Replica 1]
  IB -->|SAML Assertions| VCR2[vCenter HA Replica 2]
  IB -->|OIDC| NSX[NSX Manager 9.0]
  IB -->|OIDC| OPS[VCF Operations]
  VC -->|Cluster| ESXi1[ESXi-01]
  VC -->|Cluster| ESXi2[ESXi-02]
  VC -->|Cluster| ESXi3[ESXi-03]
  VC -->|Cluster| ESXi4[ESXi-04]

IP Addressing

Network	Purpose	VLAN
`10.2.0.0/20`	VCF 9.0 management network (Fleet Manager, VCF Operations, vCenter, NSX, Identity Broker)	VLAN 1645
`10.3.1.0/24`	vCenter HA failover cluster (management network for HA communication between vCenter nodes)	VLAN 1645

Credentials

System	Username	Password
VCF 9.0 Fleet Manager	`admin@local`	From VCF 9.0 deployment (vcp-admin-03)
VCF Operations	`admin@local`	Federated via Identity Broker (post-configuration)
vCenter Server 8.0	`administrator@vsphere.local`	Set during vCenter OVA deployment, then federated
Identity Broker	`admin@local`	From VCF 9.0 bring-up
External IdP (Okta/Entra/AD FS)	`test-user@company.com`	Configured in external IdP system

Tasks

Task 1 Deploy vCenter Server 8.0 via VCF Operations OVA Workflow

Availability

In VCF 5.2, vCenter was deployed as part of the Cloud Builder orchestrated bring-up. In VCF 9.0, vCenter is a managed component that can be deployed post-management-domain via VCF Operations. This task teaches you the VCF 9.0 Day 1.5 operational workflow where vCenter is treated as an upgradeable, replaceable component (not baked into the bring-up).

Step 1

From VCF Operations UI, navigate to Infrastructure > vCenter. Click 'Deploy vCenter' or similar button (exact label depends on VCF 9.0.x version). The UI should present a form to configure vCenter deployment parameters.

vCenter deployment form visible with fields for: vCenter FQDN, IP address, resource sizing, datastore selection, network port group selection.

Step 2

Fill in the vCenter deployment form: (a) FQDN: vcenter.vcf.sddc.lab, (b) Management IP: 10.2.0.6 (assign from management network range), (c) Resource sizing: standard 12 vCPU, 32 GB RAM minimum (for HA failover, each replica needs equal resources), (d) Datastore: select management cluster's vSAN datastore, (e) Port group: select management network port group (should already exist from management domain bring-up), (f) Root password: complex password (this is the initial vCenter local root, will be replaced by federated auth post-deployment).

Form fully populated with valid values. No validation errors displayed.

vCenter 8.0 on VCF 9.0 requires at least 32 GB RAM. Earlier vCenter versions (7.0) required 16 GB. If your nested lab has constrained resources, you may need to accept a degraded configuration (increased memory swap) or skip the vCenter HA replica deployment until resources are available.

Step 3

Configure vCenter HA: After the main configuration, look for an optional section 'Configure High Availability' or similar. Set the HA replica count to 2 (meaning 1 primary + 2 replicas = 3 total vCenter nodes). Specify IP addresses for replicas: 10.2.0.7 and 10.2.0.8. Set the HA failover FQDN to vcenter-ha.vcf.sddc.lab (this is the floating IP/hostname that applications use; it fails over between primary and replicas).

HA configuration section shows: Primary IP 10.2.0.6, Replica 1 IP 10.2.0.7, Replica 2 IP 10.2.0.8, HA cluster FQDN vcenter-ha.vcf.sddc.lab.

vCenter HA uses a passive replication model: the primary handles all traffic, replicas stay in sync via continuous replication. If the primary fails, one replica is promoted via a quorum-based election. This is more sophisticated than vSphere HA for VMs; it requires manual configuration here in VCF 9.0.

Step 4

Select the management cluster where vCenter will run: vCenter VMs will be created on the 4 ESXi hosts in the management cluster (specifically, the HA primary and replicas will be distributed across hosts). Click 'Deploy' or 'Submit' and wait for the deployment to begin.

VCF Operations shows a progress indicator for vCenter deployment. Deployment should take 15-30 minutes.

Step 5

Monitor the deployment progress. You can check: (a) VCF Operations UI progress bar, (b) vSphere Client to see vCenter OVA being imported and VMs created (look for VM names like 'vcenter-primary', 'vcenter-replica-1', 'vcenter-replica-2'), (c) System logs via SSH to vCenter VMs once they are deployed (to verify services starting correctly).

All three vCenter VMs visible in vSphere Client. Each shows 'powered on' status. IP addresses assigned on management network.

If deployment stalls at the 'Importing OVA' step for > 10 minutes, the datastore may be full or the network transfer is slow. Check datastore free space and consider using a local datastore copy of the vCenter OVA instead of downloading it.

Step 6

Wait for vCenter services to initialize. Once all three VMs are deployed, vCenter services will start. This can take 10-15 minutes. You can SSH to the primary vCenter VM and check: systemctl status vmware-vpxd (vCenter main service) and systemctl status vmware-vpostgres (vCenter database). Wait for both to show 'active (running)'.

SSH to vCenter successful. Both vmware-vpxd and vmware-vpostgres services show 'active (running)' status.

Step 7

Verify vCenter HA synchronization: From the primary vCenter VM, check the HA status: systemctl status vsan-health (vCenter uses VSAN storage for HA sync) and verify replication to replicas: Check /var/log/vmware/vpxd/vpxd.log for lines containing 'replica' and 'replication successful'. Alternatively, use the vCenter Client once it is accessible to view the HA status under Administration > System Configuration > HA (if available in UI).

vCenter HA replicas are replicating data from primary. Logs show successful replication entries.

Validation Gate

Check: vCenter UI accessible at https://vcenter-ha.vcf.sddc.lab. Three vCenter VMs visible in vSphere Client. vCenter HA primary and replicas show replicated status.

Expected: vCenter 8.0 with HA fully deployed and ready for configuration

Common Errors

vCenter OVA import fails with 'Insufficient space on datastore'

Cause: Management cluster datastore full. vCenter OVA is ~7-8 GB; HA replicas require additional space.

Fix: Check datastore free space: esxcli storage filesystem list on physical ESXi. Delete old snapshots or unused VMs. Minimum 50 GB free required for vCenter primary + 2 replicas. If using nested labs, verify nested ESXi hosts have sufficient disk allocation.

📋 KB: VCF 9.0 community: vCenter deployment datastore exhaustion

vCenter VMs created but services don't start (vmware-vpxd shows 'inactive')

Cause: vCenter database (vPostgres) failed to initialize. Usually due to insufficient RAM or storage I/O contention.

Fix: Check vCenter VM memory allocation. Each vCenter node needs 32 GB minimum. If memory is constrained, reduce other lab VMs temporarily. Check /var/log/vmware/vpostgres/vpostgres.log for startup errors and address missing dependencies.

vCenter replicas show replication status 'Failed' or 'Degraded'

Cause: Network latency or packet loss between primary and replicas. vCenter HA is sensitive to network quality.

Fix: Check network connectivity: ping between primary and replica IPs. Check for packet loss: ping -c 100. If latency > 100ms or packet loss > 1%, investigate network configuration (VLAN, MTU, switch port configuration). Restart vCenter HA sync: systemctl restart vmware-vsan-health on replicas.

Task 2 Configure Identity Broker Federation with External OIDC/SAML IdP

Security

vCenter 8.0 in VCF 9.0 is designed to use federated authentication via SAML. Instead of managing local accounts, you delegate to an external identity provider (IdP). This is the modern authentication paradigm for enterprise cloud platforms. VCDX panelists will probe your understanding of SAML assertion flows and the security implications.

Step 1

Prepare your external IdP (Okta trial, Entra ID, or on-premises AD FS). You will need: (a) IdP OIDC/SAML metadata URL (e.g., https://dev-12345678.okta.com/.well-known/oidc/metadata or https://sts.windows.net/<tenant-id>/federationmetadata/2007-06/federationmetadata.xml for Entra), (b) OAuth2 / SAML application configured in the IdP with Redirect URI pointing to vCenter or VCF Operations (e.g., https://vcenter.vcf.sddc.lab/ui/saml/sso), (c) At least 3 test users created in IdP with group memberships (e.g., groups: 'vcf-admins', 'vcf-readers', 'vcf-developers').

IdP application configured and metadata URL available. Test users created with group memberships.

Step 2

From Identity Broker UI, navigate to Authentication > Identity Providers. Click 'Add IdP' or 'Configure Federation'. Choose your IdP type (OIDC for Okta/Entra, SAML for AD FS). Paste the IdP metadata URL or manually configure the endpoints. Identity Broker will fetch the public key and trust certificate from the IdP metadata.

Identity Broker shows IdP configuration form with fields for: IdP name, metadata URL, client ID (if OIDC), client secret (if OIDC), SAML certificate, assertion consumer service (ACS) URL.

Client secrets should NOT be stored in plain text in configuration files. Use Identity Broker's secure credential storage or a secrets management system. Community thread 'Identity Broker client secret exposure' documents a security incident where secrets were inadvertently logged.

Step 3

Configure the SAML/OIDC assertion mapping: In Identity Broker, define how IdP group memberships map to vCenter/VCF roles. Create mappings: (a) IdP group 'vcf-admins' -> VCF role 'Administrator' (maps to vCenter 'Administrator' role), (b) IdP group 'vcf-readers' -> VCF role 'ReadOnly' (maps to vCenter 'Read-Only' role), (c) IdP group 'vcf-developers' -> VCF role 'PowerUser' (custom role, define permissions). Save the mappings.

Identity Broker shows group-to-role mappings. Each mapping displays source group, target role, and any attribute transformations applied.

SAML assertions contain the user's group membership as an XML attribute (e.g., <saml:Attribute Name='memberOf'><saml:AttributeValue>vcf-admins</saml:AttributeValue></saml:Attribute>). Identity Broker parses this and enforces the role mapping on every login.

Step 4

Register vCenter as a relying party in Identity Broker: Navigate to Applications > Register New Application. Select 'vCenter Server 8.0'. Enter vCenter details: (a) vCenter FQDN: vcenter-ha.vcf.sddc.lab, (b) Assertion Consumer Service (ACS) URL: https://vcenter-ha.vcf.sddc.lab/ui/saml/sso, (c) Entity ID: https://vcenter-ha.vcf.sddc.lab (can be same as FQDN), (d) Certificate: use Identity Broker's auto-generated certificate or upload a custom cert. Save and note the SAML metadata URL that Identity Broker generates (you will need this for vCenter configuration).

Identity Broker generates vCenter SAML metadata URL (e.g., https://identity-broker.vcf.sddc.lab/saml/metadata). Download or copy this URL.

Step 5

Configure SAML in vCenter: Access the vCenter Server Appliance Management Interface (VAMI) at https://vcenter-ha.vcf.sddc.lab:5480. Log in with the temporary root credentials set during vCenter deployment. Navigate to Administration > Single Sign-On > Configuration. Enable SAML SSO and paste the Identity Broker SAML metadata URL. vCenter will fetch the metadata and establish trust with Identity Broker.

VAMI shows SAML SSO enabled with Identity Broker certificate loaded. No SSL/certificate trust errors displayed.

vCenter and Identity Broker must trust each other's certificates. If you are using self-signed certificates in the lab, ensure both trust the other's CA or certificate. Certificate validation failures will prevent SAML login.

Step 6

Test SAML login to vCenter: Open a private browser window and navigate to https://vcenter-ha.vcf.sddc.lab/ui. You should be redirected to Identity Broker's login page. Enter a test user from your IdP (e.g., test-user@company.com). After authentication at the IdP, you should be redirected back to vCenter and logged in as that user. Note the user's role in the vCenter UI — it should match the group mapping you configured (e.g., if user is in 'vcf-admins' group, they should see 'Administrator' role).

SAML login redirects to IdP, then back to vCenter. User logged in with correct role. vCenter UI shows user's name and role on the welcome page.

Validation Gate

Check: Identity Broker configured with external IdP trust. vCenter SAML enabled. SAML login tested with at least one federated user. User's role matches group mapping.

Expected: vCenter 8.0 fully integrated with federated authentication via Identity Broker

Common Errors

SAML login fails with 'Invalid SAML Response' or 'Assertion expired'

Cause: Clock skew between Identity Broker and vCenter, or SAML assertion attribute names don't match vCenter's expectation.

Fix: Ensure Identity Broker and vCenter system clocks are synchronized (NTP configured correctly). Check Identity Broker logs for the exact assertion error. Verify the assertion's 'Groups' or 'memberOf' attribute name matches the mapping configuration in Identity Broker.

SAML login redirects to IdP, but login at IdP fails

Cause: IdP application is not properly configured with the correct vCenter Redirect URI, or CORS is blocking the request.

Fix: In the external IdP, verify the Redirect URI (ACS URL) exactly matches what vCenter is sending (check browser network tab in Developer Tools). Common issue: IdP expects https://vcenter.lab/ but vCenter is sending https://vcenter-ha.vcf.sddc.lab/. Align the FQDNs.

User logs in successfully but gets 'Access Denied' or 'Insufficient Permissions' in vCenter

Cause: User's group membership in IdP is not being transmitted in SAML assertion, or the group name in the assertion doesn't match the mapping in Identity Broker.

Fix: Check IdP's assertion output (use browser developer tools or IdP audit logs). Verify the 'Groups' or 'memberOf' attribute is included and matches the mapping. If not, configure the IdP application to include the attribute in the assertion.

Task 3 Configure Role-Based Access Control (RBAC) Mapping in vCenter and NSX

Security

RBAC is the enforcement mechanism for federated identity. Once a user authenticates via SAML, vCenter and NSX must know what they are allowed to do. This task teaches you how to align IdP group structure with VCF's built-in and custom roles.

Step 1

In vCenter, create a custom role to supplement the built-in roles. Navigate to Administration > System Configuration > Roles. Click 'Add Role' (or similar). Create a role 'VCF-PowerUser' with permissions: Host.Config., VM.Config., but exclude Datastore.Delete and Storage.Delete (so power users cannot destroy infrastructure). Save the role.

vCenter shows new custom role 'VCF-PowerUser' in the Roles list with the specified permissions.

Step 2

Map IdP groups to vCenter roles: Navigate to Administration > Access Control > Users and Groups. For each test user from your IdP, add them to a vCenter global role. However, vCenter 8.0 with SAML typically handles this via group assignment at login (SAML assertion contains group membership). Alternative: navigate to Administration > System Configuration > Permissions and add a group-level permission. For example: Group 'vcf-admins' (from IdP) -> vCenter role 'Administrator' on 'Root' object (applies to entire vCenter).

vCenter Permissions page shows group-level role assignments. Groups from SAML IdP are listed.

Step 3

Repeat RBAC configuration for NSX Manager. From NSX Manager UI, navigate to System > Roles. NSX 9.0 in VCF 9.0 can delegate authentication to Identity Broker via OIDC. Configure NSX to use Identity Broker as its authentication provider (if not already done during NSX bring-up). Map IdP groups to NSX roles: (a) 'vcf-admins' -> NSX role 'Administrator', (b) 'vcf-readers' -> NSX role 'Auditor', (c) 'vcf-developers' -> NSX role 'Network Admin' (custom, with limited permissions).

NSX Manager shows configured roles with group mappings. Groups can be local NSX groups or LDAP groups synced from IdP.

Step 4

Configure VCF Operations for federated access: VCF Operations (Fleet Manager's management plane) also uses Identity Broker for authentication. Navigate to VCF Operations Administration > Access Control. Verify Identity Broker is configured as the authentication provider. Ensure the same group-to-role mappings exist here: 'vcf-admins' -> 'Fleet Admin', 'vcf-readers' -> 'Read-Only', 'vcf-developers' -> 'Instance Admin' (with limited scope).

VCF Operations shows group-to-role mappings identical to or consistent with vCenter and NSX configurations.

Step 5

Test RBAC enforcement with three different test users: (a) Test user in 'vcf-admins' group: should see full administrative controls in vCenter, NSX, and VCF Operations. (b) Test user in 'vcf-readers' group: should see read-only interfaces, no modification buttons. (c) Test user in 'vcf-developers' group: should see limited write permissions (e.g., can create VMs but not delete datastores). Log in as each user and verify permissions are enforced.

Three SAML logins with different users, each showing appropriate role-based permissions (admin, read-only, developer).

Step 6

Test a cross-VCF role escalation scenario: Log in to vCenter as a 'vcf-readers' user (read-only), then attempt to: (a) create a new VM (should be denied), (b) change NSX firewall rules (should be denied), (c) upgrade VCF Operations (should be denied). Verify that permissions are consistently enforced across all three platforms even though they trust Identity Broker for authentication.

All three denial scenarios occur with appropriate error messages (e.g., 'You do not have permission to perform this action').

Validation Gate

Check: RBAC roles configured in vCenter, NSX, and VCF Operations. Group-to-role mappings match across all three. Three test users log in successfully and see appropriate role-based UI restrictions.

Expected: Federated identity is fully integrated with RBAC across the entire VCF stack

Common Errors

User logs in successfully but sees 'No objects visible' or empty inventory

Cause: vCenter or NSX permissions are not assigned to the user's group. The user authenticated successfully but has no permissions.

Fix: Verify the user's IdP group membership. In vCenter/NSX, ensure that group is assigned at least View permissions on the root object. Check the Permissions page to see all group assignments.

User logs in to vCenter but NSX still shows 'Unauthorized' or empty inventory

Cause: NSX is not using the same Identity Broker instance, or NSX group mappings are not configured.

Fix: Verify NSX is configured to use Identity Broker for authentication (NSX > System > Authentication Providers). Ensure the user's group is mapped to an NSX role. If NSX is using local LDAP instead of IdP, group memberships may not sync automatically.

Task 4 Validate Multi-Platform SSO and Test Failover Scenarios

Recoverability

In production, Identity Broker is a critical component. If it fails, users cannot log in. Similarly, if vCenter HA primary fails, users must be able to reach the replicas seamlessly. This task tests both authentication failover and vCenter HA failover to ensure production readiness.

Step 1

Validate SSO across multiple platforms: Log in to vCenter with a federated user, then open a new tab and navigate to NSX Manager and VCF Operations. You should NOT be prompted to log in again (because all three platforms trust the same Identity Broker and your browser has cached the SAML session). Confirm that the same username appears in all three consoles, and your role is consistent.

Seamless SSO across vCenter, NSX, and VCF Operations. Same user logged in to all three without re-authentication.

Step 2

Test vCenter HA failover: Ensure the vCenter primary is running and all replicas are synced. From the vSphere Client managing the management cluster, gracefully power off the vCenter primary VM (vcenter-primary). Wait 2-3 minutes for the HA quorum to detect the primary is down and promote a replica to primary.

One vCenter replica is promoted to primary. The HA cluster resumes normal operation. The floating HA FQDN (vcenter-ha.vcf.sddc.lab) should still be reachable and route to the new primary.

Step 3

Attempt to log in to vCenter during/after failover: Navigate to https://vcenter-ha.vcf.sddc.lab/ui during the failover (either while the old primary is shutting down or while the new primary is being promoted). You may experience a brief connection timeout (30-90 seconds), but login should succeed once the replica becomes the new primary. Verify that your SAML session either persists (if cached) or re-authenticates seamlessly.

Step 4

Simulate Identity Broker unavailability: From the Identity Broker VM, temporarily shut down the OIDC/SAML service: systemctl stop vcf-identity-broker (or equivalent for your IdP if external). Attempt to log in to vCenter / NSX / VCF Operations. All login attempts should fail with an error like 'Cannot contact Identity Provider' or 'SAML IdP unavailable'.

Login fails with clear error message indicating Identity Broker is unreachable. Administrators are prompted to use break-glass account (see next step).

Step 5

Test break-glass access (emergency local account): VCF 9.0 provides a break-glass local account for scenarios when Identity Broker is down. Navigate to vCenter login page. Look for an option like 'Use local account' or 'Break-glass login'. Enter the local administrator@vsphere.local account (created during vCenter OVA deployment) and the temporary password set at deploy time. You should be able to log in without Identity Broker.

Break-glass local account login succeeds when Identity Broker is unavailable. vCenter is accessible via local admin.

Step 6

Restart Identity Broker and verify restoration: systemctl start vcf-identity-broker. Wait for the service to initialize (2-5 minutes). Attempt to log in again with a federated user. Login should succeed. Verify all three platforms (vCenter, NSX, VCF Operations) are accessible again with SAML authentication.

All federated logins succeed after Identity Broker is restarted. No persistent disruption to service.

Validation Gate

Check: SSO works across vCenter, NSX, and VCF Operations with single login. vCenter HA failover succeeds and login works during/after failover. Identity Broker outage is handled gracefully with break-glass account. Service is restored after Identity Broker restart.

Expected: Full multi-platform SSO with failover resilience verified

Common Errors

During vCenter HA failover, login fails with 'Certificate Error' or 'Invalid FQDN'

Cause: The new vCenter primary has a different IP than the old primary, but the HA floating IP/FQDN hasn't updated correctly. Browser may be caching the old IP.

Fix: Clear browser cache and cookies for vcenter-ha.vcf.sddc.lab. Verify the HA floating IP is correctly mapped in DNS or hosts file. On the new primary vCenter, check that the HA configuration is correct: /etc/vmware/vpxd/vcenterserver.conf should show the correct node role.

Break-glass account doesn't work (password incorrect or account disabled)

Cause: Break-glass account was not created during vCenter OVA deployment, or password was never documented.

Fix: Re-create the break-glass account via SSH to vCenter primary: /usr/lib/vmware-vmafd/bin/vdcadmintool user-create. Set a new password for administrator@vsphere.local. Document it securely.

Task 5 Implement Multi-Tenancy Access Control with Custom Roles

Security

Advanced scenario: Some organizations want to delegate management of specific workload domains or resource pools to different teams via federated identity. This task teaches you how to create a multi-tenant RBAC model where Team A can only manage their workload domain and Team B can only manage theirs, all authenticated via the same external IdP.

Step 1

Create two IdP groups in your external IdP (if not already done): 'team-a-admins' and 'team-b-admins'. Add test users to each group (e.g., user1@company.com in team-a-admins, user2@company.com in team-b-admins).

Two groups created in IdP with test users assigned to each.

Step 2

In vCenter, create two custom roles for tenant isolation: (a) 'Tenant-A-Admin': permissions to view and manage VMs in 'Folder-A' only (create a folder structure in vCenter and assign permissions). Limited to VM.Config., not Datastore. or Host.*. (b) 'Tenant-B-Admin': similar permissions but scoped to 'Folder-B'. Create the folders if they don't exist: vCenter > VMs and Templates > Right-click > New Folder > 'Tenant-A', 'Tenant-B'.

Two vCenter folders created ('Tenant-A', 'Tenant-B') and two custom roles defined with appropriate permission scopes.

Step 3

Assign vCenter permissions: Navigate to Administration > Permissions. For each group from IdP, assign the appropriate tenant role: (a) Group 'team-a-admins' -> Role 'Tenant-A-Admin' on object 'Folder-A' (not root), (b) Group 'team-b-admins' -> Role 'Tenant-B-Admin' on object 'Folder-B'. This ensures each team can only manage their assigned folder.

vCenter Permissions page shows two group-to-role assignments, each scoped to a specific folder.

Step 4

Test tenant isolation: Log in to vCenter as user1@company.com (from team-a-admins). Verify: (a) User can see and manage VMs in Folder-A, (b) User CANNOT see or access Folder-B (should show 'No access' or empty inventory for Folder-B), (c) User CANNOT perform host-level operations (should see 'insufficient permissions' if attempting to reboot a host). Log out and repeat with user2@company.com for Folder-B.

Team A user sees only Folder-A in inventory. Team B user sees only Folder-B. Cross-tenant access is denied.

Step 5

Implement the same multi-tenancy model in NSX Manager: Create two NSX security groups (team-a-vms, team-b-vms) with logical segmentation policies. Map IdP groups to NSX roles with tenant-scoped permissions. This ensures network isolation aligns with VM isolation. Test that team-a-admins can modify network policies for team-a-vms but not team-b-vms.

NSX shows two security groups and two role assignments scoped to each group. Cross-tenant NSX access denied.

Step 6

Document the multi-tenant architecture: Create a diagram showing: (a) External IdP with three group hierarchies (admins, team-a, team-b), (b) Identity Broker mapping groups to VCF roles, (c) vCenter and NSX implementing object-level RBAC per tenant. Annotate the critical access control points: 'Where does tenant A's permission end and tenant B's begin?' Document any implicit trust assumptions (e.g., 'Both teams trust the same IdP instance and the identity of users in it').

Architecture diagram with explicit multi-tenant boundaries and RBAC enforcement points documented.

Validation Gate

Check: Two IdP groups created with test users. Two vCenter folders created with tenant-scoped roles. Two NSX security groups created with tenant-scoped policies. Cross-tenant access successfully denied for both teams.

Expected: Multi-tenant access control model fully implemented and tested

Common Errors

User from team-a-admins can still see Folder-B in vCenter inventory (should only see Folder-A)

Cause: Permission assignment was applied to root object instead of the specific folder. Root permissions override folder-level permissions.

Fix: Navigate to Permissions. Verify the 'Propagate' setting is DISABLED for the tenant role permissions. Re-assign permissions explicitly to the tenant folder, not root.

Final Validation

vCenter Server 8.0 deployed with HA (3 nodes) in VCF 9.0 management domain. Identity Broker federated with external OIDC/SAML IdP. Role-based access control enforced across vCenter, NSX, and VCF Operations. Multi-platform SSO validated. Failover scenarios tested (vCenter HA and Identity Broker outage). Multi-tenant isolation implemented and verified.

✓ vCenter 8.0 deployed with 3 HA nodes (primary + 2 replicas) → All three VMs running, HA replication active, HA cluster healthy

✓ Identity Broker configured with external IdP trust (SAML/OIDC) → IdP metadata loaded, group-to-role mappings defined

✓ SAML login tested in vCenter, NSX, and VCF Operations → Three federated users log in successfully with correct role enforcement

✓ vCenter HA failover tested (graceful shutdown of primary) → Replica promoted to primary, login succeeds during/after failover

✓ Identity Broker outage scenario tested (service stopped, login denied, break-glass used) → Break-glass account allows local login when IdP unavailable

✓ Multi-tenant isolation implemented and tested → Two teams can only access their assigned folders/resources in vCenter and NSX

Cleanup / Restore

Snapshot: vcp-admin-04-complete

• Take a snapshot of the vCenter primary and replicas in a stable state for future reference

• Document the vCenter HA floating IP/FQDN and all three node IPs in your lab notebook

• Document Identity Broker configuration details (IdP type, group mappings, SAML certificate details) for future troubleshooting

• Preserve the break-glass local account password in a secure location (consider using a password manager)

• Keep a copy of your multi-tenant RBAC diagram and folder structure for reference

Design Reflection (VCDX)

A VCDX architect designing vCenter deployment in VCF 9.0 must understand that authentication is no longer a standalone vCenter concern—it is part of the larger VCF identity ecosystem. The shift from local vCenter accounts to federated authentication via Identity Broker has profound implications: (1) vCenter is now stateless with respect to identity (IdP is the source of truth), (2) User provisioning is decoupled from vCenter (admins manage groups in the IdP, not in vCenter), (3) Compliance and audit trails flow through Identity Broker and the external IdP, not vCenter logs alone.
In VCDX design scenarios, be prepared to explain: Why would you choose OIDC vs SAML? How does Identity Broker scale if you have 100,000 users? What happens if your IdP is compromised (attacker gains ability to issue SAML assertions)? How do you handle emergency access when IdP is down? These are architect-level concerns, not operator concerns.

Requirements

vCenter 8.0 must be deployed with HA (minimum 3 nodes: 1 primary, 2 replicas) in VCF 9.0 management domain
vCenter must be integrated with Identity Broker for SAML 2.0 authentication
External OIDC or SAML IdP (Okta, Entra ID, AD FS) must be configured and accessible
IdP group memberships must map to VCF roles (Admin, Read-Only, PowerUser, etc.) via SAML assertions
RBAC must be enforced consistently across vCenter, NSX Manager, and VCF Operations
Multi-platform SSO must work seamlessly (user logs in once, authenticated across all three consoles)
Failover scenarios must be tested: vCenter HA failover and Identity Broker outage with break-glass recovery

Constraints

vCenter 8.0 requires 32 GB RAM minimum per node (HA with 3 nodes = 96 GB total); nested labs may have resource constraints
vCenter OVA is ~7-8 GB; deploying 3 nodes requires 50+ GB datastore space
vCenter HA requires network latency < 100ms and < 1% packet loss between nodes; high-latency networks may fail HA quorum
SAML assertion size is limited (~64 KB); large group lists in IdP may cause assertion overflow
External IdP must be reachable from VCF environment (firewall, network routing must allow outbound HTTPS to IdP)
Self-signed certificates in lab environments require manual trust configuration; production requires proper CA-signed certificates
vCenter and Identity Broker clocks must be synchronized (NTP) with skew < 5 minutes

Assumptions

VCF 9.0 management domain is already deployed and operational (from vcp-admin-03)
External IdP (Okta trial, Entra ID tenant, or AD FS) is configured and accessible
At least 3 test users are created in IdP with group memberships
Network connectivity exists between lab and external IdP (or IdP is on-prem and lab has access)
vCenter OVA 8.0 Update 2+ is staged in management cluster datastore
Administrator has ability to modify DNS or hosts file for vCenter FQDNs and HA floating IP
Identity Broker is already part of VCF 9.0 bring-up (not deployed separately)

Risks

vCenter HA failover failure due to network issues or split-brain quorum loss — IMPACT: vCenter unavailable until manual recovery, MITIGATION: pre-validate network quality, implement monitoring for HA quorum status
Identity Broker compromise or token forgery allows unauthorized access — IMPACT: all federated systems are compromised, MITIGATION: implement certificate pinning, use short-lived tokens, audit token issuance logs
SAML assertion contains sensitive group information (may reveal organizational structure) — IMPACT: information disclosure, MITIGATION: use minimal group scope in assertions, implement attribute transformation to abstract group names
Break-glass account compromised (if password is weak or disclosed) — IMPACT: unauthorized administrative access, MITIGATION: strong password, account locked/disabled after break-glass use, audit all break-glass logins
vCenter replica synchronization failure causes data loss — IMPACT: user sessions and configuration lost, MITIGATION: monitor replication health continuously, perform periodic backups independent of HA

Self-Assessment Discussion Prompts

Why does vCenter 8.0 in VCF 9.0 require SAML-based federated authentication instead of supporting local accounts as the primary mechanism?
In a multi-tenant environment, why is Identity Broker a potential single point of failure? How would you design IdP redundancy (e.g., multiple IdP instances)?
The break-glass local account is a security trade-off: access without IdP during outages, but a potential backdoor if compromised. How would you justify this trade-off to security auditors?
If your external IdP (Okta/Entra) is in the cloud and your VCF is on-premises, how does network latency or IdP outages affect vCenter availability?
How would you handle SAML assertion attribute mismatches between IdP and vCenter (e.g., IdP sends 'memberOf' but vCenter expects 'Groups')?
In a disaster recovery scenario, if your primary site's IdP is down but your secondary site (with vCenter HA replica) is up, how do you maintain authentication continuity?

Extensions

Implement Passwordless Authentication with FIDO2

Configure Identity Broker to support FIDO2 hardware security keys (e.g., YubiKey) as an alternative to password-based OIDC. Test passwordless login to vCenter using a FIDO2 key. This simulates modern zero-trust authentication patterns and is increasingly required by security frameworks (FedRAMP, SOC 2).

harder

Configure vCenter Backup and Restore via VCF Operations

While vCenter HA provides replication-based recovery, production requires backup snapshots. Configure vCenter backup via VCF Operations (if available) or VCSA Backup Scheduler. Test restore from a backup snapshot to a different vCenter instance (to simulate site recovery). Validate that SAML configuration is preserved post-restore.

same

Implement Fine-Grained Authorization with NSX Micro-Segmentation Tied to IdP Attributes

Extend multi-tenancy to network level: create NSX Distributed Firewall rules that reference IdP user attributes (e.g., department or location) to enforce network access per user context, not just per role. This is advanced policy-as-code and requires NSX policy engine customization.

harder

Test vCenter HA Replica Promotion and Manual Failback Procedure

After the primary fails and a replica is promoted, simulate a manual failback scenario where the original primary comes back online. Document the procedure: is it automatic or manual? How do you prevent the old primary from becoming primary again unexpectedly?

same

References

VMware Cloud Foundation 9.0 Identity Broker Administration GuideTier 1 — Official
Official Broadcom documentation for Identity Broker configuration, SAML/OIDC setup, and group mappings. Essential for Tasks 2-3.
vSphere 8.0 Security Configuration Guide: SAML AuthenticationTier 1 — Official
vCenter-specific SAML configuration and trust setup. Required for Task 2 vCenter SAML integration.
VCF 9.0 vCenter High Availability (HA) Deployment GuideTier 1 — Official
Step-by-step vCenter HA configuration and failover procedures. Essential for Task 1 and failover testing.
NSX Manager Authentication and Role-Based Access Control (RBAC) ConfigurationTier 1 — Official
NSX-specific RBAC and identity integration. Required for Task 3 NSX role configuration.
Okta SAML 2.0 Application Setup (or Entra ID OIDC Setup)Tier 2 — VMware Press
IdP-specific configuration guides. Choose Okta or Entra depending on your lab IdP choice. Required for Task 2 external IdP setup.
Cormac Hogan — VCF 9.0 Identity and Security ArchitectureTier 3 — Expert Blog
Expert deep-dives on VCF 9.0 identity architecture, federation patterns, and security implications.

Mark complete