Ruhiges IT-Forum

Wir bereiten die Aktivierung der Active Directory-Richtlinie „LDAP-Server-Signaturanforderungen“ auf unseren Domänencontrollern vor. Durch die Überwachung des unsignierten LDAP-Datenverkehrs (Ereignis 2889) stellten wir fest, dass das WAPT-Self-Service-Modul (get_allowed_domain_usergroups() in waptservice/service.py, Überprüfung der Gruppe waptselfservice) eine unsignierte SASL/GSSAPI-Bindung über pyldap.PyLdapClient.bind_sasl_kerberos() durchführt.

Es wurde bestätigt: Es wird keine SASL-Sicherheitseigenschaft angefordert (keine Signierung), und die OpenLDAP-Systemkonfiguration (SASL_SECPROPS in /etc/ldap/ldap.conf) hat keine Auswirkung. Das pyldap-Modul scheint direkt in die waptservice-Binärdatei eingebettet zu sein (nicht als Datei gefunden), sodass von unserer Seite aus keine Konfiguration oder Umgehung möglich ist.

Im Vergleich dazu funktioniert die Authentifizierung über die Admin-Konsole (auth_module_ad.check_credentials_ad) mit LDAPS/SASL über ldap_auth_server einwandfrei – nur die Self-Service-Authentifizierung scheint betroffen zu sein.

Meine Frage: Ist dieses Verhalten bekannt? Gibt es eine undokumentierte Konfigurationsoption, um die Signierung zu erzwingen? Ist eine Behebung für eine zukünftige Version geplant?

Vielen Dank für Ihr Feedback

Hallo Nabil,

wenn die Signierung auf dieser Ebene nicht angefordert wird, ist das ungewöhnlich. Könntest du bitte die WAPT-Version und das Client-Betriebssystem bestätigen, auf dem der Self-Service ausgeführt wird?

Normalerweise führt der Lazarus pyLDAP-Client die Signierung durch, wenn der Server dies anfordert.

Viele Grüße,

Denis

Hallo Denis,

vielen Dank für das Feedback. Nach Prüfung der Ereignisse 2889 auf den Domänencontrollern stellt sich heraus, dass die Quelle der unsignierten LDAP-Bindung nicht der Windows-Self-Service (Lazarus/pyLDAP), sondern der WAPT-Server selbst ist:

WAPT-Version: 2.6.1,
Server-Betriebssystem: Debian 13 (Trixie).
Die LDAP-Bindung stammt vom WAPT-Server und wird über dessen Computerkonto ausgeführt – also serverseitig (Python-Backend) und nicht clientseitig (Windows).
Der Windows-Self-Service wird in keinem der gemeldeten Ereignisse 2889 erwähnt. Sendet der WAPT-Server direkte LDAP-Anfragen an Active Directory (zusätzlich zur WAPT-Server-LDAP-Authentifizierung für den Konsolen-/Web-Self-Service)? Falls ja, welche Bibliothek wird serverseitig verwendet (python-ldap, ldap3 oder eine andere) und ist sie für die Anforderung einer SASL-Signatur konfiguriert?

Viele Grüße,
Nabil

Hallo Nabil,

in Version 2.6.1 haben wir die ldap3-Bibliothek entfernt. LDAP-Aufrufe sollten daher nur noch über das in FPC/Lazarus entwickelte pyLDAP-Modul erfolgen. Dieses Modul wurde speziell für die vollständige LDAP-Unterstützung in SASL GSSAPI Kerberos mit Signierung/Versiegelung und Kanalbindung neu entwickelt.

Der pyLDAP-Client wählt immer die Signierung/Versiegelung, sofern der Server dies unterstützt. Dies ist die Standardeinstellung in Microsoft Active Directory. Wenn Sie also die Signierung in Ihrem Active Directory aktivieren, entstehen keine Probleme. Vermeiden Sie jedoch die Fehlermeldung 2889. Wir haben der Verbindung ein Flag hinzugefügt, um die Signierung/Versiegelung explizit anzufordern. Dieses Flag wird in einer zukünftigen Version enthalten sein.

Welche Version 2.6.1 verwenden Sie genau?

Viele Grüße,

Denis

Hallo Denis,

vielen Dank für die Klarstellung, das beruhigt mich. Wir verwenden Version 2.6.1.17834-bd5dd3d4.

Zur Verdeutlichung: In unserem Fall wird das pyLDAP-Modul auf dem WAPT-Server selbst (waptservice auf unserem Debian-System) im Rahmen der Gruppenmitgliedschaftsprüfung für das Kerberos-SSO der Self-Service-Oberfläche aufgerufen – nicht von einer Windows-Workstation. Die in Ereignis 2889 beobachtete LDAP-Bindung stammt daher von der IP-Adresse des WAPT-Servers und seinem Computerkonto.

Wenn das Verhalten tatsächlich so ist, wie Sie es beschreiben (Signierung/Versiegelung wird standardmäßig akzeptiert, sofern AD dies unterstützt; Meldung 2889 entsteht vorerst nur aufgrund des Fehlens einer expliziten Anforderung), können wir die Umstellung auf „Signierung erforderlich“ auf AD-Seite ohne Bedenken planen. Wir werden es testen und ich halte Sie auf dem Laufenden, falls Probleme auftreten.

Beste Grüße,
Nabil