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 vCenter 7.0, vous pouvez configurer l'instance 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.

Mais dans une prochaine version, VMware arrête le support de l'authentification intégrée. Concrètement, le système permettait de se connecter directement au contrôleur de domaine Active Directory ou autre, puis de s'authentifier directement avec des informations utilisateurs saisies dans le formulaire. Mais nous savons bien qu'il y'a toujours un risque que les informations peuvent êtres interceptées donc compromises.

Dans ce tutoriel, nous allons voir ensemble la procédure complète dans l'intégration de l'authentification depuis un serveur de fédération ADFS afin de mieux gérer l'authentification des utilisateurs du domaine.

Principe de fonctionnement

Afin de mieux situer les choses, voici un schéma définissant le fonctionnement d'une 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 le serveur AD FS.
3. Si nécessaire, le serveur AD FS invite l'utilisateur à se connecter avec des informations d'identification Active Directory.
4. Le serveur 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.

Prérequis

Afin de suivre la formation ADFS, quelques prérequis sont nécessaires :

• Au minimum un serveur de domaine Active Directory (rôle ADDS, DNS).
• Une machine Windows Server pour le rôle ADFS.
• Le certificat issu de la PKI du serveur ADFS.
• Une machine VCSA (vCenter 7.0) - vSphere.

Prenez garde que toutes les manipulations de doivent pas êtres réalisées directement sur le VCSA de production car les utilisateurs seront dropés de VCSA, je le dis au cas où

Configuration de l'authentification

Concrètement, nous allons dès à présent voir les différents moyens d'authentification au serveur VCSA. Nous allons étudier cette partie.

Configuration actuelle : authentification intégrée

Dirigez vous dans le menu hamburger ☰, puis l'onglet Administration > Single Sign-On > Configuration.

Puis, dans la partie "Sources d'identité", nous avons dans notre cas déjà configuré une authentification intégrée Windows Active Directory :

Afin d'éviter tout conflits, il est important de supprimer la source d'identités Windows intégrée, puis de redémarrer le nœud (voir : Déploiement > Configuration système > Redémarrer le nœud). C'est important.

Récupérer les adresses de redirection

Nous allons récupérer dans un premier temps les adresses de redirection pour notre serveur d'identité ADFS externe afin de réaliser la migration à partir du fournisseur d'identité vCenter Server intégré vers un fournisseur d'identité externe en cliquant sur 🛈 > URI de redirection :

Dans notre cas :

• https://VCSA.domain.local/ui/login
• https://VCSA.domain.local/ui/login/oauth2/authcode

Gardez ces adresses de côté

Importation du certificat de l'ADFS

Afin de lier le serveur ADFS au VCSA, il est nécessaire de récupérer le certificat du serveur ADFS et de l'importer sur l'ADFS. Nous allons réaliser ces manipulations en ligne de commandes avec l'applet Java JRE VMware afin de gérer l'ajout dans le magasin de certificat VCSA.

Activer la connexion SSH

Rendez-vous dans la console vCenter Server Management depuis l'URI de redirection de votre VCSA, port 5480 : https://VCSA.domain.local:5480/login

Puis, allez dans la section Accès > Paramètres d'accès. Cliquez sur le bouton "Modifier" et cochez l'option "Activer la connexion SSH" :

Une fois que les opérations sont terminées, désactivez ensuite le service

Importer le certificat ADSF avec WinSCP

Avec WinSCP, nous allons nous connecter en SFTP au VCSA afin d'importer le certificat au format .crt (clée publique uniquement !) de l'ADFS dans le dossier utilisateur, pour l'importation du certificat dans l'autorité JRE.

Le fichier a été importé dans le dossier racine de l'utilisateur /root, portant le nom adfs-cert.crt :

Si vous avez des problèmes durant la connexion au WinSCP, lisez la solution de remédiation

Importer le certificat ADFS dans le magasin de certificats

En ligne de commande, après avoir ouvert une connexion SSH, nous allons aller dans un dossier spécifique à Java dans lequel nous allons retrouver certains fichiers binaires, dont un utilitaire qui est "keytool". Il s'agit de l'utilitaire capable de manipuler le magasin de certificats sur le VCSA courant.

En ligne de commande, réalisez les commandes suivantes :

Command> shell
Shell access is granted to root
root@VCSA [ ~ ]# cd /usr/java/jre-vmware/bin/
root@VCSA [ /usr/java/jre-vmware/bin ]# keytool -import -trustcacerts -file ~/adfs-cert.crt -alias adfs -keystore /usr/java/jre-vmware/lib/security/cacerts

Concrètement, ces instructions ouvre un Shell pour l'utilisateur "root", puis on se déplace dans le dossier des binaires Java et on réalise ensuite l'importation du certificat dans le magasin de certificats VCSA.

Nous saisissions le mot de passe du "keystore", puis on confirme qu'il faut faire confiance à ce certificat :

root@VCSA [ /usr/java/jre-vmware/bin ]# keytool -import -trustcacerts -file ~/adfs-cert.crt -alias adfs -keystore /usr/java/jre-vmware/lib/security/cacerts
Picked up JAVA_TOOL_OPTIONS: -Xms32M -Xmx128M   -Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true   -Dorg.apache.xml.security.ignoreLineBreaks=true
Enter keystore password:           <<--- Mot de passe du Keystore
[...]
Trust this certificate? [no]: yes  <<--- On souhaite "Truster" le certificat
Certificate was added to keystore
root@VCSA [ /usr/java/jre-vmware/bin ]#

Le mot de passe par défaut de keystore ("Enter keystore password:") est : changeit.

Le certificat est importé.

Maintenant, il est nécessaire de redémarrer la WebUI, les services "TrustManagement" et "STSD" afin de prendre en compte l'ajout du certificat :

root@VCSA [ /usr/java/jre-vmware/bin ]# service-control --stop vsphere-ui
root@VCSA [ /usr/java/jre-vmware/bin ]# service-control --start vsphere-ui
root@VCSA [ /usr/java/jre-vmware/bin ]# service-control --start vmware-trustmanagement
root@VCSA [ /usr/java/jre-vmware/bin ]# service-control --start vmware-stsd

Nous allons lister ensuite le certificat importé, avec l'alias "adfs" :

root@VCSA [ /usr/java/jre-vmware/bin ]# keytool -list -keystore /usr/java/jre-vmware/lib/security/cacerts -alias adfs -v

On récupère ainsi l'ensemble des informations du certificat dont l'l'alias et le type d'entrée qui est "trustedCertEntry" :

root@VCSA [ /usr/java/jre-vmware/bin ]# keytool -list -keystore /usr/java/jre-vmware/lib/security/cacerts -alias adfs -v
Picked up JAVA_TOOL_OPTIONS: -Xms32M -Xmx128M   -Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true   -Dorg.apache.xml.security.ignoreLineBreaks=true
Enter keystore password:           <<--- Mot de passe du Keystore
Alias name: adfs                   <<--- Alias du certificat ADFS
Creation date: Apr 27, 2023
Entry type: trustedCertEntry       <<--- Le certificat est "trusté"

Owner: [email protected], CN=adfs.vemotech.training, OU=VemoTech, O=VemoTech, L=LILLE, ST=HAUTS-DE-FRANCE, C=FR
Issuer: [email protected], CN=VemoTech Labs Authority, OU=VemoTech, O=VemoTech, L=LILLE, ST=HAUTS-DE-FRANCE, C=FR
Serial number: f7fe24cb
Valid from: Sun Apr 23 18:55:35 CEST 2023 until: Thu Apr 21 18:55:35 CEST 2033
Certificate fingerprints:
     SHA1: C0:5C:0B:6E:AD:7E:4E:18:96:F5:5B:0A:14:E7:70:A6:04:25:2B:97
     SHA256: 48:E2:5B:E8:F2:F4:62:7D:1C:AD:F0:0D:ED:14:C9:57:FB:55:9F:90:6A:07:E7:C9:1C:03:4D:28:B6:AC:E7:08
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

[...]

root@VCSA [ /usr/java/jre-vmware/bin ]#

Création du groupe d'application ADFS

Maintenant que nous avons importé le certificat, nous allons dès à présent créer le groupe d'application sur le serveur ADFS.

Ouvrez la console de "Gestion AD FS" directement dans la barre de recherche ou effectuez un Windows + R > %windir%\ADFS\Microsoft.IdentityServer.msc. Dans la section "Groupe d'applications", cliquez sur "Ajouter un groupe d'applications..." :

L'assistant nous invite à choisir un nom et une description de notre application.

Sélectionnez comme modèle d'application client/server : "Application serveur accédant à une API web" :

En cliquant sur "Suivant", récupérez le "ClientID". Ce dernier permets à l'ADFS d'authentifier l'application derrière (le VCSA).

On spécifie ensuite les deux URI de redirection copiées au préalable :

Copiez dans un bloc-notes le "ClientID" (notre cas : ClientID : 323626cf-0e0c-4921-94e8-65a22a054f47). Il nous servira pour la configuration sur le VCSA.

La prochaine étape va être d'utiliser une clé secrète partagée (Pre-shared Key). Copiez-la dans un bloc-notes, elle nous sera utile pour plus tard :

C'est ici que maintenant vous devez être attentifs. Lors de la configuration de l'API Web, l'identifiant est une chaine de caractère qui est à nouveau transmise du VCSA vers le serveur ADFS afin de gérer l'authentification, afin de prouver qu'il s'agit bien de vous.

Dans ce cas, nous devons spécifier le "ClientID" qui a été généré en amont, celui que vous avez copié dans le bloc-notes :

Faites attention à ne pas laisser d'espaces avant et après la chaine de caractères, ou tout autres caractères tel que des apostrophes ou des guillemets.

Au niveau de la stratégie de contrôle d'accès, vous pouvez gérer la zone d'authentification et des listes d'accès : soit rendre accessible uniquement un zone Intranet, Extranet, imposer une authentification MFA ou autoriser pour tout le monde, comme dans notre cas :

Les spécifications d'autorisations de l'application sera d'autoriser la demande et l'utilisation des tokens d'identité.

Choisissez alors : "allatclaims" et "openid" :

Enfin, un récapitulatif est affiché, puis cliquez sur "Suivant" afin de d'appliquer la configuration.

L'application est bien créée :

Configuration de l'OpenID

Cette phase présente la configuration de l'OpenID. Nous allons ainsi ajouter un ensemble de règles afin de permettre cela.

Vous pouvez double cliquer sur le groupe l'applications ou clic-droit > Propriétés afin d'afficher un descriptif, mais également modifier les propriétés du groupe dans le futur en sélectionnant l'application, puis "Modifier..." :

Dans notre cas, nous allons ajouter des modifications à l'application "API Web". Sélectionnez l'application API web, puis cliquez sur "Modifier" :

Dans l'onglet "Règles de transformation d'émission", la liste est actuellement vide. Cliquez sur "Ajouter une règle" :

Sélectionnez le modèle par défaut :

Création de la règle "Group claim"

Comme nom de la règle, ajoutez comme nom générique : "Group claim" et sélectionnez comme magasin d'attributs "Active Directory".

Ensuite, ajoutez un champ d'attribut LDAP qui est "Token-Groups - Qualifié par nom long de domaine" et comme type de revendication sortante : "Groupe".

En cliquant sur "Terminer", la règle est créée et est visible dans la liste :

Création de la règle "Subject claim"

Même chose, on créé une deuxième règle pour l'objet de la demande ADFS. Ajoutez comme nom générique : "Group claim" et sélectionnez comme magasin d'attributs "Active Directory".

Ensuite, ajoutez un champ d'attribut LDAP qui est "User-Principal-Name" et comme type de revendication sortante : "ID de nom" :

Création de la règle "UPN claim"

Enfin on créé une dernière règle pour l'objet de la demande ADFS. Ajoutez comme nom générique : "UPN claim" et sélectionnez comme magasin d'attributs "Active Directory".

Ensuite, ajoutez un champ d'attribut LDAP qui est "User-Principal-Name" et comme type de revendication sortante : "UPN" :

Les trois règles sont créées. Validez en cliquant sur "Appliquer", puis "OK" :

Maintenant, ce que nous devons faire est la configuration de l'OpenID. C'est une URL qui permettra au VCSA d'obtenir des informations sur le serveur ADFS. Ce sont les informations qui seront essentiels à notre configuration.

Avec PowerShell, il est possible d'obtenir ces informations depuis le serveur ADFS :

PS C:\> Get-AdfsEndpoint | Select "FullURL" | Select-String "OpenID-Configuration"

@{FullUrl=https://authwall.vemotech.fr/adfs/.well-known/openid-configuration}

On obtient ainsi l'URL complète de configuration pour OpenID : https://authwall.vemotech.fr/adfs/.well-known/openid-configuration

Gardez cette adresse URL dans votre bloc-notes, on en aura besoin

Modification du fournisseur d'identité

Connecté sur l'interface Web d'administration du VCSA (https://VCSA.domain.local/ui/app/admin/sso-configuration/identity-provider), allez au niveau du menu hamburger ☰, puis l'onglet Administration > Single Sign-On > Configuration.

Puis, dans la partie "Sources d'identité", nous allons cliquer sur "Changer de fournisseur d'identité" :

On souhaite configurer, lors de cet assistant, Microsoft ADFS comme fournisseur d'identité :

Renseignez dans les champs correspondants les informations que nous avons copiées dans le bloc-notes :

• ClientID : 323626cf-0e0c-4921-94e8-65a22a054f47
• Pre-Shared : LlIoM_vfvAsF_XX4pSadacTCl0vY4a_vBTtrr6ao
• OpenID Config URL : https://<ADFS>/adfs/.well-known/openid-configuration

Nous avons à ce stade donnés les informations cruciales au moyen de l'OpenID configurable auprès de notre ADFS.

Même si nous utilisons exclusivement l'authentification ADFS dans le futur, tout de même l'assistant souhaite obtenir une connexion à l'annuaire Active Directory. C'est nécessaire lors de la phase de saisie de l'utilisateur, le VCSA va chercher si l'utilisateur existe dans la base et dispose des droits d'accès et donc de créer une nouvelle demande d'authentification et recevoir ensuite un ticket SAML.

Nous allons ainsi spécifier les différentes informations de notre domaine Active Directory :

• Nom unique de base pour les groupes : dc=domain,dc=local
• Nom d'utilisateur (compte de service créé sur l'AD) : [email protected]
• Mot de passe : ••••••••••
• URL du serveur principal (AD) : ldaps://1.2.3.4:636
• URL secondaire du serveur (si vous avez un second AD) : ldaps://5.6.7.8:636
• Certificats (pour LDAPS) :
• AD001.cer
• AD002.cer

Chaque certificat de vos contrôleurs de domaines doivent êtres récupérés afin de vérifier la connexion. La connexion s'effectue en TLS avec les contrôleurs de domaine sur le port TCP LDAP (389) ou LDAPS (636). Chaque certificat est à récupérer dans la magasin public de chaque serveur.

Un récapitulatif affiche la configuration. Cliquez sur "Terminer" :

L'assistant va dans un premier temps joindre le serveur ADFS sur le port TCP 443 (HTTPS), puis va ensuite tenter de se connecter aux contrôleurs de domaine.

L'ADFS est maintenant enregistré :

Processus d'authentification avec le VCSA & l'ADFS

Notre authentification ADFS est désormais fonctionnelle. Nous allons de ce fait tester cette connexion. Dans une fenêtre de navigateur privée, connectez-vous à votre VCSA (https://vcsa.domain.local/ui/login).

Vous pouvez remarquer que maintenant l'interface utilisateur d'authentification a changée. Habituellement, nous sommes habitués à voir un champ pour la saisie de l'utilisateur et un champ pour le mot de passe, ici nous n'avons plus que le nom d'utilisateur à saisir. Nous avons bien la page pour une connexion SSO du VCSA :

Autoriser l'accès au VMware vCenter Server Appliance (VCSA)

Il est nécessaire maintenant d'ajouter les utilisateurs ou groupes autorisés à se connecter au VCSA.

Dirigez vous dans le menu hamburger ☰, puis l'onglet Administration > Single Sign-On > Utilisateurs et groupes. Dans cette section, nous avons la liste des comptes et groupes créés et récupérés par domaines.

Sélectionnez le domaine local (domain.local), puis saisir le compte utilisateur à autoriser :

On va ensuite tester la connexion sur le VCSA avec le compte de domaine "vt_training", dans un nouvel onglet de navigateur Web. Le format du nom d'utilisateur doit être [email protected] ou DOMAIN\account :

En cliquant sur "Suivant", nous sommes redirigés sur le portail ADFS :

Sur le serveur ADFS, nous spécifions ainsi le nom d'utilisateur complet + mot de passe :

Et voilà le travail ! Nous sommes bien authentifié sur le VCSA !

Troubleshooting

En cas de problèmes, consultez les fichiers journaux sur chaque machines, vérifiez que les certificats sont identiques, que la connectivités réseau est OK.

• Observateur d’événements sur le serveur ADFS : eventvwr.msc /s :

• Fichiers journaux (logs) sur le VCSA :
• Afficher les messages d'évènements : tail -f /var/log/vmware/messages
• Afficher les messages liés aux connexions SSO : tail -f /var/log/vmware/sso/ssoAdminServer.log

Conclusion

Nous avons ainsi configuré avec succès l'authentification VCSA avec un serveur ADFS. Dans un premier temps, nous renseignons notre nom d'utilisateur avec la structure [email protected]. Ensuite, en cliquant sur suivant, nous sommes redirigés vers la page d'authentification ADFS. De ce fait, l'authentification se fait en OAuth et après que les informations d'identifications ont été vérifiées sur le serveur ADFS, avec entre autre le serveur Active Directory, nous obtenons ainsi un "request-token" afin de valider qu'il s'agit d'une connexion authentifiée et valide.

Il est très avantageux de proposer ce système, étant donné la criticité de l'accès au serveur VCSA. À noter que si l'ADFS ou le contrôleur de domaine ne fonctionnait plus, tout le système est caduque.