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
Code: Alle auswählen
Client Error Forbidden (403): Restricted access. WRONG_PASSWORD_USERNAME
for url: https://127.0.0.1:8088/loginCode: Alle auswählen
WARNING local_login failed for user@domaine.local:
Forbidden, unable to find session or local profile for user user@domaine.local- 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,
