Le certificat VPN ne protège pas le tronçon LDAP

Une connexion VPN qui vérifie les identifiants auprès d’un annuaire implique deux connexions réseau distinctes. La connexion de l’utilisateur à la passerelle est protégée par le certificat propre du VPN et par la configuration du protocole. La connexion de la passerelle à l’annuaire est une autre session avec ses propres réglages TLS, son propre magasin de confiance et ses propres modes de défaillance. Rien dans la première ne garantit quoi que ce soit sur la seconde.

Cette asymétrie est le mécanisme derrière une connexion qui semble chiffrée et qui envoie pourtant un mot de passe de bind en clair.

Deux connexions, deux décisions de confiance

La session externe est ce que voit l’utilisateur : un certificat lié au nom d’hôte du VPN, validé par le client, qui transporte l’échange d’authentification. La session interne appartient au client d’annuaire à l’intérieur de la passerelle, qui ouvre sa propre connexion et soit négocie TLS, soit ne le fait pas. Chaque côté valide le pair auquel il parle, à l’aide d’éléments provenant d’un autre fichier de configuration. Un tronçon interne mal configuré reste invisible du côté de l’utilisateur, car le tronçon externe fonctionne exactement comme prévu.

C’est pourquoi la défaillance est silencieuse plutôt que bruyante. Une passerelle qui ne vérifie jamais le certificat de l’annuaire authentifie quand même correctement les utilisateurs ; elle les authentifie simplement sur un canal qu’elle n’a pas vérifié.

StartTLS et LDAPS, choisis délibérément

StartTLS s’ouvre comme du LDAP simple et s’élève sur place, conventionnellement sur le port 389. LDAPS démarre TLS avec la connexion, conventionnellement sur le 636. Les deux sont légitimes et l’adaptateur doit correspondre à ce que l’annuaire propose. Exiger StartTLS est différent de l’essayer et de continuer lorsque l’élévation échoue, et c’est précisément dans cet écart qu’un mot de passe de bind peut s’échapper. Configurez le mode strict et n’autorisez pas de repli non protégé pour un bind par mot de passe.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

L’option -ZZ est tout l’enjeu : la requête échoue plutôt que de continuer silencieusement sans l’élévation. Les noms et comptes de cette ligne sont des exemples. La documentation TLS d’OpenLDAP couvre les réglages de confiance qui la sous-tendent.

Quel magasin de confiance lit le client LDAP ?

La bibliothèque cliente OpenLDAP lit sa propre configuration de confiance, que ce soit depuis le fichier système ou depuis un réglage propre au greffon. La directive CA du VPN s’applique aux pairs VPN et ne prouve pas que la bibliothèque LDAP lit le même fichier. Utilisez le nom d’hôte d’annuaire que le certificat couvre réellement, plus la chaîne émettrice à laquelle la bibliothèque fait confiance. Dans Active Directory, déployez un certificat de service d’annuaire avec le bon usage d’authentification serveur au lieu de raisonner à partir d’un nom d’affichage.

Chaque destination de basculement doit satisfaire la même politique d’identité. Un environnement où le primaire est validé et le secondaire ne l’est pas est pire que celui sans basculement, car le chemin le plus faible n’est découvert que pendant une panne.

Le compte de bind reste un problème à part

Protéger le transport ne réduit pas ce que le compte de bind peut faire. La portée de recherche dans l’annuaire, l’autorisation par groupes et les privilèges du compte de service sont des décisions distinctes, et un compte de bind large reste large une fois TLS activé. Utilisez le compte de service et la base de recherche les plus étroits dont l’intégration a besoin, et consignez le point de terminaison, le mode TLS, le propriétaire de la confiance et le processus de renouvellement avec la configuration du VPN.

Lorsqu’une non-concordance de certificat apparaît, déployez le certificat ou la chaîne corrects. Désactiver la vérification transforme une non-concordance visible en invisible et laisse la seconde relation de confiance non testée.

Deux connexions, deux propriétaires, deux dates de renouvellement. Les garder séparées dans la documentation, voilà ce qui garde la connexion honnête.