Hallo Denis,

danke für die Info zum Filetoken. Wir werden das für Version 2.7 berücksichtigen (lokaler LSASS-Cache, übersichtlicher). Vorerst testen wir die Umstellung auf „Signatur erforderlich“ auf AD-Seite, ohne unsere aktuelle Authentifizierungsmethode zu ändern, da du bestätigt hast, dass die Signierung standardmäßig über … ausgehandelt wird.

Hallo Denis,

vielen Dank für die Klarstellung, das ist beruhigend. 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 SSO aufgerufen.

Hallo Denis,

vielen Dank für das Feedback. Nach der Überprüfung von Ereignis 2889 auf den Domänencontrollern stellt sich heraus, dass die Quelle der unsignierten LDAP-Bindung nicht der Windows-Selbstbedienungsdienst (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 unter dessen Benutzername.

Wir bereiten die Aktivierung der Active Directory-Richtlinie „LDAP-Serversignierungsanforderungen“ auf unseren Domänencontrollern vor. Durch die Überwachung des unsignierten LDAP-Datenverkehrs (Ereignis 2889) haben wir festgestellt, dass das WAPT-Self-Service-Modul (get_allowed_domain_usergroups() in waptservice/service.py, Überprüfung der...).