Aller au contenu

Authentification AD, LDAP, OpenID Connect, 2FA (TOTP, WebAuthn)

Day 1 · DéployerNiveau 2 · OpérerProcédureRédigé · à valider en lab

Objectif : brancher Proxmox VE sur l'annuaire de l'entreprise (Active Directory, LDAP ou fournisseur OpenID Connect), synchroniser les groupes, puis imposer un second facteur aux administrateurs.

Les realms disponibles

Realm Type Qui vérifie le mot de passe Synchronisation Usage conseillé
pam Linux PAM Le nœud (comptes Linux) Non root@pam de secours uniquement
pve Proxmox VE PVE (/etc/pve/priv/shadow.cfg) Non Comptes locaux, comptes de service
AD ad Contrôleur de domaine Oui (pveum realm sync) Parc Windows
LDAP ldap Annuaire LDAP (OpenLDAP, FreeIPA…) Oui Parc Linux
OpenID Connect openid Fournisseur d'identité (Entra ID, Keycloak, Authentik…) Non (création à la volée) SSO, MFA porté par l'IdP

Les comptes @pam doivent exister sous Linux sur chaque nœud. C'est la raison principale de privilégier un annuaire.

Avant de toucher la prod

  • Une session root@pam reste ouverte dans un autre navigateur pendant toute la procédure.
  • Compte de liaison (bind) dédié en lecture seule dans l'annuaire, mot de passe au coffre.
  • Connexion chiffrée possible : LDAPS (636) ou StartTLS, certificat de l'annuaire reconnu par les nœuds.
  • Flux ouverts depuis tous les nœuds pve01, pve02, pve03 vers les contrôleurs de domaine.
  • Groupe AD cible défini (ex. GG-Proxmox-Admins) et droit PVE prévu, voir modèle de droits.
  • Pour WebAuthn : accès GUI par FQDN avec certificat valide, voir durcissement.

Étapes

1. Ajouter le realm

  1. Datacenter → Permissions → Realms → Add → Active Directory Server (ou LDAP Server, OpenID Connect Server).
  2. Onglet General : Realm ad-corp, Domain corp.local, Server dc01.corp.local, Fallback dc02.corp.local, Mode LDAPS, Verify Certificate coché.
  3. Onglet Sync Options : Bind User CN=svc-proxmox,OU=Services,DC=corp,DC=local, son mot de passe, Group Filter limité aux groupes Proxmox, Scope Users and Groups, Remove Vanished coché pour ACL, Entry et Properties.
  4. Default : ne cocher que si le realm doit être présélectionné à la connexion.
pveum realm add ad-corp --type ad --domain corp.local \
  --server1 dc01.corp.local --server2 dc02.corp.local \
  --mode ldaps --verify 1 \
  --bind-dn "CN=svc-proxmox,OU=Services,DC=corp,DC=local" --password '<mot-de-passe-bind>' \
  --base-dn "DC=corp,DC=local" \
  --group-filter "(cn=GG-Proxmox-*)" \
  --sync-defaults-options "scope=both,remove-vanished=acl;entry;properties"

Pour OpenID Connect (le client est déclaré au préalable dans l'IdP avec l'URL de redirection https://pve01.corp.local:8006) :

pveum realm add sso --type openid \
  --issuer-url https://idp.corp.local/realms/infra \
  --client-id proxmox --client-key '<secret>' \
  --username-claim email --autocreate 1

2. Synchroniser utilisateurs et groupes (AD/LDAP)

Realms → sélectionner ad-corp → Sync, cocher Preview pour un essai à blanc, puis relancer sans Preview. Pour une synchronisation régulière : Datacenter → Permissions → Realms → Realm Sync Jobs → Add.

pveum realm sync ad-corp --dry-run 1    # aperçu
pveum realm sync ad-corp
pveum group list | grep ad-corp         # groupes importés : <nom>-ad-corp

Les groupes synchronisés reçoivent le suffixe du realm (GG-Proxmox-Admins-ad-corp). Poser ensuite l'ACL :

pveum acl modify / --group GG-Proxmox-Admins-ad-corp --role Administrator

3. Activer le second facteur

Facteur Configuré par Remarque
TOTP L'utilisateur (application d'authentification) Simple, sans matériel
WebAuthn L'utilisateur (clé FIDO2, Windows Hello…) Résiste à l'hameçonnage, exige FQDN + certificat valide
Clés de récupération L'utilisateur Jeu de codes à usage unique, à imprimer et mettre au coffre
TOTP ou Yubico OTP imposé par realm L'administrateur, au niveau du realm Les utilisateurs sans facteur ne peuvent plus se connecter
  1. Pour WebAuthn, une fois : Datacenter → Options → WebAuthn Settings, renseigner Name, Origin https://pve01.corp.local:8006 et ID pve01.corp.local (le bouton Auto-fill reprend l'URL courante).
  2. Chaque administrateur : menu utilisateur en haut à droite → TFA (ou Datacenter → Permissions → Two Factor → Add), ajouter TOTP ou WebAuthn, puis générer les clés de récupération.
  3. Pour imposer le facteur à tout un realm : éditer le realm, champ Require TFA.
pveum user tfa list                     # facteurs déclarés par utilisateur
pveum user tfa unlock jdupont@ad-corp   # déverrouiller après trop d'échecs
pveum realm modify ad-corp --tfa type=oath   # imposer TOTP au realm

Avec OpenID Connect, le second facteur est en général porté par l'IdP : ne pas empiler un TOTP PVE en plus.

Vérifications

  • Connexion dans une fenêtre privée avec jdupont@ad-corp : la page demande le second facteur, puis affiche uniquement les objets autorisés.
  • pveum user permissions jdupont@ad-corp liste les privilèges attendus sur /.
  • pveum user list montre les comptes synchronisés avec le realm ad-corp.
  • journalctl -u pvedaemon --since "10 min ago" ne contient pas d'échec authentication failure inexpliqué.

Rollback

Le compte root@pam n'est pas concerné par le realm AD : il reste toujours utilisable. Pour revenir en arrière, supprimer l'ACL du groupe, puis le realm (pveum realm delete ad-corp). Un administrateur bloqué par la 2FA : pveum user tfa unlock ou suppression de son facteur dans Permissions → Two Factor par un autre administrateur.

Pièges vus en support

  • Mode LDAP en clair sur le port 389 : le mot de passe de chaque utilisateur circule en clair. Toujours LDAPS ou StartTLS.
  • Certificat de l'AD signé par une PKI interne non installée sur les nœuds : échec TLS. Ajouter la CA dans /usr/local/share/ca-certificates/ puis update-ca-certificates sur chaque nœud.
  • Remove Vanished non coché : un salarié retiré de l'AD garde son compte et ses ACL dans PVE.
  • WebAuthn enregistré en accédant par IP : la clé ne fonctionne plus une fois l'accès par FQDN mis en place. Fixer FQDN et certificat avant.
  • Pas de clés de récupération générées : téléphone perdu = compte bloqué. Après 8 échecs TOTP, ce facteur est verrouillé ; seule une clé de récupération ou un administrateur le débloque.
  • 2FA imposée au realm pam : le compte root@pam de secours peut devenir inutilisable en urgence. Le MSP doit disposer de son propre accès documenté.

Quand ouvrir un ticket iTop

Plus aucun administrateur ne peut se connecter (realm cassé, 2FA perdue, root@pam inconnu) : P2, le MSP intervient en console. Intégration OIDC avec un IdP particulier, PKI interne : P4 demande de service. Joindre la configuration du realm (cat /etc/pve/domains.cfg) sans mot de passe.

Ouvrir un ticket iTop

Pour aller plus loin