AD FS Login Problem

Hallo zusammen,

ich habe ein seltsames Phänomen bei meinem neu eingerichtetem AD FS.

Ich habe ein AD FS auf einem Server 2019 (1809) nach dieser Anleitung installiert und eingerichtet (ohne WAP-Server):
https://www.anreiter.at/active-directory-federation-services-adfs-instal ...

Daraufhin habe ich ein externes Portal mit dem FS über den internen FQDN verknüpft (von außen nicht erreichbar). Die Authentifizierung mit meinem User funktioniert einwandfrei und ich lande im Portal.

Problem:
Lege ich nun einen Testuser an und versuche, mich damit zu authentifizieren, passiert einfach mal nichts. Nur ein Refresh der Login-Page des FS ohne Fehlermeldung. Auch im Ereignislog des FS-Server ist kein Problem zu sehen.

Phänomen:
Ich gehe im AD in die Eigenschaften des Testuser, gebe "Authentifizierte Benutzer" das Recht "Lesen" und übernehme, nehme den Haken wieder raus und übernehme, und schon funktioniert die Authentifizierung gegen den FS und der Testuser landet im Portal.

Dieses Phänomen ist jederzeit reproduzierbar und besteht bei jedem neuen User aber auch bei 20 Jahre alten Bestandsusern. Wurde der Haken einmal gesetzt und wieder entfernt, ist das Problem behoben.

Frage:
Weiß jemand, woran das liegen kann? Gibt es im AD eine Art "Vorlage" für neue Benutzer, die ich bearbeiten kann/muss?

Hier geht es leider um ca. 400 User und ich möchte das Problem natürlich bei jedem neuen User direkt beseitigt haben und nicht immer diesen Workaround durchführen müssen.

Viele Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3885474864

Url: https://administrator.de/forum/ad-fs-login-problem-3885474864.html

Ausgedruckt am: 21.05.2025 um 03:05 Uhr

7 Kommentare

Neuester Kommentar

Moin,

Ich gehe im AD in die Eigenschaften des Testuser, gebe "Authentifizierte Benutzer" das Recht "Lesen" und übernehme, nehme den Haken wieder raus und übernehme, und schon funktioniert die Authentifizierung gegen den FS und der Testuser landet im Portal.

ich weiß ad-hoc nicht welche Einstellung zu meinst. Bitte poste doch einmal einen Screenshot, damit wir und ich es bildlich vor den Augen haben.

Ich habe ein AD FS nach dieser Anleitung installiert und eingerichtet (ohne WAP-Server):

D.h. es handelt sich beim AD FS Server um Windows Server 2019 (Build 1809)?

Gruß,
Dani

Anbei ein Screenshot

Den Server habe ich im Beitrag ergänzt

Moin,
das ist seltsam...

Ich habe ein AD FS auf einem Server 2019 (1809) nach dieser Anleitung installiert und eingerichtet (ohne WAP-Server):

Hast du was von der Anleitung weggelassen bzw. nicht so wie beschrieben umgesetzt?

Was hat das Debugging ergeben?
https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/troublesh ...
https://www.faq-o-matic.net/2016/06/29/adfs-debug-logging-einschalten-un ...
https://dirteam.com/sander/2019/08/15/howto-enable-auditing-and-logging- ...

Gruß,
Dani

Dabei kommt jetzt interessanterweise das heraus. Und zwar direkt drei Mal hintereinander. Es wird aber definitiv nicht falsch eingegeben. Bei falscher Eingabe erhalte ich vom FS Login schon eine Fehlermeldung.

Bei absichtlicher Falscheingabe erhalte ich zusätzlich drei Mal die Event-ID 52 mit folgendem Inhalt:

Protokollname: AD FS Tracing/Debug
Quelle:        AD FS Tracing
Datum:         09.09.2022 12:05:26
Ereignis-ID:   52
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:ADFSSTS
Benutzer:      DOMAINX\gMSA-ADFS$
Computer:      ADFS.domainx.intern
Beschreibung:
ServiceHostManager.LogFailedAuthenticationInfo: Token of type 'http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName' validation failed with following exception details: 
 System.IdentityModel.Tokens.SecurityTokenValidationException: test-user@domainx.intern ---> System.ComponentModel.Win32Exception: Der Benutzername oder das Kennwort ist falsch
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle& tokenHandle, SafeLsaReturnBufferHandle& profileHandle)
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUser(String domain, String username, String password, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
   bei Microsoft.IdentityServer.Service.LocalAccountStores.ActiveDirectory.ActiveDirectoryCpTrustStore.ValidateUser(IAuthenticationContext context)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei Microsoft.IdentityServer.Service.LocalAccountStores.ActiveDirectory.ActiveDirectoryCpTrustStore.ValidateUser(IAuthenticationContext context)
   bei Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.ValidateTokenInternal(UsernameAuthenticationContext usernameAuthenticationContext, SecurityToken token)
   bei Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
  <System>
    <Provider Name="AD FS Tracing" Guid="{0457a490-4d4d-4a5b-b639-35382f1b6709}" /> 
    <EventID>52</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000400</Keywords>
    <TimeCreated SystemTime="2022-09-09T10:05:26.461307500Z" /> 
    <EventRecordID>75</EventRecordID>
    <Correlation ActivityID="{a624b0d5-9cd7-418e-1300-0080010000f1}" /> 
    <Execution ProcessID="2360" ThreadID="920" ProcessorID="0" KernelTime="0" UserTime="3" /> 
    <Channel>AD FS Tracing/Debug</Channel>
    <Computer>ADFS.domainx.intern</Computer>
    <Security UserID="S-1-5-21-507921405-1580818891-725345543-22460" /> 
  </System>
  <UserData>
    <Event xmlns="http://schemas.microsoft.com/ActiveDirectoryFederationServices/2.0/Events"> 
      <EventData>ServiceHostManager.LogFailedAuthenticationInfo: Token of type 'http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName' validation failed with following exception details: 
 System.IdentityModel.Tokens.SecurityTokenValidationException: test-user@domainx.intern ---&gt; System.ComponentModel.Win32Exception: Der Benutzername oder das Kennwort ist falsch
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUserHandle(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, SafeCloseHandle&amp; tokenHandle, SafeLsaReturnBufferHandle&amp; profileHandle)
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime&amp; nextPasswordChange, DateTime&amp; lastPasswordChange, String authenticationType, String issuerName)
   bei Microsoft.IdentityServer.Tokens.LsaLogonUserHelper.GetLsaLogonUser(String domain, String username, String password, DateTime&amp; nextPasswordChange, DateTime&amp; lastPasswordChange, String issuerName)
   bei Microsoft.IdentityServer.Service.LocalAccountStores.ActiveDirectory.ActiveDirectoryCpTrustStore.ValidateUser(IAuthenticationContext context)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei Microsoft.IdentityServer.Service.LocalAccountStores.ActiveDirectory.ActiveDirectoryCpTrustStore.ValidateUser(IAuthenticationContext context)
   bei Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.ValidateTokenInternal(UsernameAuthenticationContext usernameAuthenticationContext, SecurityToken token)
   bei Microsoft.IdentityServer.Service.Tokens.MsisLocalCpUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)</EventData>
    </Event>
  </UserData>
</Event>

Moin,
im letzten Screenshot hast du vergessen den Namen unkenntlich zu machen (Feld: Computer).

Dabei kommt jetzt interessanterweise das heraus. Und zwar direkt drei Mal hintereinander.

Bei einem Loginversuch oder drei Versuche hintereinander?

Das es sich um ein Bug handelt kann ich gerade nicht glauben. Denn ich habe einmal bei uns nachgeschaut und wir nutzen ebenfalls Windows Server 2019 Build 1809, allerdings in englisch.

Bitte mach eine Gegenprobe: Aktivere das Passwortänderungsportal, starte den Browser im privaten Modus und führe eine Anmeldung mit Passwortänderung durch. Funktioniert das ohne Fehler/Probleme?

Gruß,
Dani

Zitat von @Dani
im letzten Screenshot hast du vergessen den Namen unkenntlich zu machen (Feld: Computer).

Moin, danke für den Hinweis

ich habe hier die Lösung gefunden:
https://social.msdn.microsoft.com/Forums/windows/en-US/61682fd8-a8b8-4e5 ...

ich habe den gMSA für das ADFS in die Gruppe "Prä-Windows 2000 kompatibler Zugriff" gepackt. Damit ist dieses Phänomen behoben.

Interessant wäre noch die Ursache des ganzen. Kann es daran liegen, dass die Domäne schon etwas älter (20 Jahre) ist und immer "mitgeschleift" wird?