Nach dem WAPT 2.7-Update trat ein Problem mit der Selbstbedienung auf

[yoann.montouchet]

Guten Morgen,
Wir haben gestern auf unserem Server (Unternehmenslizenz) auf Version 2.7.19598 aktualisiert. Auf dem Server läuft Debian 13 Trixie (ebenfalls gestern aktualisiert; zuvor nutzten wir Debian 11 und dann Debian 12).
Seit dieser Umstellung hat sich unser Verhalten im Bereich Self-Service verändert; die von uns verwendete Authentifizierung funktioniert nicht mehr.
Dies steht in gewissem Zusammenhang mit diesem Thema: viewtopic.php?t=4581 die wir nicht fortgesetzt hatten.
Zum damaligen Zeitpunkt entschieden wir uns für die Macs, die wir einsetzten, schließlich dagegen, sie in unser AD-Verzeichnis zu integrieren (was keinen praktischen Nutzen bot), und um die Selbstverwaltung zu ermöglichen, konfigurierten wir alle Agenten (Windows und macOS) wie folgt:
service_auth_type=waptserver-ldap
use_kerberos = False

Mit dieser Konfiguration wurden beim Öffnen des Selbstbedienungsbereichs Benutzername und Passwort vom Selbstbedienungssystem angefordert und anschließend vom Server mit Active Directory (samba-ad) verifiziert. Insgesamt hat dies für uns gut funktioniert.
Der WAPT-Server ist korrekt mit AD authentifiziert; ich konnte ein Kerberos-Ticket anfordern und mich dann damit authentifizieren (über "curl -v --negotiate -u: https://si-wapt-01.ad.xxx.fr/api/v3/login_kerberos -k") ohne Sorgen:

Code: Alle auswählen

{"success":true,"msg":"Authentication OK","request_time":0.04843854904175,"result":{"auth_result":{"auth_method":"kerb","user":"yoann.montouchet@ad.xxx.fr","auth_date":"2026-10-08T12:58:39.508967+00:00","roles":[],"auth_otp_validated":false},"server_uuid":"xxx","version":"2.7.0.19598","server_domain":"ad.xxx.fr","edition":"enterprise","user_acls":{},"token":null}}

Seit dem Versionsupgrade erhalten wir mit derselben Konfiguration (waptserver-ldap und ohne Kerberos) auf Windows-Rechnern die folgende Fehlermeldung:

Screenshot 2026-10-08 150108.png (11,35 KB) 6268 Mal angesehen

auf Macs:

Screenshot 2026-10-08 150225.png (55,57 KB) 6268 Mal angesehen

Durch die Beibehaltung von waptserver-ldap und die Aktivierung von Kerberos treten keine Fehler mehr auf der Windows-Seite auf, aber es werden keine Pakete angezeigt.
Und ein Fehler auf der Mac-Seite:

Screenshot 2026-10-08 150436.png (48,22 KB) 6252 Mal angesehen

Wir haben andere Kombinationen (System, waptagent-ldap) ausprobiert, jedoch ohne Erfolg. Die einzige, die die Windows-Seite wiederherzustellen scheint, ist die Speicherung in filetoken. Dort finden wir den erwarteten Inhalt im Self-Service, aber auf dem Mac sehen wir weiterhin nichts, wie ich glaube, schon im letzten März.

Kurz gesagt, ich bin etwas ratlos und weiß nicht mehr, wo ich suchen soll, und wir haben das Problem, dass knapp zwanzig Macs seit gestern nicht mehr in der Lage sind, das Selbstbedienungssystem zu öffnen.

Haben Sie eine Ahnung, was die Ursache sein könnte und wie man das Problem beheben kann?

NACHTRAG: Wichtige Information, aber der Test "testing-ldap-connectivity.sh" ist in Ordnung:

Code: Alle auswählen

----------------------------------------------------------------
Test SSO SELFSERVICE LDAP with ldap_account_service_login
----------------------------------------------------------------
Username : yoann.montouchet
Group test member : Domain Users
----------------------------------------------------------------
[OK] Test SSO SELFSERVICE LDAP with ldap_account_service_login
----------------------------------------------------------------
Test ldap with direct Login
----------------------------------------------------------------
Username ldap: yoann.montouchet
Password ldap:
Group test member : Domain Users
--------
ALL GOOD
--------

NACHTRAG 2: Ich habe eine erste Erklärung; mein Selbstbedienungssystem verwendet kurze "Gruppennamen" und keine vollständigen NamenGruppenname@ad.xxx.fr".
Durch Hinzufügen einer solchen Gruppe in der waptserver-ldap+kerberos-Konfiguration sehe ich auf der Windows-Seite, dass die Pakete im Self-Service ankommen.
Auf dem Mac wird jedoch weiterhin ein Fehler angezeigt...

NACHTRAG 3: Eine weitere möglicherweise interessante Information, aber auf der Mac-Seite scheint die Kerberos-Authentifizierung korrekt zu funktionieren:

Code: Alle auswählen

yoann.montouchet@XXX~ % kinit yoann.montouchet@ad.xxx.fr
yoann.montouchet@ad.xxx.fr's password: 
yoann.montouchet@XXX~ % klist
Credentials cache: API:91B80912-6A34-4F3E-A1EC-B450011A2DAA
        Principal: yoann.montouchet@AD.XXX.FR

  Issued                Expires               Principal
Oct  8 16:05:17 2026  Oct  9 02:05:12 2026  krbtgt/ad.xxx.fr@AD.XXX.FR

[yoann.montouchet]

Ich bin ein Stück weitergekommen; Sie müssen den Namen Kerberos in Großbuchstaben schreiben: yoann.montouchet@AD.XXX.FR auf der Ebene von kinit und verwenden Sie eine temporäre Datei, um das Token zu speichern, und exportieren Sie den Pfad zum Token:
kinit -c DATEI:/tmp/krb5cc_$(id -u) yoann.montouchet@AD.XXX.FR
export KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u)

Starten Sie den Befehl anschließend manuell im selben Terminal:
/Applications/WAPT/WAPT\ Self-service.app/Contents/MacOS/waptself

Der Selbstbedienungsbereich öffnete sich daraufhin korrekt und die erwarteten Pakete waren vorhanden. Es gab jedoch keinen Knopf, um die Pakete zu verwalten!

Screenshot 2026-10-08 162907 (Small).png (143,38 KB) 6173 Aufrufe

Es ist klar, dass es äußerst schwierig sein wird, diese Schritte für Kollegen zu industrialisieren... Haben Sie vielleicht eine elegantere Idee?

[dcardon]

Hallo Yoann,

bezüglich des Anzeigefehlers in der Self-Service-Oberfläche: Wir konnten ihn reproduzieren und arbeiten an einer Lösung (es handelt sich um einen Unterschied im Verhalten zwischen Intel- und ARM-Macs).

Bezüglich des Problems mit der Self-Service-Authentifizierung/Gruppenabfrage wurde am Freitag ein Patch in den Nightly Build eingespielt, um einige Fehler zu beheben. Ich werde mit meinen Kollegen klären, ob dieser auch das Problem von Rechnern außerhalb der Domäne mit Domänen-Login/Passwort-Authentifizierung behebt.

Ich empfehle Ihnen jedoch, macOS der Domäne hinzuzufügen (das funktioniert heutzutage gut, war aber nicht immer so ). Dadurch wird insbesondere die Passwortrotation sichergestellt.

Wir führen noch eine letzte Testreihe durch und werden in Kürze ein Update veröffentlichen.

Viele Grüße,

Denis

[yoann.montouchet]

Hallo Denis,
das Problem mit den Macs ist, dass unsere Domäne für die Rechner beim Anmelden nicht direkt zugänglich ist, sondern nur über ein VPN, das erst nach Verbindungsaufbau aktiv wird.
Dadurch funktioniert unter anderem die Passwortrotation nicht.
Wir mussten MDM speziell für diese Rechner implementieren, um die Passwortrotation zu verwalten und Richtlinien wie Active Directory unter Windows (aber nicht auf einem Mac) bereitzustellen.
Daher sahen wir keinen Sinn darin, die Integration in Active Directory weiter zu verfolgen.
Wir hatten ein Beispiel mit einem in Active Directory integrierten Mac; das Kontopasswort wurde auf dem Mac trotz einer Änderung in Active Directory weiterhin erkannt und akzeptiert, sogar noch Wochen später und trotz bestehender VPN-Verbindung (nach der Anmeldung).
Kurz gesagt: Wir sind offen für eine Lösung. Als letzten Ausweg haben wir einen Workaround entwickelt, der es ermöglicht, ein Kerberos-Token lokal zu aktualisieren, bevor der Self-Service gestartet wird. Wir haben ihn als Paket bereitgestellt und über Wapt verteilt; er scheint als temporäre Ausweichlösung zu funktionieren.