SSO Kerberos self-service (bind_sasl_kerberos) en bind LDAP non signé

[ngallouj]

Nous préparons l'activation de la stratégie AD "LDAP Server Signing Requirements" sur nos contrôleurs de domaine. En auditant le trafic LDAP non signé (event 2889), nous avons identifié que le module self-service de WAPT (get_allowed_domain_usergroups() dans waptservice/service.py, vérification du groupe waptselfservice) effectue un bind SASL/GSSAPI non signé via pyldap.PyLdapClient.bind_sasl_kerberos().

Confirmé : aucune propriété de sécurité SASL demandée (pas de signing), et la config système OpenLDAP (SASL_SECPROPS dans /etc/ldap/ldap.conf) est sans effet - le module pyldap semble embarqué directement dans le binaire waptservice (introuvable comme fichier), donc aucune configuration/contournement possible de notre côté.

Par comparaison, l'authentification de la console admin (auth_module_ad.check_credentials_ad) gère correctement LDAPS/SASL via ldap_auth_server - seul le self-service semble concerné.

Ma question : comportement connu ? Option de config non documentée pour forcer le signing ? Correctif prévu dans une future version ?

Merci pour vos retour

[dcardon]

Bonjour Nabil,

si le signing n'est pas demandé à ce niveau c'est pas normal. Est ce que vous pouvez me confirmer la version Wapt et l'OS client qui fait tourner le selfservice?

Normalement le client pyLDAP Lazarus fait du signing si le serveur le demande.

Cordialement,

Denis

[ngallouj]

Bonjour Denis,

Merci pour le retour. Après vérification des events 2889 sur les DC, la source du bind non signé n'est pas le self-service Windows (Lazarus/pyLDAP) mais le serveur WAPT lui-même :

Version WAPT : 2.6.1
OS serveur : Debian 13 (Trixie)
Le bind LDAP provient du serveur WAPT, sous son identité de compte machine — donc côté waptserver (backend Python), pas côté client Windows.
Le self-service Windows n'apparaît dans aucun des events 2889 remontés. Est-ce que waptserver fait des requêtes LDAP directes vers l'AD (au-delà de l'auth waptserver-ldap pour la console/self-service web) ? Si oui, quelle lib est utilisée côté serveur (python-ldap, ldap3, autre) et est-elle configurée pour demander le signing SASL ?

Cordialement,
Nabil

[dcardon]

Bonjour Nabil,

en 2.6.1 on a supprimé la lib ldap3 et il ne doit plus y avoir d'autre appel ldap autre que à travers le module pyLDAP développé en FPC/Lazarus. On a redéveloppé ce module justement pour avoir un support complet LDAP en SASL GSSAPI Kerberos avec signing / sealing et Channel Binding,

Le client pyLDAP choisi toujours le signing/sealing si le serveur le supporte, ce qui est le cas par défaut sur un AD Microsoft. Donc si vous basculer votre AD en signing required, ça ne posera pas de soucis. Par contre éviter le message d'audit 2889, on a rajouté un flag à la connexion pour le demander le signing/sealing explicitement. Ca sera inclus dans une prochaine release.

Vous êtes en quelle version 2.6.1 exactement?

Cordialement,

Denis