vCenter : authentification Active Directory via LDAPS

Le probleme qu’on resout

Par defaut, vCenter authentifie via le domaine SSO local (ex. vsphere.local). Gerer des comptes locaux ne passe pas a l’echelle : pas de politique de mot de passe centralisee, pas de desactivation automatique a la sortie d’un employe, pas de tracabilite unifiee. On veut donc deleguer l’authentification a Active Directory.

La methode « evidente » — ajouter une source d’identite AD en LDAP simple sur le port 389 — fonctionne techniquement mais transmet les identifiants de bind et les requetes d’annuaire en clair sur le reseau. C’est une exposition inacceptable (interception des credentials, MITRE ATT&CK T1557 Adversary-in-the-Middle). L’autre option, « Integrated Windows Authentication », est obsolete et retiree dans les versions recentes de vSphere (7.0 U3+ et 8.x) au profit du mode LDAP/LDAPS explicite.

La seule approche durable et securisee est donc une source d’identite Active Directory over LDAP forcee en LDAPS, avec validation de la chaine de certificats du controleur de domaine.

Comment ca marche

vCenter Single Sign-On (le service STS integre a la vCenter Server Appliance) agit comme client LDAP. Lorsqu’un utilisateur se connecte avec utilisateur@domaine.exemple.test, SSO :

• se connecte au(x) controleur(s) de domaine specifie(s) via LDAPS (TCP 636) ;
• effectue un bind avec le compte de service pour interroger l’annuaire ;
• recherche l’utilisateur sous le Base DN pour les utilisateurs et resout ses appartenances de groupe sous le Base DN pour les groupes ;
• applique les roles vCenter affectes a l’utilisateur ou a ses groupes AD.

Le point sensible est TLS : vCenter doit faire confiance au certificat presente par le controleur de domaine. Il faut donc importer dans la source d’identite la chaine de l’autorite de certification (AD CS d’entreprise typiquement) qui a emis les certificats des DC. Sans cette chaine, le handshake TLS echoue et aucun bind n’aboutit.

Prerequis

• Acces administrateur au vSphere Client, membre du groupe SSO Administrators du domaine vsphere.local.
• Acces SSH au vCenter Server Appliance (VCSA) pour les tests (compte root, shell active).
• Un compte de service AD dedie (ex. svc-vcenter-ldap@domaine.exemple.test), droits lecture seule sur l’annuaire, mot de passe sans expiration ou avec rotation documentee.
• Les FQDN des controleurs de domaine (ex. dc01.domaine.exemple.test) et une resolution DNS fonctionnelle depuis le VCSA.
• La chaine de certificats PEM de la CA (racine + intermediaires) ayant signe les certificats LDAPS des DC.
• Ouverture reseau du VCSA vers les DC sur TCP 636 (et 3269 si Global Catalog over SSL requis).
• Les Base DN utilisateurs/groupes (ex. OU=Users,DC=domaine,DC=exemple,DC=test).

Procedure

1. Recuperer la chaine CA. Exportez le certificat de la CA racine (et intermediaires) au format Base64/PEM. Depuis une AD CS : console certsrv > proprietes de l’autorite > onglet General > « Afficher le certificat » > export Base64. Ou en PowerShell (voir bloc de code).
2. Verifier la connectivite TLS depuis le VCSA vers le DC (voir section Validation) avant toute configuration dans l’interface.
3. Ouvrir le vSphere Client > Administration > Single Sign On > Configuration > onglet Identity Provider > Identity Sources > Add.
4. Choisir le type « Active Directory over LDAP ».
5. Renseigner les parametres : nom de domaine, alias (NetBIOS), Base DN utilisateurs et groupes, compte de bind au format UPN ou DN, mot de passe.
6. Forcer LDAPS : dans les URL de serveur, saisissez ldaps://dc01.domaine.exemple.test:636 (et un second DC pour la redondance). Cochez l’option de connexion securisee.
7. Importer la chaine CA (fichier PEM) dans le champ certificat de la source d’identite.
8. Valider et enregistrer. vCenter teste le bind ; une erreur ici signale un probleme TLS, DNS, DN ou credentials.
9. Affecter les droits : Administration > Access Control > Global Permissions > ajoutez un groupe AD (ex. vSphere-Admins) avec le role approprie.
10. (Optionnel) Definir la source par defaut si vous voulez que le domaine AD soit propose en premier a la connexion.

Le script

Export de la chaine CA en PEM depuis un hote Windows disposant du certificat racine, puis validation TLS/LDAPS depuis le VCSA. Valeurs generiques a adapter.

# ====== PowerShell (hote Windows) : exporter la chaine CA au format PEM ======
# Prerequis : certificat racine present dans le magasin de l'ordinateur local

# 1. Identifier le certificat de la CA racine
$ca = Get-ChildItem -Path Cert:\LocalMachine\Root |
      Where-Object { $_.Subject -like "*CA-Racine-Exemple*" } |
      Select-Object -First 1

# 2. Exporter en Base64 (.cer PEM-compatible)
$bytes  = $ca.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
$base64 = [System.Convert]::ToBase64String($bytes, 'InsertLineBreaks')
$pem    = "-----BEGIN CERTIFICATE-----`r`n$base64`r`n-----END CERTIFICATE-----"
$pem | Out-File -FilePath "C:\temp\ca-chain.pem" -Encoding ascii

Write-Host "Chaine exportee vers C:\temp\ca-chain.pem"
# Repeter pour chaque CA intermediaire (magasin Intermediate Certification Authorities)
# et concatener tous les blocs BEGIN/END dans un seul fichier ca-chain.pem.

# ====== Shell (SSH sur le VCSA, compte root) : valider LDAPS avant config ======
# Variables generiques
DC="dc01.domaine.exemple.test"
PORT=636
BASE_DN="DC=domaine,DC=exemple,DC=test"
BIND_DN="svc-vcenter-ldap@domaine.exemple.test"

# 1. Resolution DNS du controleur de domaine
nslookup "$DC"

# 2. Verifier le certificat presente par le DC sur le port LDAPS
#    (affiche la chaine ; verifier l'emetteur = votre CA et la validite)
echo | openssl s_client -connect "${DC}:${PORT}" -showcerts 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# 3. Test de bind LDAPS reel (saisie du mot de passe demandee avec -W)
#    Un code "result: 0 Success" et des entrees retournees = OK
ldapsearch -H "ldaps://${DC}:${PORT}" \
  -D "$BIND_DN" -W \
  -b "$BASE_DN" \
  -s sub "(sAMAccountName=svc-vcenter-ldap)" dn

# ====== Astuce : forcer la confiance CA pour le test ldapsearch ======
# Si le bind echoue avec "Can't contact LDAP server" / erreur TLS,
# pointer ldapsearch vers votre chaine PEM :
LDAPTLS_CACERT=/root/ca-chain.pem \
ldapsearch -H "ldaps://${DC}:636" -D "$BIND_DN" -W -b "$BASE_DN" "(objectClass=user)" dn | head

Validation

• Handshake TLS : openssl s_client doit afficher l’emetteur correspondant a votre CA et un Verify return code: 0 (ok) si la chaine est fournie.
• Bind LDAP : ldapsearch renvoie result: 0 Success et au moins une entree dn:.
• Enregistrement vCenter : la source d’identite apparait dans la liste sans erreur.
• Test de connexion end-to-end : deconnectez-vous, reconnectez-vous avec un compte AD membre du groupe autorise (utilisateur@domaine.exemple.test). La session doit s’ouvrir avec les privileges attendus.
• Resolution de groupe : dans Global Permissions, verifiez que le groupe AD est resolu (pas affiche comme SID non resolu).

Plan de retour (rollback)

1. Conserver l’acces local SSO : avant toute modification, verifiez que vous disposez d’un compte administrator@vsphere.local fonctionnel. C’est votre filet de securite.
2. Supprimer la source d’identite fautive : Single Sign On > Identity Sources > selectionnez la source AD > Remove. L’authentification AD cesse immediatement, les comptes locaux restent valides.
3. Retirer les Global Permissions pointant vers des groupes AD si elles creent des conflits.
4. Snapshot VCSA : pour un changement a risque, prenez un snapshot du VCSA avant intervention et revenez dessus en cas de corruption de la configuration SSO. Supprimez le snapshot apres validation (ne jamais le laisser en production prolongee).

Depannage

Securite, changement et bonnes pratiques

• Moindre privilege : le compte de bind ne doit avoir que le droit de lecture de l’annuaire. Ne jamais reutiliser un compte admin de domaine.
• Gestion du secret : stockez le mot de passe du compte de service dans un coffre (PAM/secret manager), documentez la rotation. Ne le laissez pas dans un script ou un ticket.
• LDAPS obligatoire : interdisez le port 389 ; verifiez periodiquement que la source utilise bien ldaps://. Contre-mesure directe a T1557.
• Redondance : declarez au moins deux controleurs de domaine dans les URL serveur pour eviter un point de defaillance unique a l’authentification.
• Surveillance d’expiration : le certificat du DC et de la CA expirent. Ajoutez une alerte avant echeance — une CA expiree casse tous les binds d’un coup.
• Cadrage ITIL : traitez cette operation comme un changement normal si elle affecte l’authentification d’un vCenter de production (impact potentiel sur l’acces de toutes les equipes), ou standard si pre-approuvee et documentee. Soumettez au CAB pour un vCenter critique, planifiez une fenetre de maintenance, et consignez le rollback (compte local + snapshot) dans la fiche de changement. Rattachez tout dysfonctionnement subsequent a la gestion des incidents, et un defaut recurrent (ex. expiration CA non surveillee) a la gestion des problemes.

A retenir

Configurer l’authentification AD via LDAPS dans vCenter repose sur trois piliers : une chaine de certificats CA valide, un compte de bind en lecture seule, et une validation TLS prealable depuis le VCSA avant de toucher a l’interface. Le trio openssl/ldapsearch/test de connexion end-to-end vous evite les retours en arriere dans le noir. Gardez toujours un compte administrator@vsphere.local operationnel comme filet de securite.

Documentez la procedure et la date d’expiration des certificats dans votre CMDB, puis integrez cette configuration a votre standard de deploiement vCenter pour la rendre reproductible sur l’ensemble du parc.