Ruhiges IT-Forum

Version: 2.7.0.19593-10b94c8e (Server, Agent und Konsole)
Ausgabe: Unternehmen
Server: Debian 12
Positionen: Windows 11, hybrider AD + Enterprise-Beitritt

Guten Morgen,

Seit dem Update auf Version 2.7.0.19593 werden unsere Standardbenutzer von der Self-Service-Funktion abgewiesen. In Version 2.6 funktionierte dies einwandfrei. Das Problem konnte auf unseren Testrechnern mit dem Agenten in Version 2.7 reproduziert werden.

Kontext
- AD-Domäne: domain.local (NetBIOS-Domäne)
- Benutzer-UPN: @entreprise.fr (alternatives UPN-Suffix, Entra-Synchronisierung)
- UPN von Administratorkonten: @domain.local
- Standard-Dienstauthentifizierungstyp (Dateitoken)

Symptom In waptservice.log: Tests (alle fehlgeschlagen für ein Konto mit dem UPN @entreprise.fr)
- Automatische Sitzung (Dateitoken): Es konnte keine Sitzung oder kein lokales Profil für den Benutzer gefunden werden Benutzer@Domäne.lokal
- "Benutzer wechseln" + Benutzer@Domäne.lokal + Passwort: gleiche Ablehnung
- "Benutzer ändern" + DOMAIN\user + Passwort: gleiche Ablehnung (für Benutzer DOMAIN\user)
- "Benutzer wechseln" + user@entreprise.fr + Passwort: Ungültige Serviceantwort für GetLocalServiceToken, kein Token vorhanden.
- service_auth_type = system: gleiches Ergebnis

Auf demselben Rechner befindet sich das Benutzer-Admin-Konto (UPN) user_adm@domain.local) stellt problemlos eine Verbindung her.
Es existieren keine lokalen Accounts mit demselben Namen in den Beiträgen.

Analyse
Der Agent scheint den Namen zu normalisieren, indem er<sAMAccountName> @<domaine DNS AD> Statt des tatsächlichen UPN (User Principal Name) oder der Sitzungs-SID zu verwenden, was fehlschlägt, wenn sich das UPN-Suffix von der Domäne unterscheidet, hängt dies wahrscheinlich mit der neuen Funktion in Version 2.7 zusammen: „Benutzer und Gruppen sind vollqualifizierte Namen für die Authentifizierung und Self-Service-ACLs (kein Fallback auf Kurznamen)“.
Das Thema „WAPT Selfservice: Fehler 666“ (viewtopic.php?t=4651) beschreibt möglicherweise denselben Fall (Benutzerzugriff verweigert, Administratorkonten OK).

Fragen
1. Ist dieses Verhalten bekannt und ist eine Lösung geplant?
2. Gibt es eine Agenteneinstellung, die es ermöglicht, den tatsächlichen UPN oder die SID der Sitzung anstelle von sAMAccountName@DNS_domain zu verwenden?

DANKE,

Hallo Maxime,

es gibt tatsächlich einen Fehler auf dieser Ebene. Die UPN-Verwaltung funktioniert nicht korrekt. Wir haben intern einen ersten Patch vorbereitet und melden uns umgehend bei Ihnen, sobald dieser validiert ist.

Die Self-Service-Zugriffsverwaltung wurde verbessert und fragt nun die lokale LSA-Schicht anstelle von Active Directory ab, um Fälle besser zu handhaben, in denen die Verbindung zum Unternehmensnetzwerk nur teilweise oder vollständig unterbrochen ist (die Windows-LSA-Schicht verwendet Caching und funktioniert dabei recht gut, auch wenn die Behandlung von Verbindungs-Timeouts manchmal etwas unzuverlässig sein kann).

Wir entschuldigen uns für die Unannehmlichkeiten; wir müssen weitere UPN-Benutzer zu unseren internen Tests hinzufügen.

Viele Grüße,

Denis

Hallo Denis,

vielen Dank für Ihre schnelle Antwort und Bestätigung. Wir stehen Ihnen gerne zur Verfügung, den Patch auf unseren Testsystemen zu testen, sobald er fertig ist, falls Ihnen das bei der Validierung hilft.

Mit freundlichen Grüßen

Hallo,

ich habe soeben Version 2.7.0.19597 veröffentlicht, die das Problem beheben sollte (bei einem anderen Kunden getestet).

Bitte versuchen Sie es erneut und geben Sie uns Bescheid.

Hallo,

vielen Dank für Ihre schnelle Antwort! Nach der Aktualisierung von Server und Agent funktioniert Self-Service wieder für Benutzer mit dem UPN @entreprise.fr: Die automatische Anmeldung funktioniert und die Pakete werden korrekt nach AD-Gruppen gefiltert.

Vielen Dank an Sie und Denis für die weitere Unterstützung

. Mit freundlichen Grüßen,