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
Kerberos self-service SSO (bind_sasl_kerberos) in unsigned LDAP bind
-
dcardon
- WAPT Expert
- Messages: 1988
- Registration: June 18, 2014 - 09:58
- Location: Saint Sébastien sur Loire
- Contact :
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
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
Denis Cardon - Tranquil IT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
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
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
- WAPT Expert
- Messages: 1988
- Registration: June 18, 2014 - 09:58
- Location: Saint Sébastien sur Loire
- Contact :
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
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
Denis Cardon - Tranquil IT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
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
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
-
dcardon
- WAPT Expert
- Messages: 1988
- Registration: June 18, 2014 - 09:58
- Location: Saint Sébastien sur Loire
- Contact :
Hi Nabil,
just so you know, we've added the "service_auth_type = filetoken" option [1] which uses the machine's local Kerberos authentication mechanism without going through the WAPT server. It's cleaner because everything remains within a purely local LSASS and Active Directory framework. I encourage you to test this option.
In filetoken mode, group name resolution against SIDs is still done via pyLDAP to AD, but from the agent and not the server. In the upcoming version 2.7, the request will go through the local LSASS service (which handles caching) and will potentially request resolution from the AD server if needed.
Best regards,
Denis
[1] https://www.wapt.fr/fr/doc/wapt-advance ... l-settings
just so you know, we've added the "service_auth_type = filetoken" option [1] which uses the machine's local Kerberos authentication mechanism without going through the WAPT server. It's cleaner because everything remains within a purely local LSASS and Active Directory framework. I encourage you to test this option.
In filetoken mode, group name resolution against SIDs is still done via pyLDAP to AD, but from the agent and not the server. In the upcoming version 2.7, the request will go through the local LSASS service (which handles caching) and will potentially request resolution from the AD server if needed.
Best regards,
Denis
[1] https://www.wapt.fr/fr/doc/wapt-advance ... l-settings
Denis Cardon - Tranquil IT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
Share your experiences on WAPT! Send us your blog and article URLs in the "Your Opinion of the forum, and we'll feature them on the WAPT
Hi Denis,
Thanks for the info about filetoken, we'll keep that in mind for 2.7 (local LSASS cache, cleaner). For now, we'll test the switch to Require Signing on the AD side directly without changing our current authentication method, since you confirmed that signing is negotiated by default via pyLDAP. I'll close the thread on my end unless there are any issues during testing — thanks for following up.
Best regards,
Nabil
Thanks for the info about filetoken, we'll keep that in mind for 2.7 (local LSASS cache, cleaner). For now, we'll test the switch to Require Signing on the AD side directly without changing our current authentication method, since you confirmed that signing is negotiated by default via pyLDAP. I'll close the thread on my end unless there are any issues during testing — thanks for following up.
Best regards,
Nabil
