Identity integration in VCF 9.1 is a fleet level task you run from VCF Operations. A component called the VCF Identity Broker sits between your enterprise identity source and every management console, so one directory account signs in to VCF Operations, the vSphere Client, NSX Manager and the other fleet services. You configure the broker once, attach an identity provider such as Active Directory over LDAP, provision the groups you care about, and then switch single sign on on for each component. This guide walks the click by click flow for an Active Directory provider, covers group provisioning, and shows how to assign roles so signed in users can actually do their work.

Run this task after the fleet is deployed and upgraded, and treat it as a standard operation every fleet performs. Password and credential rotation for the built in local accounts is a separate task, covered in Part 6 on password and credential rotation, so this part stays on external identity only. If you want the wider picture of which console owns what, read the Part 1 overview of the operating model and the primer on what VCF Operations is in VCF 9. For the original bring up steps, see the VCF 9.1 Deployment guide.

Prerequisites

Gather the following before you open VCF Operations. A read only bind account and reachable domain controllers are the two items that stall most first attempts, so confirm both up front.

How VCF single sign on fits together

Your identity provider holds the users and groups. The VCF Identity Broker trusts that provider and issues tokens to each console. Every management component trusts the broker rather than the directory directly, which is why you configure the connection once and enable it per component. The diagram below shows the path a sign in request travels.

Provisioning also has a choice of methods. With a modern provider you can use just in time provisioning or SCIM, and with a directory source you use AD over LDAP to pull groups. This guide uses the directory method, so the broker reads groups straight from Active Directory rather than waiting for a first sign in to create the account. Whichever method you pick, the pattern that follows stays the same: attach a provider, decide which groups to synchronise, enable the components, and grant roles.

Step 1, choose an identity broker deployment mode

Console for this step: VCF Operations. Deployment mode sets whether the broker runs inside the management vCenter or on its own appliances. Choose embedded for a single instance, or the appliance cluster when you run several instances or need higher availability.

1. Sign in to VCF Operations with a local administrator account.
2. Open the Fleet Management menu, then select Identity and Access.
3. Select your VCF instance, then click Set Up to start single sign on configuration.
4. On the deployment mode screen, choose Embedded for a single instance, or Appliance for a three node cluster serving up to five instances.
5. Enter the requested network details for the appliance option, then click Next to stage the broker.

Step 2, add your identity provider

Console for this step: VCF Operations. With the broker staged, attach the provider that holds your users. This walkthrough uses Active Directory over LDAP, which is the common choice for an on premises directory.

1. On the Identity and Access page, open the Identity Providers tab.
2. Click Add Identity Provider.
3. Select Active Directory over LDAP as the provider type.
4. In the Directory Name field, type a label such as corp.example.com so operators recognise it later.
5. In the Base Distinguished Name for Users field, enter the user search base, for example OU=Users,DC=corp,DC=example,DC=com.
6. In the Base Distinguished Name for Groups field, enter the group search base, for example OU=Groups,DC=corp,DC=example,DC=com.
7. In the Bind Username field, enter the read only service account in User Principal Name form, for example svc-vcf-ldap@corp.example.com.
8. Type the account password in the Bind Password field.

If you bind over secure LDAP on port 636, add the directory server certificate so the broker trusts the connection. Supply the root chain in PEM format.

1. Set the connection to port 636 to use LDAPS.
2. Paste the root certificate authority chain into the LDAPS Certificate field.
3. Click Test Connection and confirm a successful bind before saving.
4. Click Save to store the provider.

Step 3, provision directory groups

Console for this step: VCF Operations. Provisioning tells the broker which directory groups to synchronise. Sync only the groups you plan to grant access to, so the member list stays small and quick to search.

1. On the identity provider you just saved, open the Group Provisioning tab.
2. Click Add Groups.
3. In the search box, type part of a group name, for example vcf-admins.
4. Select each matching group by its Distinguished Name from the results list.
5. Click Add to move the selected groups into the sync list.
6. Click Sync Now to pull members immediately, or accept the scheduled sync.

Step 4, enable single sign on for vCenter and NSX Manager

Console for this step: VCF Operations. Core infrastructure components turn on single sign on with a checkbox. You can enable more than one at once from the component configuration screen.

1. On the Identity and Access page, open the Component Configuration tab.
2. Tick the checkbox next to vCenter Server.
3. Tick the checkbox next to NSX Manager.
4. Click Configure Component to apply single sign on to both.
5. Wait for each row to report a configured state before you move on.

Management services such as VCF Operations for Logs sit in their own nodes in the navigation tree. Open each node and follow the on screen guidance to finish its single sign on setup. For how NSX itself is owned across the fleet, see the primer on NSX in VCF 9 and Fleet Management.

Step 5, set the SDDC Manager single sign on group

Console for this step: SDDC Manager. Its interface is deprecated and does not accept single sign on login, so you keep using the local admin account there. You still configure a single sign on group, because some vSphere Client actions run against SDDC Manager on your behalf and need that authorisation.

1. Sign in to SDDC Manager with the local administrator@vsphere.local account.
2. Open Administration, then select Single Sign On.
3. Grant the Administrator role to the same directory group you use for vCenter administration.
4. Click Save to store the mapping.

Step 6, assign roles per component

Sign in gives a directory user access to the login screen, not permissions. Assign roles once, using each component local admin account, so provisioned groups can operate. Role names and locations differ by component, as the table shows. Grant the narrowest role that lets a group do its job, and use separate groups for read only operators and full administrators so an audit stays clear later.

The sequence below sums up the whole flow, from provider to working access, so you can confirm you have not skipped a stage.

Verify the integration

Confirm each layer before you hand the environment to your operators. Test with a real directory account that belongs to a provisioned group, not with a local admin.

1. In VCF Operations, open Group Provisioning and confirm the expected members appear under each synced group.
2. Sign out, then sign in to VCF Operations with a directory user and confirm the console loads with the granted role.
3. Open the vSphere Client, sign in with the same directory user, and confirm the assigned vCenter permissions apply.
4. Open NSX Manager, sign in with the directory user, and confirm the Enterprise Admin actions are available.
5. In VCF Operations, review the Component Configuration tab and confirm every enabled row reports a configured state.

Common errors and fixes

Common questions

Can I use Microsoft Entra ID instead of Active Directory over LDAP. Yes. VCF 9.1 supports Microsoft Entra ID, Okta, Ping Identity, Microsoft ADFS and Generic SAML 2.0 alongside the directory options, and you add any of them from the same Identity Providers tab.

Why can I not sign in to SDDC Manager with a directory account. Its interface is deprecated and stays on the local admin login. You configure a single sign on group there only so vSphere Client actions that run against SDDC Manager stay authorised.

When should I pick the appliance broker over embedded. Choose the three node appliance cluster when you run more than one VCF instance or need identity to stay available if the management vCenter is down. Embedded suits a single instance.

Do I still rotate the built in local passwords after this. Yes, and that stays a separate routine. Follow Part 6 on password and credential rotation for the local accounts, since single sign on does not replace them.

References

• Configure a New VCF Single Sign On for a VCF Instance, Broadcom TechDocs
• Configure Active Directory as an Identity Provider Using AD over LDAP, Broadcom TechDocs
• Configure VCF Single Sign On for NSX and vCenter, Broadcom TechDocs
• Configure VCF Single Sign On With a Modern Identity Provider for Authentication and AD over LDAP for Provisioning, Broadcom KB

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts