L’authentification LDAP d’OpenVPN fonctionne mais le contrôle de groupe échoue : où regarder

Les identifiants passent, le tunnel commence à monter, puis la session échoue avec un message sur le groupe plutôt que sur le mot de passe. Cette combinaison place la panne dans la seconde moitié du travail du greffon LDAP : la liaison et la vérification du mot de passe ont réussi, et la décision d’appartenance qui suit non. Les deux moitiés lisent la même strophe de configuration, ce qui explique qu’une correction à un endroit puisse laisser l’autre intacte. Commencez par la ligne de journal qui nomme l’étape, pas par le compte avec lequel vous testez par hasard.

Traitez le refus comme une réponse d’autorisation

Le greffon effectue une liaison de service, recherche le compte, vérifie le mot de passe fourni, puis demande si ce compte appartient à un groupe autorisé. Ce sont quatre opérations distinctes, et seule la dernière concerne les groupes. Un refus qui arrive après une liaison réussie ne dit donc rien du mot de passe, même lorsque le client affiche une erreur d’authentification générique. Élever le niveau de journal du greffon avant de modifier la configuration est ce qui sépare les quatre dans la sortie.

Cherchez l’évaluation du groupe elle-même. Quand aucune requête de groupe n’apparaît du tout, le bloc d’autorisation n’est pas atteint, ce qui signifie généralement qu’une directive se trouve hors de la strophe qui la possède ou qu’une option obligatoire manque. Quand la requête apparaît et ne renvoie rien, le point de terminaison ou le filtre répond à une autre question que celle que vous vouliez.

Décidez si l’appartenance vit dans le filtre ou dans un bloc de groupe

Deux formes sont prises en charge, et les mélanger est la façon dont une configuration qui marchait cesse de marcher. La première pousse l’appartenance dans la recherche d’utilisateur en demandant un attribut sur l’objet utilisateur ; la seconde laisse la recherche d’utilisateur tranquille et fait chercher l’objet groupe ensuite par le greffon. Choisissez-en une par déploiement et notez laquelle vous avez choisie.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Avec cette forme, le filtre décide de tout, donc RequireGroup doit valoir false, sinon le greffon part chercher un objet groupe que le filtre n’a jamais mentionné. L’attribut du filtre doit exister sur l’objet utilisateur et être renseigné, ce qui n’est pas garanti dès que les groupes sont imbriqués.

L’autre forme garde la recherche simple et ajoute une recherche de groupe après elle. L’objet groupe est nommé explicitement, et le greffon compare l’utilisateur aux membres que l’annuaire renvoie pour lui. Rien ne change dans le filtre utilisateur, ce qui rend cette forme plus facile à auditer quand une autre équipe gère le groupe.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

L’angle mort est partagé : une simple comparaison d’appartenance ne développe pas les groupes imbriqués, donc un compte dont l’accès passe par un groupe parent échoue alors que la console affiche toujours l’appartenance. Active Directory expose member sur le groupe, d’autres schémas utilisent uniqueMember, et pointer vers le mauvais attribut renvoie un résultat vide au lieu d’une erreur.

Choisissez un point de terminaison qui contient l’objet groupe

L’URL décide quel annuaire le greffon interroge, et un contrôleur de domaine sur le port 389 ne répond que pour son propre contexte de nommage. Un catalogue global sur le port 3268 répond pour toute la forêt, en lecture seule et avec un jeu d’attributs partiel. Quand les comptes sont dans un domaine et le groupe VPN dans un autre, une requête sur un seul domaine peut trouver l’utilisateur et manquer quand même l’appartenance. C’est le cas où déplacer l’URL vers le port du catalogue résout le refus, et c’est aussi le cas où les gens généralisent trop loin.

Le jeu d’attributs partiel est la limite : un attribut que le catalogue ne contient pas ne peut pas servir de filtre, donc le même changement peut faire fonctionner un déploiement et en faire renvoyer un autre vide. Confirmez ce que le point de terminaison renvoie réellement pour l’utilisateur et le groupe réels avant de réécrire la strophe. Les renvois et TLS sont de nouveau des sujets distincts, puisqu’un renvoi doit être suivi et qu’un point de terminaison exigeant TLS a besoin des fichiers de confiance correspondants.

Gardez l’état du compte et la portée de recherche dans leurs propres champs

L’indicateur de désactivation appartient au filtre, pas au contrôle de groupe. Dans Active Directory, c’est le deuxième bit de userAccountControl, et sans cette condition un compte désactivé avec un mot de passe valide s’authentifie puis échoue à l’étape du groupe, ce qui ressemble à un bogue d’autorisation. La portée de recherche appartient au DN de base, car partir de la racine du domaine est plus lent et peut correspondre à des objets hors de l’unité d’organisation que vous vouliez couvrir.

Gardez aussi les droits du compte de liaison étroits. Des droits d’annuaire larges transforment un filtre mal configuré en requête réussie et cachent le bogue jusqu’à ce que quelqu’un audite le compte. Modifiez l’appartenance dans l’annuaire lui-même, jamais dans une liste d’exceptions locale, pour que désactiver le compte suffise à retirer l’accès. Si une autre équipe gère le groupe, mettez-vous d’accord sur l’attribut qu’elle renseigne avant d’écrire un filtre dessus.

Prouvez le résultat avec trois comptes

Exécutez la configuration contre trois identités : un membre autorisé, un compte valide hors du groupe et un compte qui a été désactivé. Si les trois sont refusés, la liaison ou la requête de groupe est cassée ; si les trois sont acceptés, aucune condition de groupe n’est appliquée du tout. Un résultat mixte est le seul qui prouve que la configuration distingue les cas qui vous importent.

Lisez les mêmes trois réponses directement dans l’annuaire avant d’accuser le greffon. La première requête montre l’attribut de groupe dont dépend le filtre, et la seconde montre la valeur de contrôle du compte. Remplacez par votre propre DN de base, compte et point de terminaison :

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Un utilisateur dont memberOf revient vide est un fait d’annuaire, pas un bogue du greffon, et un compte qui s’authentifie encore après avoir été désactivé signifie que le filtre manque la condition de contrôle du compte. Corrigez d’abord cette preuve, puis relancez le test à trois comptes. Gardez la ligne de journal qui a nommé l’étape en échec à côté du changement de configuration, pour que la personne suivante puisse séparer l’autorisation de l’authentification sans refaire la recherche.