vCenter Single Sign-On permet aux composants vSphere de communiquer au moyen d'un mécanisme d'échange de jetons sécurisé.
- Authentification des utilisateurs par le biais d'une fédération de fournisseur d'identité externe ou du fournisseur d'identité intégré de vCenter Server. Le fournisseur d'identité intégré prend en charge les comptes locaux, Active Directory ou OpenLDAP, l'authentification Windows intégrée (IWA) et divers mécanismes d'authentification (carte à puce et RSA SecurID).
- Authentification des utilisateurs de solution par le biais des certificats.
- STS (Security Token Service).
- SSL pour sécuriser le trafic.
Fournisseur d'identité intégré de vCenter Server
vCenter Server inclut un fournisseur d'identité intégré. Par défaut, vCenter Server utilise le domaine vsphere.local comme source d'identité (mais vous pouvez modifier le domaine lors de l'installation). Vous pouvez configurer le fournisseur d'identité intégré de vCenter Server pour utiliser Active Directory (AD) comme source d'identité à l'aide de LDAP/S, OpenLDAP/S ou de l'authentification Windows intégrée (IWA). De telles configurations permettent aux clients de se connecter à l'instance de vCenter Server à l'aide de leurs comptes AD.
vCenter Server et un fournisseur d'identité externe
Dans vSphere 7.0 et versions ultérieures, vous pouvez configurer vCenter Server pour un fournisseur d'identité externe à l'aide de l'authentification fédérée. Dans une telle configuration, vous remplacez vCenter Server comme fournisseur d'identité.
vSphere prend en charge les fournisseurs d'identité suivants.
- vSphere 7.0 et versions ultérieures : Services de fédération Active Directory (AD FS)
- vSphere 8.0 Update 3 et versions ultérieures : Okta
- vSphere 8.0 Update 2 et versions ultérieures : Microsoft Entra ID (anciennement appelé Azure AD)
- À partir de vSphere 8.0 Update 3 : PingFederate
Lorsque vous configurez vSphere pour utiliser un fournisseur d'identité externe, celui-ci interagit avec les sources d'identité pour le compte de vCenter Server.
Connexion de l'utilisateur avec l'authentification fédérée du fournisseur d'identité vCenter Server
Lorsque vous utilisez un fournisseur d'identité externe pour vous authentifier auprès de vCenter Server, vCenter Server redirige la demande de connexion vers le fournisseur d'identité externe. Le fournisseur d'identité externe authentifie l'utilisateur avec son service d'annuaire, puis émet un jeton pour que vCenter Server l'utilise pour se connecter à l'utilisateur.
Par exemple, la figure suivante montre une vue détaillée du flux de connexion de l'utilisateur pour la fédération de fournisseur d'identité vCenter Server à l'aide d'AD FS.
vCenter Server, AD FS et Active Directory interagissent de la façon suivante :
- L'utilisateur démarre sur la page d'accueil de vCenter Server en entrant un nom d'utilisateur.
- Si le nom d'utilisateur est destiné à un domaine fédéré, vCenter Server redirige la demande d'authentification vers AD FS.
- Si nécessaire, AD FS invite l'utilisateur à se connecter avec des informations d'identification Active Directory.
- AD FS authentifie l'utilisateur avec Active Directory.
- AD FS émet un jeton de sécurité avec les informations de groupe d'Active Directory.
- vCenter Server utilise le jeton pour connecter l'utilisateur.
Si le fournisseur d'identité externe est inaccessible, le processus de connexion revient à la page de destination de vCenter Server et affiche un message d'information approprié. Les utilisateurs peuvent toujours se connecter à l'aide de leurs comptes locaux dans la source d'identité vsphere.local.
L'interaction entre vCenter Server et Okta, Microsoft Entra ID ou PingFederate est semblable à celle d'AD FS, sauf que vCenter Server utilise VMware Identity Services. Reportez-vous à la section Processus d'authentification VMware Identity Services.
Connexion de l'utilisateur avec le fournisseur d'identité intégré de vCenter Server
La figure suivante illustre le flux de connexion de l'utilisateur lorsque vCenter Server agit comme le fournisseur d'identité.
- Un utilisateur se connecte à vSphere Client avec un nom d'utilisateur et un mot de passe pour accéder au système vCenter Server ou à un autre service vCenter.
- vSphere Client transmet les informations de connexion au service vCenter Single Sign-On. Celui-ci vérifie alors le jeton SAML de vSphere Client. Si vSphere Client dispose d'un jeton valide, vCenter Single Sign-On vérifie ensuite que l'utilisateur figure bien dans la source d'identité configurée (par exemple, Active Directory).
- Si seul le nom d'utilisateur est employé, vCenter Single Sign-On effectue la vérification dans le domaine par défaut.
- Si un nom de domaine est inclus avec le nom d'utilisateur (DOMAIN\user1 ou user1@DOMAIN), vCenter Single Sign-On vérifie ce domaine.
- Si l'utilisateur peut s'authentifier auprès de la source d'identité, vCenter Single Sign-On renvoie un jeton qui représente l'utilisateur pour vSphere Client.
- vSphere Client transmet le jeton au système vCenter Server.
- vCenter Server vérifie auprès du serveur vCenter Single Sign-On que le jeton est valide et n'a pas expiré.
- Le serveur vCenter Single Sign-On renvoie le jeton au système vCenter Server, en utilisant la structure d'autorisation de vCenter Server pour autoriser l'accès de l'utilisateur.
Connexion pour les utilisateurs de solution
Les utilisateurs de solution sont des ensembles de services utilisés dans l'infrastructure vCenter Server (par exemple, les extensions vCenter Server). Les extensions VMware et éventuellement les extensions tierces peuvent également s'authentifier auprès de vCenter Single Sign-On.
La figure suivante illustre le flux de connexion des utilisateurs de solution.
- L'utilisateur de solution tente de se connecter à un service vCenter Server.
- L'utilisateur de solution est redirigé vers vCenter Single Sign-On. Si l'utilisateur de solution est nouveau dans vCenter Single Sign-On, il doit présenter un certificat valide.
- Si le certificat est valide, vCenter Single Sign-On attribue un jeton SAML (jeton de support) à l'utilisateur de solution. Le jeton est signé par vCenter Single Sign-On.
- L'utilisateur de solution est ensuite redirigé vers vCenter Single Sign-On et peut effectuer des tâches, selon les autorisations qui lui sont attribuées.
La prochaine fois que l'utilisateur de solution devra s'authentifier, il pourra utiliser le jeton SAML pour se connecter à vCenter Server.
Cet établissement de liaison est automatique par défaut, car VMCA provisionne les utilisateurs de solution à l'aide de certificats pendant le démarrage. Si votre stratégie d'entreprise requiert des certificats signés par une autorité de certification tierce, vous pouvez remplacer les certificats d'utilisateur de solution par ces certificats signés par une autorité de certification tierce. Si ces certificats ne sont pas valides, vCenter Single Sign-On attribue un jeton SAML à l'utilisateur de solution. Reportez-vous à la section Remplacer les certificats d'utilisateurs de solutions par des certificats personnalisés à l'aide de Certificate Manager.
Chiffrement pris en charge dans vSphere
Le chiffrement AES, qui est le niveau de chiffrement le plus élevé, est pris en charge. Le chiffrement pris en charge affecte également la sécurité lorsque vCenter Single Sign-On utilise Active Directory comme source d'identité.
Cela affecte également la sécurité chaque fois qu'un hôte ESXi ou vCenter Server est associé à Active Directory.