Cette erreur de mot de passe LDAP n’est peut-être pas le mot de passe de l’utilisateur

Réinitialiser le mot de passe d’un utilisateur est le mauvais premier geste lorsque le journal indique seulement qu’un bind a été refusé. Avec un greffon d’annuaire, il y a plus d’un bind dans une même connexion, et le refus peut appartenir au compte de service qui effectue la recherche. Réinitialiser les identifiants de l’utilisateur dans ce cas ne change rien. Cela verrouille aussi quelqu’un qui n’a jamais été le problème.

Une connexion, plusieurs bind

Une configuration dotée d’un compte d’annuaire dédié exécute généralement quatre étapes dans l’ordre, et chacune d’elles peut mettre fin à la connexion.

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

Le greffon construit sa connexion d’authentification utilisateur via le même assistant que celui qui gère la première connexion, si bien que cet assistant peut échouer lors de la connexion, lors de la négociation TLS ou lors du bind en tant que compte de service. Le message de haut niveau sur un mot de passe est généré plus tard et ne porte pas l’identité impliquée. C’est pourquoi le texte de l’erreur seul ne peut pas vous dire si l’utilisateur ou le compte de service a été refusé.

Lisez les lignes qui précèdent le message et notez le moment où l’échec s’est produit. Un refus au démarrage, avant qu’un utilisateur n’arrive, désigne le compte configuré ou le point de terminaison. Un refus qui n’apparaît que pour une personne, après une recherche réussie, désigne l’entrée ou l’état de compte de cette personne.

Associez l’erreur à une identité

La règle pratique est d’enregistrer trois choses ensemble : quand cela a échoué, quelle opération était en cours et quelle identité a été présentée. Sans ce triplet, deux pannes très différentes se ressemblent dans un journal qui ne conserve que la phrase finale.

Si le compte configuré échoue, inspectez ce compte et la connexion avant de toucher à un enregistrement utilisateur. Si le bind de l’utilisateur échoue après une recherche réussie, examinez l’entrée renvoyée par la recherche plutôt que celle que vous supposiez qu’elle renverrait. Les deux chemins partagent un message et rien d’autre. Notez lequel vous avez écarté, car la personne suivante posera exactement cette question.

Le nom distinctif est une donnée, pas une supposition

Modifier un composant de nom parce qu’il semble peu familier est un moyen courant de casser une configuration qui fonctionne. L’emplacement par défaut des objets utilisateur dans Active Directory est un conteneur nommé Users, et un conteneur n’est pas le même type d’objet qu’une unité d’organisation au nom similaire.

Demandez à l’administrateur de l’annuaire le nom distinctif réel du compte, ou lisez-le depuis l’objet lui-même. Les deux exemples suivants peuvent être corrects dans leur propre annuaire, c’est pourquoi aucun ne devrait être saisi de mémoire.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

Un déplacement ou un renommage modifie cette valeur alors que le compte et le mot de passe restent valides, si bien qu’une configuration qui fonctionnait le trimestre dernier peut échouer celui-ci sans que personne ne touche à un identifiant. Comparez la chaîne configurée à l’attribut actuel de l’annuaire après toute réorganisation. Faites-le aussi après une migration silencieuse, pas seulement après une panne signalée.

Une base de recherche n’est pas un compte de service

L’identité de bind et la base de recherche répondent à des questions différentes : sous quelle identité le greffon s’authentifie et où il cherche des personnes. Un bind réussi suivi d’aucun utilisateur correspondant est un problème d’étendue, de filtre ou de droit de lecture, et remplacer le nom distinctif du compte par la base des utilisateurs n’y change rien.

Confirmez que le service a chargé la configuration que vous avez modifiée et que son point de terminaison, sa confiance TLS et son mode d’authentification correspondent à un test administratif qui fonctionne. Une recherche manuelle avec un autre compte, ou contre un autre contrôleur de domaine, n’est pas une expérience équivalente.

Vérifiez le secret stocké et vérifiez si le compte est activé, expiré ou verrouillé, sans imprimer le mot de passe nulle part. L’expiration est facile à manquer car le compte continue de fonctionner jusqu’au jour où il ne fonctionne plus. Un verrouillage hérité d’un service sans rapport est tout aussi discret. Aucune des deux conditions ne produit de message nommant le compte de service.

Les règles de groupe viennent en dernier

L’autorisation s’exécute après la réussite des bind, donc une vérification de groupe ne peut pas être la cause d’un échec de bind, et supprimer l’exigence de groupe ne peut pas le réparer. Si la connexion atteint désormais l’étape du groupe, le problème restant est l’appartenance, pas les identifiants.

Accorder au compte de service de larges droits d’annuaire pour faire disparaître l’erreur modifie la politique d’accès de tout le déploiement. Traitez cela comme une décision de sécurité avec sa propre revue, pas comme un correctif pour un message que vous n’avez pas encore attribué à une identité.