Huit consoles, huit comptes locaux, un tableur de mots de passe partagé par l’équipe d’astreinte. Puis un audit tombe : tout départ doit être révoqué sur l’ensemble du parc en moins de vingt-quatre heures. C’est ce déclencheur — et non une envie de modernité — qui met VCF Single Sign-On sur la table de l’avant-projet.
Cet article ne raconte pas « comment brancher un SSO ». Il répond à une seule question, celle que l’avant-projet tranche mal et que l’exploitation paie ensuite : une fois VCF Single Sign-On configuré, quelles consoles arrêtent de demander un compte local, et lesquelles continuent ? On lit la liste des composants telle que Broadcom la publie, on nomme les exclusions telles qu’elles sont écrites, et on chiffre le prix de sortie du mode de déploiement. Aucun lab n’a été exécuté : ce qui suit est un travail de lecture de documentation VCF 9.0 et 9.1, avec ses trous signalés à voix haute.
TL;DR
- La décision : trancher embedded ou appliance avant tout le reste, parce que changer de mode ensuite impose un Reset SSO complet — configuration de l’IdP, utilisateurs et groupes provisionnés, configuration des composants, tout est supprimé puis à refaire.
- L’arbitrage qui coûte : le mode appliance apporte un cluster de trois nœuds et jusqu’à cinq instances VCF rattachées, mais il oblige à générer un nouveau client OAuth pour PowerCLI et à refaire la configuration d’IdP au lieu de la reprendre.
- L’action de lundi matin : écrire la liste des accès qui restent hors du SSO — UI de SDDC Manager, ESX, clusters VKS, compte admin local de chaque composant — et nommer, pour chacun, le compte de secours et son détenteur.
Composant ou configuration : deux noms, deux plans
VCF Identity Broker est le composant que l’on déploie. C’est le nom porté par les titres de pages TechDocs : Deploying VCF Identity Broker, Deployment Modes of the VCF Identity Broker, Upgrade to Identity Broker 9.1. VCF Single Sign-On est la configuration que l’on réalise avec — Configuring VCF Single Sign-On, Configure a New VCF Single Sign-On for a VCF Instance. Une phrase du type « déployer VCF SSO » mélange les deux plans dès le premier mot.
L’abréviation « vIDB » circule largement sur le terrain. Un billet officiel VCF du 18 février 2026 écrit que l’Identity Broker « was previously known as VIDB ». Aucune page TechDocs chargée ne l’emploie comme nom normatif : à traiter comme un raccourci de couloir, pas comme un nom de catalogue.
Le piège suivant coûte plus cher. En VCF 9.1, l’index Authentication and Authorization de NSX liste treize sous-sections, dont, côte à côte, Integration with VMware Workspace ONE Access et Integration with VCF Identity Broker for Single-Sign-On Access. Les deux intégrations d’identité coexistent dans la documentation 9.1, sans hiérarchie annoncée entre elles.
Ce que la documentation ne dit pas
Aucune page chargée ne porte d’avis de dépréciation de Workspace ONE Access, ne nomme VCF Identity Broker comme son successeur, ni ne fournit de consigne de migration. Des contenus tiers affirment cette dépréciation ; elle n’a pas été retrouvée sur une page Broadcom. Le point se tranche sur la version déployée chez vous, pas depuis un billet.
Trace de renommage, en revanche, parfaitement vérifiable : la page NSX s’intitule Integration with VCF Identity Broker for Single-Sign-On Access mais vit toujours à une adresse dont le segment porte workspace-one-access-broker. Le nom du produit a changé plus vite que l’arborescence documentaire. C’est une anecdote, et c’est aussi la meilleure raison de vérifier un nom avant de l’écrire dans un document d’architecture.
Les trois cercles de couverture — et les deux frontières
La page Configuring VCF Single Sign-On énumère les composants concernés : vCenter, VCF Operations, VCF Automation, VCF Operations for logs, VCF Operations for networks, VCF Operations orchestrator, VCF Operations HCX et NSX. La formulation publiée en 9.1 est sans ambiguïté : « across all VCF components except SDDC Manager and ESX ». Ce n’est pas un oubli de rédaction, c’est une frontière de produit.
À l’intérieur même de cette liste, la profondeur d’intégration n’est pas la même partout. Le découpage qui suit n’est publié tel quel sur aucune page : c’est un assemblage de plusieurs pages officielles, et il vaut ce que vaut une lecture, pas ce que vaudrait une observation.
Cercle 1 — un écran, deux composants. vCenter et NSX se configurent ensemble depuis VCF Operations, dans Fleet Management → Identity & Access. En 9.1, le parcours passe par le bouton Start en face de Enable SSO for vCenter and NSX, puis par la sélection des composants dans la grille et Configure. La page d’étape s’appelle littéralement Configure VCF Single Sign-On for NSX and vCenter.
Cercle 2 — une étape dédiée, devenue optionnelle. VCF Operations et VCF Automation ont leur propre étape dans la séquence. En 9.1, elle est explicitement marquée (Optional).
Cercle 3 — un client OIDC monté composant par composant. L’étape Configure VCF Single Sign-On for other VCF Components est un hub de navigation : elle renvoie vers une procédure par composant plutôt que d’en décrire une. Et ces procédures ne se ressemblent pas.
| Composant | Où la configuration se fait | Ce qu’il faut fournir |
|---|---|---|
| VCF Operations for logs | dans l’appliance logs (Configuration → Authentication → carte VCF SSO) et côté fleet (Identity & Access → VCF Other Components) | privilèges super admin sur l’appliance, licence VCF |
| VCF Operations for networks | connexion locale au composant, puis Configure → Identity and Access Management → VCF SSO | identity broker issuer address, REPLACE_WITH_CLIENT_ID, REPLACE_WITH_SHARED_SECRET, puis Test Connection |
| VCF Operations HCX | dans HCX Manager, sur son propre port d’administration, menu Configuration | application OAuth créée en amont, puis mapping de rôles obligatoire |
| PowerCLI | client OAuth généré côté fleet (Identity & Access → VCF Other Components → Add → Generate OIDC Client) | Client ID et secret ; le contexte OAuth est échangé contre un contexte SAML pour joindre vCenter |
| VCF Operations orchestrator | page de configuration non chargée pendant cette recherche | inconnu — à relever sur votre plateforme |
La ligne « orchestrator » est un trou assumé : le composant est nommé par le hub et par la matrice de rôles, mais sa page de configuration n’a pas pu être chargée. Décrire son parcours reviendrait à l’inventer.
Première frontière : SDDC Manager et ESX. La page Points to Consider précise le comportement réel : « SDDC Manager UI will support logins only with local admin accounts such as @vsphere.local users », tandis que « SDDC Manager APIs will support logins with VCF Single Sign-On users ». L’interface est exclue, l’API ne l’est pas. Un billet officiel VCF du 19 juin 2025, signé Eric Gray, formule la même limite côté pratique.
Seconde frontière : VKS. La page Configuring Identity and Access for VKS Clusters ne connaît que deux méthodes — vCenter Single Sign-On par défaut, ou un fournisseur d’identité externe conforme à OIDC. VCF Identity Broker n’y est nommé nulle part, et ni VKS ni vSphere Supervisor n’apparaissent dans la liste des composants couverts. La seule description d’un branchement Identity Broker vers vSphere Supervisor est un billet personnel de William Lam, publié le 8 juin 2026, présenté par son auteur pour des besoins « lab or PoC » — et qui pose lui-même la réserve décisive : dès que VCF Automation est déployé avec le Supervisor, c’est VCFA qui devient l’interface IdP et l’Identity Broker n’est plus dans la boucle. Ce n’est pas de la documentation produit, et cela ne fonde aucun statut de support : pour le lecteur qui monte ses clusters, la mise en route d’un premier cluster VKS reste un chantier d’identité distinct.
Ce que « SSO » ne recouvre pas
Le mot fait entendre quatre promesses. Deux tiennent, deux ne tiennent pas — et la documentation le dit elle-même.
| Ce que le lecteur entend | Ce que la documentation établit |
|---|---|
| un seul login | oui, pour les composants de la liste publiée |
| un seul annuaire | oui, une seule source d’authentification configurée depuis VCF Operations |
| un seul logout | non — « VCF Single Sign-On supports a single component logout mechanism. When you log out, the session ends exclusively for that particular VCF component within the designated browser. » |
| un seul modèle de rôles | non — « VCF roles do not aim to replace the individual components roles or their Authorization model » |
Six rôles VCF sont intégrés : VCF Administrator, VCF Viewer, SDDC Administrator, SDDC Viewer, Migration Admin, Migration Appliance Admin. Leur correspondance publiée laisse des cellules vides, et c’est le point le plus utile du tableau.
| Rôle VCF | vCenter | NSX | VCF Operations | VCF Automation |
|---|---|---|---|---|
| VCF Administrator | Admin | enterprise_admin |
Administrator | System Administrator |
| VCF Viewer | ReadOnly | auditor |
ReadOnly | — |
| SDDC Administrator | Admin | enterprise_admin |
— | — |
| SDDC Viewer | ReadOnly | auditor |
— | — |
La page Managing VCF Roles ajoute la phrase qui tue le raccourci : « If a user has VCF roles and component roles assigned, then the overall access is a combination of both, and not the replacement of one over the other. » Et la page d’étape, en 9.0 comme en 9.1, prévient qu’après la configuration initiale il faut se connecter avec le compte admin local de chaque composant pour attribuer les rôles aux utilisateurs et groupes provisionnés.
Traduction opérationnelle pour notre parc de démonstration : grp-vcf-admins se mappe sur VCF Administrator, grp-vcf-viewers sur VCF Viewer, mais grp-nsx-secops ne trouve aucun rôle VCF intégré qui convienne. L’écriture de politiques de sécurité NSX passe par l’un des quinze rôles NSX intégrés, attribué localement. L’authentification est centralisée ; l’autorisation ne l’est pas.
Conséquence directe sur le SLA de départ : un SSO n’est pas une révocation. Couper l’utilisateur en amont ferme l’ouverture de nouvelles sessions, mais il reste à statuer sur les sessions en cours et sur les rôles attribués localement dans chaque composant.
Embedded ou appliance : le prix de sortie avant le prix d’entrée
Deux modes existent, et deux seulement. Le mode embedded se configure dans le vCenter du domaine de gestion : service à nœud unique, protégé par vSphere HA et par la sauvegarde/restauration de vCenter, avec la recommandation publiée d’un Identity Broker par instance VCF. Le mode appliance se déploie depuis VCF Operations sous forme d’un cluster de trois nœuds, tolère la panne d’un nœud, et accepte au maximum cinq instances VCF rattachées à un même Identity Broker.
Les critères de sélection publiés pour l’appliance sont explicites : plusieurs instances VCF à connecter, un vCenter de domaine de gestion inaccessible à certains composants, ou un besoin de résistance à la panne d’un nœud. La bibliothèque de design tranche dans le même sens : le modèle embedded « fits new VMware Cloud Foundation platforms, or deployments that have lower requirements for availability », le modèle appliance vise les « critical up-time requirements » et les plateformes « multi-instance multi-site ». Elle formalise deux exigences chiffrées, VCF-SSO-REQD-EXT-001 — déployer l’appliance dans le premier vCenter du domaine de gestion, avec l’implication publiée d’une charge d’exploitation supplémentaire — et VCF-SSO-REQD-EXT-002, connecter l’appliance à l’IdP d’entreprise.
Ce que les comparatifs rapides omettent, c’est le prix de sortie. Changer de mode après coup n’est pas un réglage : la page Change the Deployment Mode in VCF Single Sign-On impose un Reset SSO, décrit comme la suppression de toutes les configurations liées au SSO, « including the identity provider configuration, the provisioned users and groups, and the component configuration ». Deuxième coût, contre-intuitif : la documentation annonce la continuité des automatisations PowerCLI seulement si l’IdP est configuré dans le vCenter du domaine de gestion en mode embedded — en mode appliance, ou sur un vCenter de gestion alternatif, un nouveau client OAuth doit être généré. Troisième : à la reprise d’une configuration d’IdP existante, la configuration n’est retenue qu’en mode embedded, et « Users and groups are not migrated » dans tous les cas.
Pour notre plateforme de démonstration, le mode appliance est retenu — idb-par-01.corp.example, nœuds idb-par-01a à idb-par-01c — parce qu’une seconde instance vcf-lyo-01 est prévue et que la panne du vCenter de gestion ne doit pas emporter l’authentification. C’est une hypothèse de design, pas une recommandation Broadcom, et son prix est assumé par écrit : reprise du parc d’automatisation PowerCLI, et reconfiguration complète de l’IdP au lieu d’une reprise.
Un arbitrage qui ne s'appuie sur aucune page de design
La page de design décrivant un modèle « fleet-wide » ne se charge pas — elle répond 404. L’arbitrage « SSO par instance ou SSO de flotte » ne peut donc pas se réclamer d’une page d’architecture : il se traite par la limite publiée des cinq instances VCF rattachées à un même Identity Broker, et par les modèles par instance, qui eux sont documentés.
Le placement réseau, enfin, est une décision d’architecture et pas un détail d’installation. La page Upgrade to Identity Broker 9.1 publie la contrainte la plus coûteuse du composant : quand VCF Operations est déjà en 9.1, une appliance Identity Broker 9.0.x posée sur un segment overlay NSX, ou sur un réseau et un datastore différents de ceux des services de gestion VCF, fait échouer l’upgrade. La consigne est de la déployer sur le réseau de gestion VCF, et de garantir qu’elle joigne l’IdP pendant la transition. Un composant d’identité posé « là où il y avait de la place » se paie au premier upgrade, pas au déploiement.
La séquence 9.1, et le prérequis qui coûte une fenêtre d’indisponibilité
La séquence de configuration a changé de forme entre 9.0 et 9.1. Citer un numéro d’étape sans citer sa version induit en erreur.
| VCF 9.0 — sept étapes | VCF 9.1 — six étapes | |
|---|---|---|
| 1 | Select a VCF Instance | Choose the Deployment Mode |
| 2 | Choose the Deployment Mode | Configure an Identity Provider |
| 3 | Configure an Identity Provider | Configure VCF Single Sign-On for NSX and vCenter |
| 4 | Configure VCF Single Sign-On for NSX and vCenter | (Optional) Assign a VCF Role |
| 5 | Configure VCF SSO for VCF Operations and VCF Automation | (Optional) Configure VCF SSO for VCF Operations and VCF Automation |
| 6 | (Optional) Configure VCF SSO for other VCF Components | (Optional) Configure VCF SSO for other VCF Components |
| 7 | Assigning Roles and Permissions | — |
Trois différences méritent d’être commentées. La sélection d’instance disparaît de la séquence 9.1. L’attribution de rôle devient une étape numérotée et optionnelle, au lieu d’une étape finale. Et la connexion de VCF Operations et VCF Automation devient explicitement optionnelle.
Avant la première étape, un prérequis structurant attend le projet : Enhanced Linked Mode doit être désactivé. La page dédiée est catégorique — « VCF Single Sign-On is not compatible with the vCenter Enhanced Linked Mode (ELM) » — et impose l’utilitaire cmsso-util break-elm, qui exige que toutes les instances vCenter de la topologie soient opérationnelles et en version 9.0. L’effet publié n’est pas anodin : « Any shared configurations, like tags, roles, permissions and so on that are in ELM, will remain local to individual vCenter Instances after you deactivate ELM. » La page recommande des snapshots hors ligne de toutes les instances vCenter — donc une indisponibilité, malgré le « without downtime » de son propre titre.
Deux autres points de la même page changent le plan de bascule. Après configuration de VCF Single Sign-On depuis VCF Operations, il n’est plus possible de configurer des sources d’identité dans les instances vCenter, et les configurations d’IdP préexistantes de vCenter sont écrasées, utilisateurs et groupes devant être re-provisionnés. Et le compte qui réalise la configuration a besoin du périmètre All Objects dans VCF Operations, attribué via Administration → Control Panel → Access Control. Les composants, eux, doivent être en version 9.0 ou ultérieure, licenciés, et hors anneau ELM.
Côté NSX, la page d’intégration précise le périmètre — NSX Managers, Local Managers et Global Managers — et renvoie, pour les Global Managers et les NSX Managers autonomes, à l’article de base de connaissances Broadcom numéro 3875053. Cet article est cité par son numéro et pas par une adresse : l’URL correspondante ne se charge pas, et un article voisin numéroté 387503 traite une autre version de NSX. Ne pas substituer l’un à l’autre.
Une contradiction publiée, qu'il faut lire comme telle
Cette même page NSX écrit : « To configure this capability, it is recommended to use the VMware Cloud Foundation SDDC Manager. » Or SDDC Manager est nommément exclu du périmètre de VCF Single Sign-On, et la séquence 9.1 passe par VCF Operations. La lecture la plus probable est un reliquat de rédaction hérité d’une génération antérieure — cohérent avec l’URL qui porte encore workspace-one-access-broker — mais la documentation ne le confirme pas. À trancher sur votre plateforme, pas ici.
Ce qui reste local après la bascule — et le compte de rupture
L’accès non interactif se gère depuis Fleet Management → Identity & Access → VCF SSO Overview, onglet API Access. Les durées publiées sont un jeton API de trente jours par défaut et un jeton d’accès de trente minutes par défaut, l’un et l’autre plafonnés par les réglages API Token Expiry et Access Token Expiry sous Fleet Settings → IAM Setting. La valeur effective sur votre plateforme reste à relever : REPLACE_WITH_TOKEN_TTL.
Le compte de rupture, lui, a une place documentée. L’emergency access client est décrit pour des « break-glass scenarios that provide high-privilege and long-lived access tokens to critical systems when standard methods fail ». Ses caractéristiques publiées : le rôle le plus élevé et le périmètre le plus large, non modifiables ; une validité par défaut de cent quatre-vingts jours ; un seul jeton d’accès d’urgence à la fois ; régénération et suppression disponibles.
La conséquence de sécurité n'est pas publiée — elle se déduit
Un jeton au plus haut privilège, valable cent quatre-vingts jours par défaut, dont le rôle ne peut pas être réduit, est un actif dont la conservation vaut celle d’une clé de coffre. Il n’ouvre pas non plus tout : il donne accès à l’API, pas à l’interface de SDDC Manager. Il ne remplace donc pas les comptes locaux de secours des composants, et le manque d’un chapitre de durcissement sur ce point dans la documentation n’est pas une autorisation à l’ignorer.
Une procédure d’astreinte honnête nomme les accès qui survivent à la centralisation :
- le compte admin local de chaque composant, nécessaire à l’attribution des rôles après la bascule ;
- le compte admin local de SDDC Manager, dont l’interface n’accepte que des comptes de type
@vsphere.local; - l’accès à ESX, hors périmètre par la documentation elle-même ;
- l’accès aux clusters VKS, qui suit vCenter Single Sign-On ou un IdP OIDC déclaré sur le Supervisor ;
- l’emergency access client, s’il a été créé, avec l’endroit où son jeton est conservé.
Reste un trou qu’il faut dire plutôt que combler : aucune page chargée ne décrit le comportement des composants pendant une indisponibilité de l’IdP amont — durée de validité des sessions en cours, échec ouvert ou fermé, tolérance. Affirmer que « les sessions en cours survivent » ou que « tout tombe » serait inventé dans les deux sens. La question se pose à l’IdP et se tranche en lab, pas dans un article.
Pièges & points de vigilance
Les cinq erreurs qui coûtent une reprise complète
1. Annoncer « le SSO sur toute la plateforme » : SDDC Manager et ESX sont exclus par la documentation, VKS n’est pas dans la liste. 2. Choisir le mode de déploiement à la légère : le changer impose un Reset SSO et la réattribution des rôles dans chaque composant. 3. Poser l’appliance sur un segment overlay NSX : l’upgrade 9.0.x vers 9.1 échoue. 4. Oublier ELM dans le planning : sa désactivation est un acte séparé, avec sauvegarde recommandée et effets définitifs sur les tags, rôles et permissions partagés. 5. Confondre authentification et autorisation : les rôles VCF s’ajoutent aux rôles des composants, ils ne les remplacent pas.
Deux autres réflexes valent d’être écrits dans la revue d’architecture. Le premier : le retour arrière n’est pas symétrique. Le Reset SSO supprime la configuration, mais aucune page chargée ne décrit la restauration d’ELM ni celle des sources d’identité locales de vCenter écrasées à la bascule. Présenter l’opération comme « réversible en bloc » est faux tant que ce chemin n’est pas documenté.
Le second : les libellés d’interface de VCF Operations 9.1 — Identity & Access, VCF SSO Overview, API Access, Emergency Access — sont ceux relevés dans la documentation, et ils peuvent bouger d’un niveau de patch à l’autre. Un runbook qui les cite sans mentionner la version se périme silencieusement. Pour le cadre général fleet / instance / domaine dans lequel tout ceci s’inscrit, la nouvelle architecture VCF 9 pose le vocabulaire, et le volet sécurité et résilience de VCF 9.1 donne le contexte de durcissement.
Conclusion
L’article s’arrête volontairement à l’étape 2 de la séquence 9.1, Configure an Identity Provider : c’est le sujet entier du prochain, Fédérer l’identité VCF : Okta, Entra ID, et le chemin générique, qui publie la matrice réelle des fournisseurs d’identité, protocole par protocole. Le troisième volet, vDefend Distributed Firewall : le zero trust au niveau du workload, ira chercher ce que cette identité permet — ou pas — d’écrire dans une règle de pare-feu. La réponse y sera moins confortable qu’on ne l’imagine ici.
Le périmètre est une liste
Huit composants nommés, SDDC Manager et ESX exclus, VKS absent. Recopier la liste dans le document d’architecture vaut mieux que de résumer par « toute la plateforme ».
Le mode se choisit une fois
Embedded ou appliance : le changement passe par un Reset SSO complet. Décider en connaissant le prix de sortie — PowerCLI, reprise d’IdP, réattribution des rôles.
Les comptes locaux ne disparaissent pas
Un compte admin par composant, l’UI de SDDC Manager, ESX, VKS, et l’accès de rupture. Les nommer et les gouverner, plutôt que de faire semblant de les avoir supprimés.
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
