Échecs de connexion Proxmox LDAP/AD : où se rompt la chaîne d’authentification et comment la réparer

octobre 9, 2025 • février 3, 2026 • Lecture : 29 min • Views: 6

Cet article vous a aidé ?

Quand la connexion LDAP/AD sur Proxmox échoue, vous n’avez pas « un problème LDAP ». Vous avez une chaîne cassée : résolution de nom, réseau, TLS, bind, recherche, résolution des groupes, mappage utilisateur, permissions, puis enfin la pile d’authentification propre à Proxmox. Un maillon faible et l’interface affiche « authentication failure » comme si elle vous faisait une faveur.

Ce guide parcourt la chaîne dans l’ordre où elle casse en production, avec des commandes à lancer maintenant, ce que signifient les sorties, et quelle décision prendre ensuite. Pas de viande mystère. Pas de « essayez de redémarrer » comme philosophie.

La chaîne d’authentification : ce que fait vraiment Proxmox lorsque vous vous connectez

Proxmox VE (PVE) n’a pas un seul sous-système d’authentification. C’est un ensemble de domaines (realms) plus un modèle de permissions et un peu de colle. Si vous ne comprenez pas la colle, vous réparerez le mauvais niveau et le fameux « ça marche sur mon poste » vous mènera à une panne.

Étape 0 : Quel realm utilisez-vous réellement ?

Proxmox supporte des realms tels que :

pam : comptes Linux locaux authentifiés via PAM (qui peuvent être soutenus par LDAP/SSSD, mais c’est une autre chaîne).
pve : utilisateurs Proxmox locaux stockés dans /etc/pve/user.cfg.
ldap : annuaire externe via LDAP (OpenLDAP, AD via LDAP).
ad : type de realm Active Directory (toujours LDAP en dessous, mais avec des paramètres AD-typiques comme la gestion des groupes).

Les utilisateurs se connectent en tant que user@realm. Si votre équipe continue de taper user@pam par habitude, vous pouvez tuner LDAP jusqu’à la fin des temps et ça n’aidera pas.

Étape 1 : PVE peut-il atteindre le service d’annuaire ?

Avant l’authentification, Proxmox doit résoudre les noms des DC/LDAP, router jusqu’à eux et ouvrir une connexion TCP. Pour AD, cela signifie souvent choisir le bon DC (ou plusieurs) et ne pas être trompé par le DNS.

Étape 2 : TLS (LDAPS ou StartTLS) réussit ou pas

LDAP sur TLS est le premier endroit où « ça marche en test » meurt en prod. Certificats, SNI, SANs, chaînes intermédiaires et horloges comptent tous. Si LDAPS échoue, Proxmox rapporte souvent une erreur d’authentification parce que le bind n’a jamais eu lieu.

Étape 3 : Le bind fonctionne

Proxmox peut se lier (bind) en tant que :

anonyme (rarement autorisé en AD ; souvent désactivé sur un LDAP durci).
compte de service (cas courant ; utilisé pour rechercher utilisateurs et groupes).
bind direct utilisateur (DN utilisateur dérivé depuis un modèle, puis bind en tant qu’utilisateur).

Un bind réussi prouve les identifiants et (souvent) que la négociation TLS s’est bien passée.

Étape 4 : La recherche trouve l’entrée utilisateur

C’est là que base DN et filtres importent. Si la recherche ne retourne aucune entrée, Proxmox ne peut pas mapper le nom d’utilisateur que vous avez tapé à un DN, et vous obtiendrez « login failed » même si le mot de passe est correct.

Étape 5 : Le mappage groupe/rôle décide de ce que vous pouvez faire

Même si l’authentification réussit, l’autorisation peut échouer d’une manière qui ressemble à un échec d’authentification (par ex., vous « vous connectez » mais ne voyez rien ; ou des appels API retournent 401/403). Les permissions Proxmox sont de type RBAC et séparées de l’authentification. L’appartenance à des groupes AD doit être mappée aux groupes/rôles Proxmox, sinon vous aurez créé une identité magnifique sans aucun droit—comme émettre un badge qui n’ouvre aucune porte.

Étape 6 : Cohérence de la configuration du cluster Proxmox

Proxmox stocke la config d’auth dans le système de fichiers du cluster (/etc/pve). Si le cluster est partitionné ou si un nœud est dans un état étrange, un nœud peut avoir une config de realm que les autres n’ont pas. Alors seules « certaines connexions » échouent, ce qui est la catégorie d’incident préférée de tout le monde.

Une idée paraphrasée de Werner Vogels (CTO Amazon) : « Vous le construisez, vous l’exploitez. » Si vous l’exploitez, vous devez le déboguer sans conjectures.

Playbook de diagnostic rapide (vérifier d’abord/deuxième/troisième)

Ceci est l’ordre qui réduit le temps pour atteindre la vérité. C’est volontairement ennuyeux. L’ennui est rapide.

Premier : identifier le realm et reproduire depuis le CLI

Confirmez le format du nom d’utilisateur (alice@ad vs alice@ldap vs alice@pam).
Utilisez le CLI Proxmox pour valider que la config du realm existe sur le nœud gérant la connexion.
Testez le bind/la recherche LDAP depuis le nœud avec ldapsearch (ou openssl s_client pour TLS).

Deuxième : prouver le réseau + DNS + l’heure

Le DNS résout correctement les DC depuis le nœud Proxmox.
Le TCP se connecte sur 389/636 et il n’y a pas de firewall/NAT étrange.
Le décalage horaire est raisonnable (TLS et Kerberos n’aiment pas le voyage temporel).

Troisième : valider le bind DN, base DN, filtre utilisateur et attributs de groupe

Les identifiants de bind sont corrects et non verrouillés/expirés.
Le base DN est correct et inclut les objets utilisateur attendus.
Le filtre utilisateur correspond au schéma de l’annuaire (différences AD vs OpenLDAP).
Les attributs d’appartenance aux groupes correspondent à ce que Proxmox attend pour votre type de realm.

Quatrième : confirmer le mappage d’autorisation dans Proxmox

L’utilisateur est présent dans le mappage utilisateur/groupe de Proxmox (ou auto-provisionné si configuré).
Les rôles et ACL accordent au moins PVEAuditor ou équivalent où nécessaire.

Cinquième : escaladez vers les logs et la capture de paquets

Lisez les logs de pveproxy et pvedaemon pour la chaîne d’erreur exacte.
Utilisez tcpdump pour confirmer la poignée de main TLS et voir si des binds ont lieu.

Discipline en une phrase : ne touchez pas à Proxmox tant que vous ne pouvez pas reproduire l’échec avec ldapsearch depuis le nœud en échec.

Faits intéressants et contexte (pourquoi c’est plus casse-tête qu’il ne devrait l’être)

Fait 1 : LDAP date du début des années 1990 comme alternative « légère » à X.500. « Léger » est depuis devenu un trait de personnalité, pas une garantie.
Fait 2 : Active Directory parle LDAP, mais ce n’est pas « juste LDAP ». AD mélange LDAP avec Kerberos, enregistrements DNS SRV et comportements de politique qui surprennent ceux habitués à OpenLDAP.
Fait 3 : LDAPS (LDAP sur 636) a historiquement concurrencé StartTLS (LDAP + upgrade). Beaucoup d’entreprises utilisent encore les deux, selon l’ancienneté du client.
Fait 4 : L’appartenance aux groupes AD est souvent récupérée depuis l’attribut memberOf, mais les groupes imbriqués requièrent une logique supplémentaire (ou des règles de correspondance) que tous les clients n’implémentent pas de la même façon.
Fait 5 : Microsoft a renforcé les comportements LDAP d’AD au fil du temps (signing, channel binding, dépréciation des chiffrements faibles). Une mise à jour Proxmox peut « casser LDAP » alors que c’est en réalité le DC qui applique une sécurité moderne.
Fait 6 : Les certificats échouent plus souvent à cause de mismatch de nom que pour la cryptographie elle-même. Les humains excellent à mal nommer les choses, surtout sous pression.
Fait 7 : Le système de fichiers du cluster Proxmox (pmxcfs) rend la config d’auth cohérente—jusqu’à ce que le cluster soit malade, où la cohérence devient une suggestion polie.
Fait 8 : Beaucoup d’erreurs « invalid credentials » LDAP sont en réalité « bind DN introuvable » ou « compte verrouillé », car les serveurs retournent volontairement des erreurs vagues pour éviter de divulguer des informations.

Tâches pratiques : commandes, sorties, décisions (12+)

Exécutez celles-ci sur le nœud Proxmox où la connexion échoue. Si vous avez un cluster derrière un load balancer, ce détail importe plus que personne ne veut l’admettre.

Tâche 1 : Lister les realms configurés et vérifier que le bon existe

cr0x@server:~$ pveum realm list
Realm    Type  Comment
pam      pam
pve      pve
ad       ad    Corporate AD

Ce que ça signifie : Le realm ad existe sur ce nœud. S’il n’existe pas, vous déboguez le mauvais nœud ou la config du cluster n’est pas cohérente.

Décision : Si le realm manque sur un nœud, réparez la santé du cluster ou recréez le realm depuis un nœud sain. N’ajoutez pas « juste localement » ; Proxmox veut cela dans /etc/pve.

Tâche 2 : Afficher la config du realm (vérifier bind DN, base DN, serveur)

cr0x@server:~$ pveum realm config ad
base_dn          dc=corp,dc=example,dc=com
bind_dn          svc_pve@corp.example.com
capath           /etc/ssl/certs
default          0
domain           corp.example.com
group_classes    group
password         **********
port             636
secure           1
server1          dc01.corp.example.com
user_attr        sAMAccountName

Ce que ça signifie : C’est ce que Proxmox utilisera. Faites attention à server1, port, secure, base_dn et à l’attribut utilisateur.

Décision : Si server1 est un nom court sans SAN correspondant dans le certificat, attendez des échecs TLS. Utilisez un FQDN qui correspond au certificat.

Tâche 3 : Vérifier la résolution DNS (et attraper les domaines de recherche « utiles »)

cr0x@server:~$ getent hosts dc01.corp.example.com
10.10.10.11   dc01.corp.example.com

Ce que ça signifie : Le nœud résout le DC. S’il résout vers une IP différente de celle attendue, vous pouvez atteindre le mauvais DC ou un enregistrement obsolète.

Décision : Si la résolution est erronée, corrigez /etc/resolv.conf (ou systemd-resolved), pas Proxmox. L’authentification dépend d’un DNS correct.

Tâche 4 : Confirmer la connectivité TCP vers LDAP/LDAPS

cr0x@server:~$ nc -vz dc01.corp.example.com 636
Connection to dc01.corp.example.com 636 port [tcp/ldaps] succeeded!

Ce que ça signifie : Le chemin réseau est ouvert. Si ça échoue, arrêtez et corrigez le routage/firewall d’abord.

Décision : Si 636 est bloqué mais 389 fonctionne, décidez si vous pouvez utiliser StartTLS sur 389 ou si vous devez ouvrir 636.

Tâche 5 : Inspecter la poignée de main TLS et les noms de certificats

cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = dc01.corp.example.com
issuer=CN = Corp Issuing CA 01, O = Corp
notBefore=Oct  1 00:00:00 2025 GMT
notAfter=Oct  1 00:00:00 2027 GMT
X509v3 Subject Alternative Name:
    DNS:dc01.corp.example.com, DNS:dc01

Ce que ça signifie : Le certificat correspond au nom utilisé. Si le SAN n’inclut pas le FQDN, Proxmox peut refuser TLS (selon les réglages).

Décision : Si les noms ne correspondent pas, utilisez le nom qui correspond au certificat ou corrigez le certificat. Ne désactivez pas la vérification sauf si vous aimez les incidents évitables.

Tâche 6 : Valider la chaîne CA que Proxmox fait confiance

cr0x@server:~$ openssl verify -CApath /etc/ssl/certs <(openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com /dev/null | openssl x509)
stdin: OK

Ce que ça signifie : Le nœud fait confiance à la chaîne de l’autorité émettrice.

Décision : Si cela échoue, installez votre CA d’entreprise dans le magasin de confiance de l’OS et mettez à jour les certificats. Corrigez la confiance une fois, pas par bidouilles applicatives.

Tâche 7 : Prouver que le bind fonctionne avec ldapsearch (compte de service)

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' -s base '(objectClass=*)' defaultNamingContext
Enter LDAP Password:
dn:
defaultNamingContext: DC=corp,DC=example,DC=com

Ce que ça signifie : TLS fonctionne, le bind fonctionne, le base DN est accessible.

Décision : Si vous obtenez Invalid credentials (49), vérifiez le format de l’identité de bind. AD accepte souvent UPN (user@domain) ou DN complet ; choisissez-en un et soyez cohérent.

Tâche 8 : Chercher l’entrée utilisateur de la même façon que Proxmox

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(sAMAccountName=alice)' dn sAMAccountName userPrincipalName memberOf
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com
sAMAccountName: alice
userPrincipalName: alice@corp.example.com
memberOf: CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com
memberOf: CN=VM-Operators,OU=Groups,DC=corp,DC=example,DC=com

Ce que ça signifie : L’utilisateur existe et peut être trouvé via l’attribut choisi.

Décision : Si la recherche ne retourne rien, corrigez base_dn et le filtre/attribut utilisateur. Ne touchez pas aux mots de passe ; ils sont innocents jusqu’à preuve du contraire.

Tâche 9 : Vérifier les groupes imbriqués si votre RBAC en dépend

cr0x@server:~$ ldapsearch -H ldaps://dc01.corp.example.com:636 -D 'svc_pve@corp.example.com' -W -b 'dc=corp,dc=example,dc=com' '(&(objectClass=user)(sAMAccountName=alice)(memberOf:1.2.840.113556.1.4.1941:=CN=PVE-Admins,OU=Groups,DC=corp,DC=example,DC=com))' dn
Enter LDAP Password:
dn: CN=Alice Nguyen,OU=Users,DC=corp,DC=example,DC=com

Ce que ça signifie : La « matching rule in chain » d’AD confirme l’appartenance imbriquée. Si vous avez besoin de groupes imbriqués et que votre configuration ne les prend pas en compte, l’autorisation sera incohérente.

Décision : Décidez si vous supportez les groupes imbriqués (alors testez-le délibérément) ou imposez « pas d’imbrication pour les groupes PVE » pour garder un comportement prévisible.

Tâche 10 : Inspecter les logs Proxmox pendant une tentative de connexion

cr0x@server:~$ journalctl -u pveproxy -u pvedaemon --since "10 minutes ago" | tail -n 30
Dec 26 09:40:12 pve01 pveproxy[2211]: authentication failure; rhost=10.10.20.55 user=alice@ad msg=ldap_bind: Invalid credentials (49)
Dec 26 09:40:12 pve01 pvedaemon[2198]: user authentication failed: alice@ad

Ce que ça signifie : Proxmox est allé jusqu’au bind (ou a essayé) et a reçu une erreur LDAP. La chaîne d’erreur est votre boussole.

Décision : Si vous voyez des erreurs TLS (handshake/verify), arrêtez de regarder la config utilisateur et corrigez la confiance/certificats/heure.

Tâche 11 : Forcer une synchronisation du realm et observer

cr0x@server:~$ pveum realm sync ad
syncing users
syncing groups
OK

Ce que ça signifie : Proxmox peut interroger les objets de l’annuaire en utilisant la config du realm. S’il échoue, il affichera généralement une erreur LDAP significative.

Décision : Si la sync fonctionne mais que la connexion interactive échoue, suspectez un décalage d’attributs utilisateur, un problème de mot de passe, ou une sélection de realm au moment de la connexion.

Tâche 12 : Vérifier que l’utilisateur existe dans la vue de Proxmox et voir les permissions

cr0x@server:~$ pveum user list | grep -E 'alice@ad|userid'
alice@ad

Ce que ça signifie : Proxmox connaît l’utilisateur. Cela ne garantit pas les permissions, seulement le mappage d’identité.

Décision : Si l’utilisateur n’est pas listé et que vous dépendez de la sync, corrigez les filtres de sync. Si vous ne dépendez pas de la sync, décidez de gérer les utilisateurs PVE localement ou via la sync—choisissez et documentez.

Tâche 13 : Vérifier les ACL (parce que « la connexion marche » mais l’UI vide reste un échec)

cr0x@server:~$ pveum acl list | grep -i alice
/ - user alice@ad - role PVEAuditor

Ce que ça signifie : L’utilisateur a au moins un rôle assigné à la racine. Si cela manque, l’utilisateur peut s’authentifier mais ne rien voir.

Décision : Si vous voulez des droits pilotés par AD, assignez des rôles aux groupes, pas aux utilisateurs individuels, et gardez la liste ACL maintenable.

Tâche 14 : Vérifier le mappage des groupes AD vers Proxmox

cr0x@server:~$ pveum group list
Administrators
VMOperators

Ce que ça signifie : Ce sont des groupes Proxmox (pas forcément des groupes AD). Vous devez mapper les groupes AD aux groupes Proxmox ou utiliser des ACL directes contre des utilisateurs.

Décision : Si votre organisation s’attend à ce que « le groupe AD accorde des droits Proxmox », implémentez ce mappage explicitement. Les attentes ne sont pas des configurations.

Tâche 15 : Vérifier la santé du filesystem du cluster (la config d’auth en dépend)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-26 09:42:33
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.12
Quorate:          Yes

Ce que ça signifie : Le cluster a le quorum et la configuration devrait être cohérente. Si pas de quorum, attendez-vous à des bizarreries incluant des configs d’auth obsolètes.

Décision : Si le quorum est perdu, arrêtez les manipulations d’auth et réparez d’abord le cluster.

Tâche 16 : Preuve au niveau paquet quand tout « a l’air bien »

cr0x@server:~$ tcpdump -i vmbr0 -nn host 10.10.10.11 and port 636 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:43:10.120345 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7], length 0
09:43:10.120611 IP 10.10.10.11.636 > 10.10.10.21.49122: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 200 ecr 100,nop,wscale 7], length 0
09:43:10.120744 IP 10.10.10.21.49122 > 10.10.10.11.636: Flags [.], ack 1, win 502, options [nop,nop,TS val 101 ecr 200], length 0

Ce que ça signifie : SYN/SYN-ACK/ACK prouve la connectivité. Si vous ne voyez pas de trafic pendant les tentatives de connexion, votre nœud Proxmox n’essaie même pas d’atteindre l’annuaire—mauvais realm, mauvais nœud, ou config non appliquée.

Décision : Si les paquets circulent mais que l’authentification échoue encore, concentrez-vous sur TLS/bind/recherche plutôt que sur le routage.

Où ça casse : modes d’échec par couche

Couche 1 : UI et sélection du realm (le problème de la « mauvaise porte »)

L’écran de connexion Proxmox a un menu déroulant de realm. Les utilisateurs choisissent le mauvais realm. Ils choisissent toujours le mauvais realm. Si vous avez à la fois pam et ad activés, « pam » gagnera le concours de popularité car ça sonne familier.

Correction : Définissez un realm par défaut clair, communiquez-le, et envisagez de restreindre les connexions locales aux comptes de secours (break-glass).

Blague #1 : LDAP est le seul protocole où « Invalid credentials » peut signifier « votre mot de passe est faux », « votre compte est verrouillé », ou « la Lune est en rétrograde ».

Couche 2 : DNS et sélection des DC (catastrophique en silence)

AD dépend du DNS. Si vos nœuds Proxmox n’utilisent pas le DNS intégré AD (ou au moins ne peuvent pas le résoudre correctement), vous pouvez obtenir :

Des résolutions renvoyant un DC déconstruit.
De la confusion split-horizon où des noms internes se résolvent extérieurement.
L’ajout de domaines de recherche transformant dc01 en dc01.lab.example.com.

Correction : Utilisez des FQDN dans la config du realm. Assurez-vous que les nœuds Proxmox utilisent les bons résolveurs. Ne comptez pas sur les domaines de recherche pour « aider ». Ils aident comme un chat aide à résoudre un puzzle.

Couche 3 : Heure (TLS et Kerberos s’en soucient)

Même si vous utilisez des binds LDAP (pas Kerberos), la validation de certificat TLS dépend du temps. Le décalage d’horloge génère des erreurs « certificat non encore valide » ou « expiré » qui ressemblent à des échecs TLS.

Correction : Rendez NTP ennuyeux et redondant. Si vos nœuds ne peuvent pas garder l’heure, votre pile d’auth devient un élément décoratif.

Couche 4 : Confiance TLS et identité du certificat

La plupart des déploiements AD en entreprise utilisent une PKI interne. Si Proxmox ne fait pas confiance à votre CA, LDAPS échoue. Si vous vous connectez à dc01 mais que le certificat dit dc01.corp.example.com, LDAPS échoue. Si la chaîne manque un intermédiaire, LDAPS échoue. Si la politique TLS change sur le DC, les clients plus anciens échouent.

Correction : Mettez votre CA dans le magasin de confiance de l’OS. Utilisez des noms qui correspondent aux SAN. Gardez la chaîne intacte. Préférez des politiques TLS modernes, mais testez-les avec vos vrais clients, pas vos espoirs.

Couche 5 : Formats d’identité de bind (UPN vs DN vs DOMAIN\user)

AD accepte plusieurs formes, mais pas toujours dans les mêmes contextes. La config de realm Proxmox peut utiliser le style UPN (svc_pve@corp.example.com) ou DN complet (CN=svc_pve,OU=Service Accounts,...). Si votre compte de service a déménagé d’un OU et que vous avez codé en dur le DN, vous aurez des échecs de bind. Si le mot de passe a changé et que personne n’a mis à jour Proxmox, vous aurez des échecs de bind.

Correction : Utilisez le UPN pour les comptes de service quand possible (moins couplé aux OU). Documentez la propriété de ce secret. Faites-en la rotation avec un plan, pas à l’instinct.

Couche 6 : Base DN et filtres (l’argument « l’utilisateur existe, je le jure »)

Les gens définissent base_dn trop étroit (un seul OU) puis ajoutent des utilisateurs ailleurs. Ou ils copient un filtre d’un exemple OpenLDAP dans AD et s’étonnent que uid ne matche rien.

Correction : Mettez le base DN à la racine du domaine sauf si vous avez une bonne raison. Si vous devez restreindre, incluez tous les OU pertinents et maintenez cela.

Couche 7 : Résolution de l’appartenance aux groupes (groupes imbriqués, choix d’attribut)

Vous pouvez vous authentifier sans résolution correcte des groupes, mais vous ne pouvez pas autoriser correctement. Les groupes imbriqués AD sont un piège classique : l’utilisateur montre memberOf seulement pour les appartenances directes. Votre politique dit « PVE-Admins » mais les utilisateurs sont membres par imbrication. La moitié de l’équipe a accès, l’autre moitié non, et tout le monde blâme Proxmox.

Correction : Décidez si vous autorisez les groupes imbriqués. Si oui, testez délibérément leur résolution. Si non, imposez-le par gouvernance d’annuaire.

Couche 8 : Permissions Proxmox et tokens (auth vs authz)

La connexion Proxmox est séparée des permissions. Un utilisateur peut s’authentifier et ne toujours rien voir. Aussi : les tokens API et les sessions utilisateur se comportent différemment des connexions interactives. Ne déboguez pas un échec de token API en changeant les filtres LDAP.

Correction : Donnez aux utilisateurs un rôle minimal au chemin correct. Utilisez des groupes pour les ACL. Gardez des comptes locaux de secours et auditez-les sévèrement.

Couche 9 : Bizarreries de cluster (ça marchait sur node1)

Dans un cluster, il est courant de tester sur un nœud, déclarer victoire, puis être alerté parce que les connexions échouent sur un autre nœud. En général c’est :

Nœud hors quorum, config obsolète.
DNS ou politique firewall différente par nœud.
État du magasin de confiance CA différent (quelqu’un a « corrigé » manuellement une fois).

Correction : Traitez les dépendances d’auth (DNS, CA, heure, firewall) comme de la configuration de gestion de cluster, pas du bricolage artisanal par nœud.

Trois mini-histoires d’entreprise (comment ça foire au travail)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils migraient d’un environnement vSphere legacy vers Proxmox, en plein trimestre, avec le fond sonore habituel des échéances. L’équipe AD a transmis un compte de service en disant « il peut lire les utilisateurs et groupes ». L’équipe Proxmox a supposé que cela signifiait qu’il pouvait lire tous les utilisateurs et groupes du domaine. Ce n’était pas le cas.

Dans AD, la délégation de lecture était limitée à un OU spécifique où « les admins serveurs » vivaient. Le base DN du realm Proxmox était la racine du domaine, donc les recherches ont traversé des zones où ce compte de service n’avait pas de droits. En test, tout le monde qui essayait de se connecter était dans l’OU déléguée. En production, la moitié du NOC était dans un autre OU. La connexion a échoué pour eux, mais pas pour l’ingénieur d’astreinte, ce qui est un type d’erreur particulièrement trompeur.

La première réaction fut prévisible : quelqu’un a changé les filtres utilisateur, puis un autre a désactivé la vérification TLS « temporairement ». Ça n’a rien changé, car le problème n’était ni TLS ni filtres. C’était l’autorisation au sein d’AD pour le compte de bind.

Ils ont résolu en alignant portée et permissions : soit élargir les droits de lecture du compte de service (préférable, avec portée minimale), soit restreindre le base DN à l’OU visé et documenter le couplage. Ils ont fait les deux : restreindre la portée pour l’instant, créer un RFC pour étendre correctement les droits de lecture, et ajouter un test de connexion pour un utilisateur hors de l’OU dans la checklist de déploiement.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Un autre établissement eut l’idée « efficace » : pointer Proxmox vers un seul DC parce que « ça réduit la latence » et simplifie le dépannage. Ils ont choisi le DC dans la même rangée de racks. Tout semblait parfait—jusqu’à la nuit de patchs.

L’équipe Windows a patché ce DC et il a redémarré. Pendant ~12 minutes, LDAP/LDAPS était indisponible. Les nœuds Proxmox ont tenté de s’authentifier ; les connexions ont échoué ; les appels API ont commencé à renvoyer des erreurs ; l’automatisation qui utilisait l’API a recommencé en boucle. La charge est montée partout, y compris sur le DC à son retour, et leur monitoring est passé du rouge à la performance artistique.

Après le choc, ils ont ajouté server2/server3 à la config du realm et retesté. Cela a résolu la disponibilité, mais ils ont découvert un effet secondaire : le DC de secours avait une chaîne de certificats légèrement différente (toujours valide, mais émise par un intermédiaire différent). Certains nœuds Proxmox faisaient confiance à un intermédiaire mais pas à l’autre, parce que quelqu’un avait installé des certificats de façon incohérente au fil du temps.

La solution finale fut peu glamour : standardiser la confiance CA sur tous les nœuds, configurer plusieurs serveurs LDAP, et arrêter d’optimiser pour quelques millisecondes dans un chemin d’auth qui s’exécute des ordres de grandeur moins souvent que les IO de stockage. Ils ont aussi ajouté un runbook de maintenance : patcher les DC un par un et valider LDAPS depuis des clients Linux avant de déclarer la réussite.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation avait l’habitude : chaque changement d’auth venait avec un petit script de test répétable exécuté depuis chaque nœud Proxmox. Rien de fancy—juste résolution DNS, connexion TCP, vérification TLS, ldapsearch bind, et recherche d’utilisateur. Ils versionnaient le script et documentaient les sorties attendues.

Pendant une rotation de CA planifiée, l’équipe CA AD a déployé une nouvelle CA émettrice et a commencé à servir de nouvelles chaînes sur les contrôleurs de domaine. Beaucoup de systèmes ont eu des problèmes. Proxmox n’en a pas eu—parce que l’équipe Proxmox avait déjà déployé la nouvelle CA dans le magasin de confiance de l’OS sur chaque nœud une semaine avant, dans le cadre du plan de changement, avec vérification.

Ce qui ressemblait à de la chance était en réalité une discipline bon marché : « le magasin de confiance est une config gérée », pas « quelque chose à réparer quand ça casse ». Leur auth n’a pas hoqueté, ce qui a permis à leur plateforme de virtualisation de rester ennuyeuse pendant que les autres équipes traitaient des incendies de certificats.

Ça n’a pas rapporté de prix. Ça a évité un week-end. En exploitation d’entreprise, c’est la meilleure récompense.

Erreurs communes : symptôme → cause → correction

1) Symptôme : « Login failed » pour tout le monde ; les logs mentionnent TLS/handshake

Cause : Proxmox ne fait pas confiance à la chaîne de certificats AD/LDAP, ou le hostname ne correspond pas au SAN du certificat.

Correction : Installez la CA d’entreprise dans le magasin de confiance de l’OS, vérifiez avec openssl verify, utilisez un FQDN correspondant au SAN. Évitez de désactiver la vérification sauf si vous voulez que des attaquants se fassent passer pour votre annuaire.

2) Symptôme : « Invalid credentials (49) » même avec le bon mot de passe

Cause : Mauvais format de bind DN, compte de service expiré/verrouillé, ou politique AD bloquant les binds simples sans TLS.

Correction : Confirmez bind DN/UPN, vérifiez l’état du compte dans AD, assurez-vous que LDAPS/StartTLS est utilisé. Validez avec ldapsearch -D ... -W depuis le nœud.

3) Symptôme : Seuls certains utilisateurs peuvent se connecter

Cause : base DN trop étroit, mauvaise portée d’OU, ou compte de service sans droits de lecture sur des parties de l’annuaire.

Correction : Élargissez le base DN de façon appropriée ou ajustez la délégation AD. Testez avec des utilisateurs de différents OU.

4) Symptôme : L’utilisateur peut s’authentifier mais voit une UI vide ou aucun nœud

Cause : ACL/roles Proxmox manquants ; l’authentification a réussi mais l’autorisation a échoué.

Correction : Assignez un rôle au bon chemin (souvent / ou /vms), idéalement via des groupes.

5) Symptôme : Marche sur node1, échoue sur node2

Cause : Cluster pas sain, config non répliquée, ou différences par nœud de DNS/firewall/magasin de confiance.

Correction : Restaurez le quorum/la santé du cluster, standardisez la gestion de configuration des nœuds, vérifiez la config des realms sur chaque nœud.

6) Symptôme : La sync du realm marche, mais la connexion interactive échoue

Cause : Décalage d’attribut utilisateur (par ex. attendre sAMAccountName alors que les utilisateurs se connectent avec UPN), ou utilisateur qui choisit le mauvais realm.

Correction : Alignez le format de connexion utilisateur avec user_attr et les instructions UI. Envisagez de définir un realm par défaut pour réduire les erreurs humaines.

7) Symptôme : Après durcissement sécurité, LDAP casse « aléatoirement »

Cause : Les exigences de signing/channel binding sur AD ont changé, ou la politique TLS s’est durcie, exposant des suppositions anciennes côté client.

Correction : Passez à LDAPS/StartTLS avec une confiance valide, assurez-vous que Proxmox et les bibliothèques sous-jacentes supportent les politiques requises, testez en staging avec les paramètres réels des DC.

8) Symptôme : Les permissions basées sur les groupes ne s’appliquent pas comme prévu

Cause : Groupes imbriqués non résolus, mauvais attribut/classe de groupe configuré, ou DNs de groupes qui ne correspondent pas au mapping Proxmox.

Correction : Décidez de la stratégie pour les groupes imbriqués, validez les requêtes d’appartenance, et maintenez la stabilité des noms/DN des groupes AD (ou mappez via des attributs non ambigus si possible).

Blague #2 : Le moyen le plus rapide de trouver votre point de défaillance unique est de l’« optimiser ». L’authentification est un excellent professeur au mauvais moment.

Listes de contrôle / plan étape par étape (rendez-le ennuyeux)

Checklist A : Quand vous construisez un nouveau realm AD/LDAP

Choisissez le type de realm (ad pour AD, ldap pour LDAP générique). Ne soyez pas trop créatif sauf nécessité.
Utilisez des FQDN pour les serveurs DC/LDAP qui correspondent aux SAN des certificats.
Configurez plusieurs serveurs si disponibles (éliminez la dépendance à un seul DC).
Installez la confiance CA dans le magasin de l’OS sur chaque nœud, de façon cohérente.
Utilisez un compte de service dédié avec le moindre privilège de lecture sur les OU requises.
Définissez le base DN intentionnellement. La racine du domaine est la plus simple ; le périmétrage demande de la gouvernance.
Choisissez le format de connexion (sAMAccountName vs UPN) et alignez user_attr en conséquence.
Décidez la politique sur les groupes imbriqués et testez avec des exemples réels d’utilisateurs.
Définissez le mapping groupe→rôle dans Proxmox et conservez-le dans le contrôle de changement.
Testez depuis chaque nœud (DNS, TCP, TLS, ldapsearch, connexion Proxmox).

Checklist B : Quand les connexions échouent maintenant et que vous êtes de garde

Confirmez le realm utilisé à la connexion et le nœud recevant la requête.
Exécutez pveum realm list et pveum realm config <realm>.
Vérifiez le DNS : getent hosts pour le serveur LDAP configuré.
Vérifiez le TCP : nc -vz vers 636/389.
Vérifiez TLS : openssl s_client et openssl verify.
Exécutez ldapsearch bind et recherche utilisateur avec le même base DN et attribut.
Consultez journalctl -u pveproxy -u pvedaemon autour du moment de l’échec.
Vérifiez les permissions Proxmox : pveum acl list et le mappage de groupes.
Si multi-nœud : vérifiez le quorum du cluster et que la config est cohérente.
Ce n’est qu’ensuite que vous escaladez à la capture de paquets.

Checklist C : Durcissement qui ne vous mordra pas après

Gardez au moins un compte local break-glass Proxmox avec MFA ou contrôles stricts (et auditez son usage).
Standardisez la gestion du magasin de confiance CA sur tous les nœuds (gestion de configuration).
Surveillez l’accessibilité LDAPS et l’expiration des certificats depuis les nœuds Proxmox (pas depuis un sous-réseau de monitoring aléatoire).
Faites la rotation des identifiants de compte de service avec un runbook et un plan de tests.
Restreignez les règles firewall aux DC et ports requis, mais documentez-le.

FAQ

1) Pourquoi Proxmox affiche-t-il « authentication failure » quand le vrai problème est TLS ?

Parce que du point de vue de Proxmox, il n’a pas pu vous authentifier. Le bind n’a jamais eu lieu. Vérifiez toujours les logs et testez TLS séparément avec openssl s_client.

2) Dois-je utiliser le type de realm `ad` ou `ldap` pour Active Directory ?

Utilisez ad sauf raison précise de ne pas le faire. Il aligne mieux les valeurs par défaut (attributs/classes) sur les comportements AD et réduit les pièges de schéma.

3) LDAPS sur 636 ou StartTLS sur 389 ?

Les deux peuvent être sécurisés. Choisissez ce que votre équipe annuaire supporte et ce que votre monitoring peut vérifier de façon fiable. Dans de nombreuses entreprises, 636 est opérationnellement plus simple (séparation claire) mais dépend fortement des certificats.

4) Mon bind DN est un DN complet et ça a cassé après un déplacement d’OU. Comment l’éviter ?

Utilisez une identité bind au format UPN (par ex. svc_pve@corp.example.com) si autorisé. Cela découple votre bind de la structure OU. Traitez aussi les déplacements d’OU comme des changements à impact, pas du « housekeeping ».

5) Les utilisateurs peuvent se connecter, mais les permissions ne reflètent pas les groupes AD. Que manque-t-il ?

L’authentification n’est pas l’autorisation. Vous devez toujours configurer des ACL/roles Proxmox liés à des utilisateurs ou groupes. Si vous voulez un accès piloté par AD, définissez clairement comment les groupes AD mappent aux rôles Proxmox et implémentez cela.

6) Dois-je synchroniser utilisateurs et groupes avec `pveum realm sync` ?

Cela dépend de votre modèle opérationnel. La sync peut faciliter la gestion basée sur les groupes, mais c’est un élément supplémentaire à surveiller. Si vous l’utilisez, monitorisez-la et exécutez-la dans le cadre de changements contrôlés.

7) Pourquoi la connexion marche pour les membres directs d’un groupe mais pas pour les membres imbriqués ?

Parce que memberOf reflète souvent uniquement les appartenances directes. La résolution des groupes imbriqués demande des règles de correspondance spéciales ou l’expansion explicite. Soit supportez et testez les groupes imbriqués, soit interdisez l’imbrication pour les groupes liés à Proxmox.

8) Puis-je « simplement désactiver la vérification de certificat » pour débloquer la situation ?

Vous le pouvez, et vous pouvez aussi enlever votre ceinture de sécurité pour atteindre plus facilement la radio. Si vous désactivez la vérification, vous êtes vulnérable au MITM et à des endpoints d’annuaire malveillants. Corrigez la confiance correctement.

9) Pourquoi ça échoue seulement sur un nœud Proxmox ?

Généralement parce que ce nœud a un DNS, des règles firewall ou un état du magasin de confiance CA différent. Parfois c’est une incohérence de config du cluster due au quorum. Vérifiez les dépendances du nœud et pvecm status.

10) Quelle est la façon la plus propre de séparer le break-glass de l’accès normal ?

Gardez un utilisateur pve local (ou un compte pam strictement contrôlé) pour les urgences, mais exigez un ticket de changement ou un processus audité pour l’utiliser. Utilisez AD pour l’accès courant.

Étapes suivantes à effectuer après que ça marche

Faire marcher LDAP/AD une fois n’est pas l’objectif. Le maintenir fonctionnel lors des changements courants est le travail.

Rédigez un runbook d’une page avec vos paramètres de realm, les formats de connexion supportés, et la commande ldapsearch exacte utilisée pour valider les binds et recherches.
Standardisez les magasins de confiance sur tous les nœuds Proxmox et suivez les rotations CA. Si votre CA change tous les quelques ans, c’est souvent suffisant pour gâcher votre semaine.
Ajoutez du monitoring pour l’accessibilité LDAPS et l’expiration des certificats depuis les nœuds Proxmox (pas depuis un agent de monitoring quelconque).
Rendez l’autorisation explicite : mapping groupe→rôle dans Proxmox, documenté et revu comme des règles firewall.
Testez la bascule en retirant temporairement un DC du service et en vérifiant que les connexions continuent via le serveur alternatif.

Si vous faites cela, LDAP cesse d’être une maison hantée et redevient ce qu’il devrait être : une dépendance que vous comprenez, mesurez et pouvez réparer sous pression.