Kerberos self-service SSO (bind_sasl_kerberos) in unsigned LDAP bind

[ngallouj]

We are preparing to activate the Active Directory "LDAP Server Signing Requirements" policy on our domain controllers. By auditing unsigned LDAP traffic (event 2889), we identified that the WAPT self-service module (get_allowed_domain_usergroups() in waptservice/service.py, checking the waptselfservice group) is performing an unsigned SASL/GSSAPI bind via pyldap.PyLdapClient.bind_sasl_kerberos().

Confirmed: no SASL security property is being requested (no signing), and the OpenLDAP system configuration (SASL_SECPROPS in /etc/ldap/ldap.conf) has no effect – the pyldap module appears to be embedded directly in the waptservice binary (not found as a file), so no configuration or workaround is possible on our end.

By comparison, admin console authentication (auth_module_ad.check_credentials_ad) correctly handles LDAPS/SASL via ldap_auth_server – only self-service seems to be affected.

My question: Is this a known behavior? Is there an undocumented configuration option to force signing? Is a fix planned for a future version?

Thank you for your feedback

[dcardon]

Hi Nabil,

if signing isn't requested at this level, that's not normal. Could you please confirm the WAPT version and client OS running the self-service?

Normally, the Lazarus pyLDAP client performs signing if the server requests it.

Regards,

Denis

[ngallouj]

Hi Denis,

Thanks for the feedback. After checking the 2889 events on the DCs, the source of the unsigned bind is not the Windows self-service (Lazarus/pyLDAP) but the WAPT server itself:

WAPT version: 2.6.1
Server OS: Debian 13 (Trixie)
The LDAP bind originates from the WAPT server, under its machine account identity — therefore on the waptserver side (Python backend), not the Windows client side.
The Windows self-service does not appear in any of the 2889 events reported. Does waptserver make direct LDAP requests to Active Directory (beyond the waptserver-ldap authentication for the console/web self-service)? If so, which library is used on the server side (python-ldap, ldap3, other) and is it configured to request SASL signing?

Best regards,
Nabil

[dcardon]

Hi Nabil,

in version 2.6.1 we removed the ldap3 library and there should no longer be any LDAP calls other than through the pyLDAP module developed in FPC/Lazarus. We redeveloped this module specifically to have complete LDAP support in SASL GSSAPI Kerberos with signing/sealing and Channel Binding.

The pyLDAP client always chooses signing/sealing if the server supports it, which is the default on a Microsoft AD. So if you switch your AD to signing required, it won't cause any problems. However, avoid the 2889 audit message; we've added a flag to the connection to explicitly request signing/sealing. This will be included in a future release.

Which version 2.6.1 are you using exactly?

Best regards,

Denis

[ngallouj]

Hi Denis,

Thanks for the clarification, it's reassuring. We're on version 2.6.1.17834-bd5dd3d4.

To clarify: in our case, the pyLDAP module is called on the WAPT server itself (waptservice, on our Debian system), as part of the group membership verification for the Kerberos SSO of the self-service interface — not from a Windows workstation. The LDAP bind observed in event 2889 therefore comes from the WAPT server's IP address, under its machine account.

If the behavior is indeed as you describe (signing/sealing accepted by default if AD supports it, message 2889 simply due to the lack of an explicit request for now), we can plan the switch to Require Signing on the AD side without fear of any issues. We'll test it and I'll keep you informed if any problems arise.

Best regards,
Nabil