Dans vSphere 7.0 et versions ultérieures, vCenter Server prend en charge l'authentification fédérée pour se connecter à vCenter Server.

Pour activer l'authentification fédérée sur vCenter Server, vous devez configurer une connexion à un fournisseur d'identité externe. L'instance de fournisseur d'identité que vous configurez remplace vCenter Server en tant que fournisseur d'identité. Actuellement, vCenter Server prend en charge Active Directory Federation Services (AD FS), Okta, Microsoft Entra ID (anciennement Azure AD) et PingFederate en tant que fournisseurs d'identité externes. vCenter Server prend en charge AD FS dans vSphere 7.0 et versions ultérieures, Okta dans vSphere 8.0 Update 1 et versions ultérieures, Microsoft Entra ID dans vSphere 8.0 Update 2 et versions ultérieures et PingFederate à partir de vSphere 8.0 Update 3.

Note : VMware vous encourage à utiliser l'authentification fédérée, car vSphere se dirige vers l'authentification basée sur des jetons. vCenter Server continue d'avoir des comptes locaux, destinés à l'accès administratif et à la récupération d'erreur.

Fonctionnement de la fédération de fournisseur d'identité vCenter Server

La fédération de fournisseur d'identité vCenter Server vous permet de configurer un fournisseur d'identité externe pour l'authentification fédérée. Dans cette configuration, le fournisseur d'identité externe interagit avec la source d'identité au nom de l'instance de vCenter Server.

Principes de base de la fédération de fournisseur d'identité vCenter Server

Dans vSphere 7.0 et versions ultérieures, vCenter Server prend en charge l'authentification fédérée. Dans ce scénario, lorsqu'un utilisateur se connecte au système vCenter Server, vCenter Server redirige la connexion de l'utilisateur vers le fournisseur d'identité externe. Les informations d'identification de l'utilisateur ne sont plus fournies directement à l'instance de vCenter Server. Au lieu de cela, l'utilisateur fournit des informations d'identification au fournisseur d'identité externe. vCenter Server approuve le fournisseur d'identité externe pour effectuer l'authentification. Dans le modèle de fédération, les utilisateurs ne fournissent jamais d'informations d'identification directement à un service ou à une application, mais uniquement au fournisseur d'identité. Par conséquent, vous « fédérez » vos applications et services, tels que vCenter Server, avec votre fournisseur d'identité.

Prise en charge du fournisseur d'identité externe de vCenter Server

vCenter Server prend en charge les fournisseurs d'identité externes suivants :

  • AD FS (vSphere 7.0 et versions ultérieures)
  • Okta (vSphere 8.0 Update 1 et version ultérieure)
  • ID Microsoft Entra, anciennement appelé Azure AD (vSphere 8.0 Update 2 et versions ultérieures)
  • PingFederate (à partir de vSphere 8.0 Update 3)

Avantages de la fédération de fournisseur d'identité vCenter Server

La fédération de fournisseur d'identité vCenter Server offre les avantages suivants.

  • Vous pouvez utiliser Single Sign-On avec une infrastructure et des applications fédérées existantes.
  • Vous pouvez améliorer la sécurité du centre de données, car le système vCenter Server ne gère jamais les informations d'identification de l'utilisateur.
  • Vous pouvez utiliser les mécanismes d'authentification, tels que l'authentification multifacteur, pris en charge par le fournisseur d'identité externe.

Architecture de la fédération de fournisseur d'identité vCenter Server

Pour établir une relation d'approbation de partie de confiance entre vCenter Server et un fournisseur d'identité, vous devez établir les informations d'identification et un secret partagé entre eux. vCenter Server utilise le protocole OpenID Connect (OIDC) pour recevoir un jeton d'identité qui authentifie l'utilisateur avec vCenter Server.

Les étapes de haut niveau de configuration d'un fournisseur d'identité externe avec vCenter Server incluent les éléments suivants :

  1. Établissement d'une approbation de partie de confiance entre vCenter Server et le fournisseur d'identité externe en créant une configuration OIDC. Pour AD FS, créez un groupe d'applications ou une application. Pour Okta, Microsoft Entra ID et PingFederate, créez une application native avec OpenID Connect comme méthode d'authentification. La configuration OIDC se compose d'une application Server et d'une API Web. Les deux composants spécifient les informations que l'instance de vCenter Server utilise pour approuver le fournisseur d'identité externe et communiquer avec lui.
  2. Création d'un fournisseur d'identité correspondant dans vCenter Server.
  3. Configuration des appartenances de groupe dans vCenter Server pour autoriser les connexions des utilisateurs dans le domaine fournisseur d'identité externe.

L'administrateur fournisseur d'identité doit fournir les informations suivantes pour créer la configuration du fournisseur d'identité vCenter Server :

  • Identifiant de client : chaîne UUID générée dans AD FS lorsque vous créez le groupe d'applications (ou l'application) et qui identifie le groupe d'applications (ou l'application), ou qui est générée dans Okta, Microsoft Entra ID ou PingFederate lorsque vous créez l'application OpenID Connect.
  • Secret partagé : secret généré dans AD FS lorsque vous créez le groupe d'applications (ou l'application), ou qui est généré dans Okta lorsque vous créez l'application OpenID Connect, et qui est utilisé pour authentifier vCenter Server avec le fournisseur d'identité externe.
  • Adresse OpenID : URL du point de terminaison de découverte de fournisseur OpenID du serveur fournisseur d'identité externe, spécifiant une adresse connue qui est généralement le point de terminaison de l'émetteur concaténé au chemin /.well-known/openid-configuration. Voici un exemple d'adresse OpenID pour une configuration AD FS : 
    https://webserver.example.com/adfs/.well-known/openid-configuration
    De même, voici un exemple d'adresse OpenID pour une configuration Okta : 
    https://example.okta.com/oauth2/default/.well-known/openid-configuration
    Voici un exemple d'adresse OpenID pour une configuration Microsoft Entra ID :
    https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0/.well-known/openid-configuration
    Voici un exemple d'adresse OpenID pour une configuration PingFederate :
    https://pingfederate-fqdn-and-port/.well-known/openid-configuration

VMware Identity Services et authentification fédérée

À partir de vSphere 8.0 Update 1, VMware Identity Services fournit l'intégration à des fournisseurs d'identité en tant que fournisseur d'identité fédéré. Vous pouvez considérer VMware Identity Services comme une version « allégée » de VMware Workspace ONE intégrée à vSphere.

Lorsque vous installez vSphere 8.0 Update 1 ou effectuez la mise à niveau vers celui-ci ou une version ultérieure, VMware Identity Services est activé par défaut sur vCenter Server. Lorsque vous configurez Okta, Microsoft Entra ID ou PingFederate en tant que fournisseur d'identité externe, vCenter Server utilise VMware Identity Services pour communiquer avec votre serveur Okta, Microsoft Entra ID ou PingFederate.

vCenter Server prend en charge Okta, Microsoft Entra ID et PingFederate en tant que fournisseur d'identité externe dans une configuration Enhanced Linked Mode. Même si, dans une configuration Enhanced Linked Mode, plusieurs systèmes vCenter Server exécutent VMware Identity Services, un seul système vCenter Server et les services VMware Identity Services qui lui sont associés communiquent avec votre serveur de fournisseur d'identité externe. Par exemple, si vous disposez d'une configuration Enhanced Linked Mode de trois systèmes vCenter Server, A, B et C, et que vous configurez le fournisseur d'identité externe Okta sur vCenter Server A, vCenter Server A est le seul système qui gère toutes les connexions Okta. vCenter Server B et vCenter Server C ne communiquent pas directement avec le serveur Okta. Pour configurer VMware Identity Services sur d'autres systèmes vCenter Server dans la configuration ELM pour interagir avec votre serveur de fournisseur d'identité externe, reportez-vous à la section Processus d'activation des fournisseurs d'identité externes dans des configurations Enhanced Linked Mode.

Note : Lors de la configuration d'Okta en tant que fournisseur d'identité externe, tous les systèmes vCenter Server dans une configuration Enhanced Linked Mode doivent exécuter au moins vSphere 8.0 Update 1. Pour l'ID Microsoft Entra, la configuration requise est au moins vSphere 8.0 Update 2. Pour PingFederate, la configuration requise est au moins vSphere 8.0 Update 3.
Avertissement : Lorsque vous utilisez une configuration Enhanced Linked Mode avec Okta, Microsoft Entra ID ou PingFederate, vous ne pouvez pas supprimer le système vCenter Server qui exécute VMware Identity Services et qui communique avec le fournisseur d'identité de la configuration ELM.

Processus d'authentification VMware Identity Services

Lorsque vous configurez vCenter Server pour utiliser VMware Identity Services pour communiquer avec votre fournisseur d'identité externe, le processus d'authentification suivant se produit :

  1. Un utilisateur se connecte à vCenter Server avec vSphere Client.
  2. vCenter Single Sign-On délègue l'authentification utilisateur et redirige la demande de l'utilisateur vers VMware Identity Services.
  3. Le processus VMware Identity Services demande un jeton au fournisseur d'identité externe pour établir la session utilisateur.
  4. Le fournisseur d'identité externe authentifie l'utilisateur (il peut utiliser l'authentification multifacteur (MFA) ou les informations d'identification SSO) et renvoie le jeton à VMware Identity Services.

    Le jeton contient les réclamations de l'utilisateur.

  5. Le processus VMware Identity Services valide le jeton du fournisseur d'identité et génère un jeton VMware Identity Services correspondant, puis envoie le jeton VMware Identity Services à vCenter Single Sign-On.
  6. vCenter Single Sign-On valide le jeton et accorde la demande de connexion.
Note : AD FS n'utilise pas VMware Identity Services pour l'authentification fédérée.

Interaction de vCenter Server avec les utilisateurs et les groupes envoyés par SCIM

Lorsque vous configurez votre fournisseur d'identité externe, vCenter Server utilise le système pour la gestion des identités inter-domaines (SCIM, System for Cross-domain Identity Management) pour la gestion des utilisateurs et des groupes. SCIM est une norme ouverte pour l'automatisation de l'identité d'utilisateur. Une application SCIM que vous créez sur votre serveur de fournisseur d'identité externe gère les utilisateurs et les groupes sur le fournisseur d'identité externe que vous souhaitez transférer vers vCenter Server. vCenter Server utilise également SCIM lors de la recherche d'utilisateurs et de groupes pour attribuer des autorisations à des objets vCenter Server.

Note : Une configuration AD FS recherche Active Directory à l'aide de LDAP. Elle n'utilise pas SCIM.

Composants de la fédération de fournisseur d'identité vCenter Server

Les composants suivants comprennent une configuration de fédération de fournisseur d'identité vCenter Server :

  • Une instance de vCenter Server
    • Pour AD FS : vCenter Server 7.0 ou version ultérieure
    • Pour Okta : vCenter Server 8.0 Update 1 ou version ultérieure
    • Pour Microsoft Entra ID : vCenter Server 8.0 Update 2 ou version ultérieure
    • Pour PingFederate : vCenter Server 8.0 Update 3
  • Un service de fournisseur d'identité configuré sur l'instance de vCenter Server
  • Un fournisseur d'identité externe (AD FS, Okta, Microsoft Entra ID ou PingFederate)
  • Une configuration OpenID Connect (OIDC) :
    • Pour AD FS : un groupe d'applications (également appelé application)
    • Pour Okta, Microsoft Entra ID ou PingFederate : une application OpenID Connect
  • Une application SCIM (System for Cross-domain Identity Management) pour la gestion des utilisateurs et des groupes (uniquement pour Okta, Microsoft Entra ID ou PingFederate)
  • Les groupes et les utilisateurs du fournisseur d'identité externe que vous mappez aux groupes et utilisateurs de vCenter Server
  • VMware Identity Services activés sur vCenter Server (uniquement pour Okta, Microsoft Entra ID ou PingFederate)
  • Facultativement, pour PingFederate, le certificat SSL ou la chaîne de certificats du serveur PingFederate, si ce certificat n'a pas été émis par une autorité de certification publique connue. Vous importez le certificat SSL PingFederate dans le vCenter Server.

Restrictions et interopérabilité de la fédération de fournisseurs d'identité vCenter Server

La fédération de fournisseurs d'identité vCenter Server peut interagir avec de nombreuses autres fonctionnalités VMware.

Lors de la planification de votre stratégie de fédération de fournisseurs d'identité vCenter Server, tenez compte des éventuelles limitations d'interopérabilité.

Mécanismes d'authentification

Dans une configuration de fédération de fournisseur d'identité vCenter Server, le fournisseur d'identité externe gère les mécanismes d'authentification (mots de passe, MFA, biométrie, etc.).

AD FS et prise en charge d'un domaine Active Directory unique

Lorsque vous configurez la fédération de fournisseurs d'identité vCenter Server pour AD FS, l'assistant Configurer le fournisseur d'identité principal vous invite à entrer les informations LDAP pour le domaine AD unique contenant les utilisateurs et les groupes pour lesquels vous souhaitez qu'ils puissent accéder à vCenter Server. vCenter Server dérive le domaine AD à utiliser pour l'autorisation, ainsi que les autorisations à partir du nom unique de base de l'utilisateur que vous spécifiez dans l'assistant. Vous pouvez ajouter des autorisations sur des objets vSphere uniquement pour les utilisateurs et les groupes de ce domaine AD. Les utilisateurs ou les groupes de domaines enfants AD ou d'autres domaines de la forêt AD ne sont pas pris en charge par la fédération de fournisseurs d'identité vCenter Server.

Prise en charge d'Okta, de Microsoft Entra ID et de PingFederate pour plusieurs domaines

Lorsque vous configurez la fédération de fournisseurs d'identité vCenter Server pour Okta, Microsoft Entra ID ou PingFederate, l'assistant Configurer le fournisseur d'identité principal vous permet d'entrer les informations LDAP pour plusieurs domaines contenant les utilisateurs et les groupes pour lesquels vous souhaitez qu'ils puissent accéder à vCenter Server.

Stratégies de mot de passe, de verrouillage et de jeton

Lorsque vCenter Server agit comme fournisseur d'identité, vous contrôlez les stratégies de mot de passe, de verrouillage et de jeton de vCenter Server pour le domaine par défaut (vsphere.local ou le nom de domaine que vous avez entré lors de l'installation de vSphere). Lors de l'utilisation de l'authentification fédérée avec le système vCenter Server, le fournisseur d'identité externe contrôle les stratégies de mot de passe, de verrouillage et de jeton pour les comptes stockés dans la source d'identité, tels qu'Active Directory.

Audit et conformité

Lors de l'utilisation de la fédération de fournisseurs d'identité vCenter Server, le système vCenter Server continue de créer des entrées de journal pour les connexions utilisateur réussies. Toutefois, le fournisseur d'identité externe est responsable du suivi et de la journalisation des actions, telles que les tentatives d'entrée de mot de passe et les verrouillages de compte d'utilisateur. Le système vCenter Server ne journalise pas ces événements, car ils ne sont plus visibles pour vCenter Server. Par exemple, lorsque AD FS est le fournisseur d'identité, il suit et journalise les erreurs des connexions fédérées. Lorsque le système vCenter Server est le fournisseur d'identification des connexions locales, vCenter Server surveille et journalise les erreurs de ces connexions. Dans une configuration fédérée, le système vCenter Server continue de consigner les actions de l'utilisateur après la connexion.

Intégration de produits VMware existants à des fournisseurs d'identité externes

Les produits VMware intégrés à l'instance de vCenter Server (par exemple, VMware Aria Operations, vSAN, NSX, etc.) continuent de fonctionner comme auparavant.

Produits qui intègrent la post-connexion

Les produits qui intègrent la post-connexion (c'est-à-dire qu'ils n'ont pas besoin d'une connexion distincte) continuent de fonctionner comme avant.

Authentification simple pour l'accès aux API, SDK et CLI

Les scripts, produits et autres fonctionnalités existantes qui reposent sur des commandes d'API, de SDK ou d'interface de ligne de commande qui utilisent l'authentification simple (c'est-à-dire nom d'utilisateur et mot de passe) continuent de fonctionner comme avant. En interne, l'authentification s'effectue en transmettant le nom d'utilisateur et le mot de passe. Cette transmission du nom d'utilisateur et du mot de passe compromet certains des avantages de l'utilisation de la fédération d'identité, car elle expose le mot de passe à vCenter Server (et à vos scripts). Envisagez de migrer vers l'authentification basée sur des jetons, lorsque c'est possible.

Accès à l'interface de gestion de vCenter Server

Si l'utilisateur est membre du groupe d'administrateurs vCenter Server, l'accès à l'interface de gestion de vCenter Server (anciennement appelée interface de gestion de dispositif vCenter Server ou interface VAMI) est pris en charge.

Entrée du texte du nom d'utilisateur sur la page de connexion AD FS

La page de connexion AD FS ne prend pas en charge la transmission de texte pour préremplir la zone de texte de nom d'utilisateur. Par conséquent, lors des connexions fédérées avec AD FS, après l'entrée de votre nom d'utilisateur sur la page de lancement de vCenter Server et redirection vers la page de connexion AD FS, vous devez entrer de nouveau votre nom d'utilisateur sur la page de connexion AD FS. Le nom d'utilisateur que vous entrez sur la page de lancement de vCenter Server est nécessaire pour rediriger la connexion vers le fournisseur d'identité approprié, et le nom d'utilisateur sur la page de connexion AD FS est nécessaire pour s'authentifier auprès d'AD FS. Cette incapacité à transmettre le nom d'utilisateur à la page de connexion AD FS constitue une limite d'AD FS. Vous ne pouvez pas configurer ou modifier ce comportement directement dans vCenter Server.

Prise en charge des adresses IPv6

AD FS, Microsoft Entra ID et Ping Federate prennent en charge les adresses IPv6. Okta ne prend pas en charge les adresses IPv6.

Configuration d'une instance unique de VMware Identity Services

Par défaut, lorsque vous installez vSphere 8.0 Update 1 ou procédez à une mise à niveau vers cette version, VMware Identity Services est activé sur vCenter Server. Lors de la configuration d'Okta, de Microsoft Entra ID ou de PingFederate en mode Enhanced Linked Mode, vous utilisez VMware Identity Services sur un système vCenter Server unique. Par exemple, si vous utilisez Okta dans une configuration Enhanced Link Mode qui se compose de trois systèmes vCenter Server, seul un système vCenter Server et son instance de VMware Identity Services sont utilisés pour communiquer avec le serveur Okta.

Avertissement :

Dans une configuration ELM qui utilise VMware Identity Services, si le système vCenter Server qui communique avec le fournisseur d'identité externe devient indisponible, vous pouvez configurer VMware Identity Services sur d'autres instances de vCenter Server dans la configuration ELM pour interagir avec votre serveur IDP externe. Reportez-vous à la section Processus d'activation des fournisseurs d'identité externes dans des configurations Enhanced Linked Mode.

Reconfiguration de l'identifiant réseau principal

La reconfiguration de l'identifiant réseau principal (PNID) de vCenter Server nécessite la mise à jour de la configuration du fournisseur d'identité externe comme suit.

Cycle de vie de la fédération de fournisseurs d'identité vCenter Server

Lorsque vous gérez le cycle de vie de la fédération de fournisseurs d'identité vCenter Server, des éléments spécifiques doivent être pris en compte.

Vous pouvez gérer le cycle de vie de la fédération de fournisseurs d'identité vCenter Server de l'une des manières suivantes.

Migration d'Active Directory vers un fournisseur d'identité externe

Si vous utilisez Active Directory comme source d'identité pour vCenter Server, la migration vers l'utilisation d'un fournisseur d'identité externe est directe. Si vos groupes et rôles Active Directory correspondent aux groupes et rôles de votre fournisseur d'identité, vous n'avez pas besoin d'effectuer d'autres actions. Lorsque les groupes et les rôles ne correspondent pas, vous devez effectuer des tâches supplémentaires. Si vCenter Server est membre du domaine, envisagez de le supprimer du domaine, car il n'est pas requis ou utilisé pour la fédération d'identité.

Redirection et migration inter-domaines

La fédération de fournisseur d'identité de vCenter Server prend en charge la redirection inter-domaines, c'est-à-dire le déplacement d'une instance de vCenter Server d'un domaine vSphere SSO vers un autre. L'instance de vCenter Server redirigée reçoit la configuration de fournisseur d'identité répliquée depuis le système vCenter Server ou les systèmes sur lesquels elle était dirigée.

En général, il n'est pas nécessaire d'effectuer une reconfiguration de fournisseur d'identité supplémentaire pour une redirection inter-domaines, sauf si l'une des conditions suivantes est vraie.

  1. La configuration de fournisseur d'identité de l'instance de vCenter Server redirigée diffère de la configuration de fournisseur d'identité de l'instance de vCenter Server sur laquelle elle était dirigée.
  2. C'est la première fois que l'instance de vCenter Server redirigée reçoit une configuration de fournisseur d'identité.

Dans de tels cas, des travaux supplémentaires sont nécessaires. Par exemple, pour AD FS, vous devez ajouter les URI de redirection du système vCenter Server au groupe d'applications correspondant sur le serveur AD FS. Par exemple, si vCenter Server 1 avec le groupe d'applications AD FS A (ou aucune configuration AD FS) est redirigé vers vCenter Server 2 avec le groupe d'applications AD FS B, vous devez ajouter les URI de redirection de vCenter Server 1 au groupe d'applications B.

Synchronisation des utilisateurs et des groupes et sauvegarde et restauration de vCenter Server

Selon le moment où vous synchronisez vos utilisateurs et groupes avec vCenter Server et où vous sauvegardez votre système vCenter Server, si vous devez restaurer votre système vCenter Server, vous devrez peut-être resynchroniser vos utilisateurs et groupes qui ont été transférés par SCIM.

Pour restaurer un utilisateur ou un groupe supprimé, vous ne pouvez pas simplement transférer l'utilisateur ou le groupe depuis le fournisseur d'identité vers vCenter Server. Vous devez mettre à jour l'application SCIM 2.0 sur le fournisseur d'identité externe avec l'utilisateur ou le groupe manquant. Reportez-vous à la section Restaurer des utilisateurs et des groupes SCIM supprimés.