La connexion à Squid réussit, mais la règle de groupe LDAP refuse l'accès

Si la connexion réussit mais que la règle de groupe refuse la requête, suivez l'identité jusque dans la recherche LDAP avant de changer le mot de passe. L'authentification, la recherche de l'objet utilisateur et la correspondance de l'appartenance au groupe sont trois résultats distincts.

1. Notez le nom authentifié : il peut être DOMAIN\alex, [email protected] ou alex.
2. Vérifiez la valeur transmise par %LOGIN de l'ACL externe et l'attribut utilisateur que l'assistant recherche.
3. Comparez une identité de test autorisée et une non autorisée : quel nom de recherche en est ressorti, l'utilisateur a-t-il été trouvé et l'appartenance correspondait-elle ?

Pour ext_ldap_group_acl, le -S documenté supprime un composant de domaine de style NT, et -K supprime un composant de royaume Kerberos séparé par @. N'utilisez l'un ou l'autre que si cette transformation correspond au contrat de l'annuaire. Si deux domaines faisant autorité portent le même nom court, retirer le qualificatif peut sélectionner la mauvaise identité.

Gardez aussi les substitutions de filtre de l'assistant cohérentes. Les filtres de recherche d'utilisateurs et de groupes ont des espaces réservés différents ; un filtre copié depuis un autre assistant ou une autre version peut chercher la mauvaise valeur même lorsque la connectivité LDAP fonctionne.

Trouvez le premier résultat qui s'écarte de la politique et corrigez ce mappage ou cette recherche. Gardez les secrets de liaison et les mots de passe des utilisateurs hors de la comparaison. Un échec de recherche de groupe après une connexion valide n'impose pas de changer le schéma d'authentification du navigateur.