Protection de votre environnement par vCenter Single Sign-On

vCenter Single Sign-On permet aux composants vSphere de communiquer au moyen d'un mécanisme d'échange de jetons sécurisé.

vCenter Single Sign-On utilise les services suivants.

• 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, RSA SecurID et l'authentification de session Windows).
• Authentification des utilisateurs de solution par le biais des certificats.
• STS (Security Token Service).
• SSL pour sécuriser le trafic.

Présentation du fournisseur d'identité

Avant vSphere 7.0, vCenter Server comprenait un fournisseur d'identité intégré. Par défaut, vCenter Server utilise le domaine vsphere.local comme source d'identité, mais vous pouvez la modifier 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 et 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.

À partir de vSphere 7.0, vous pouvez configurer l'instance de 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é. Actuellement, vSphere prend en charge Active Directory Federation Services (AD FS) en tant que fournisseur d'identité externe. Dans cette configuration, AD FS interagit avec les sources d'identité au nom de l'instance de vCenter Server.

Connexion de l'utilisateur avec l'authentification fédérée du fournisseur d'identité vCenter Server

La figure suivante montre le flux de connexion de l'utilisateur pour la fédération de fournisseur d'identité vCenter Server.

Figure 1. Connexion de l'utilisateur de la fédération de fournisseur d'identité vCenter Server

vCenter Server, AD FS et Active Directory interagissent de la façon suivante :

1. L'utilisateur démarre sur la page d'accueil de vCenter Server en entrant un nom d'utilisateur.
2. Si le nom d'utilisateur est destiné à un domaine fédéré, vCenter Server redirige la demande d'authentification vers AD FS.
3. Si nécessaire, AD FS invite l'utilisateur à se connecter avec des informations d'identification Active Directory.
4. AD FS authentifie l'utilisateur avec Active Directory.
5. AD FS émet un jeton de sécurité avec les informations de groupe d'Active Directory.
6. vCenter Server utilise le jeton pour connecter l'utilisateur.

L'utilisateur est désormais authentifié et peut afficher et modifier les objets pour lesquels il possède les privilèges pertinents.

Note : Le rôle Aucun accès est attribué initialement à chaque utilisateur. Pour qu'un utilisateur puisse se connecter, un administrateur vCenter Server doit au moins lui attribuer le rôle Lecture seule. Consultez la documentation de Sécurité vSphere.

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.

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é.

Figure 2. Connexion de l'utilisateur avec le fournisseur d'identité intégré de vCenter Server

1. 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.

   Lorsque l'authentification Windows intégrée (IWA) a été configurée, les utilisateurs peuvent également se connecter sans avoir à entrer de nouveau leur mot de passe Windows en cochant la case Utiliser l'authentification de session Windows.

2. 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.
3. 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.
4. vSphere Client transmet le jeton au système vCenter Server.
5. vCenter Server vérifie auprès du serveur vCenter Single Sign-On que le jeton est valide et n'a pas expiré.
6. 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.

L'utilisateur est désormais authentifié et peut afficher et modifier les objets pour lesquels il possède les privilèges pertinents.

Note : Le rôle Aucun accès est attribué initialement à chaque utilisateur. Pour qu'un utilisateur puisse se connecter, un administrateur vCenter Server doit au moins lui attribuer le rôle Lecture seule. Consultez la documentation de Sécurité vSphere.

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.

Note : L'instance de vCenter Server utilise des certificats d'utilisateur de solution uniquement pour la communication interne. Les certificats d'utilisateur de solution ne sont pas utilisés pour la communication externe.

La figure suivante illustre le flux de connexion des utilisateurs de solution.

Figure 3. Connexion pour les utilisateurs de solution

1. L'utilisateur de solution tente de se connecter à un service vCenter Server.
2. 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.
3. 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.
4. 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 Utiliser des certificats personnalisés avec vSphere.

Chiffrement pris en charge

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.