Anmeldeprobleme - Benutzername / Passwort falsch

stevenki · 21. August

Hallo zusammen,

wir haben aktuell "massive" Probleme mit Anmeldeproblemen, die ich einfach nicht nachvollziehen kann.
Ich würde behaupten, dass die Probleme auftreten, seit dem wir einen Windows Server 2025 DC mit im System haben, 12 Jahre davor hatten wir keinerlei diese Probleme.

Die Probleme äußern sich wie folgt:

Einige Rechner melden bei der Anmeldung "Benutzername oder Kennwort falsch".

Wenn wir in dem Moment uns dann lokal Anmelden und Test-SecureComputerChannel machen, bekomme ich ein True.

NSLookup hat auch die Domain sowie alle Domaincontroller aufgelöst usw.

Zeit passt auch mit den DCs überein.

Nach einem Neustart des Clients gehts dann immer wieder.

Das Problem haben wir auch im gesperrten Modus, also wenn ein Benutzer seinen Rechner sperrt und wieder entsperren will.

Im Log des Clients wird folgendes gemeldet:

EventID 4625

MachineName TA-CLPC20005.xxx.local

EntryType FailureAudit

Fehler beim Anmelden eines Kontos.

Antragsteller:
   Sicherheits-ID:       S-1-5-18
   Kontoname:       TA-CLPC20005$
   Kontodomäne:       [DOMAINNAME]
   Anmelde-ID:       0x3e7

Anmeldetyp: 2

Konto, für das die Anmeldung fehlgeschlagen ist:
   Sicherheits-ID:       S-1-0-0
   Kontoname:       [Anmeldename]
   Kontodomäne:       [DOMAINNAME]

Fehlerinformationen:
   Fehlerursache:       %%2304
   Status:           0xc000006d
   Unterstatus::       0x0

Prozessinformationen:
Aufrufprozess-ID: 0x9e8
Aufrufprozessname: C:\Windows\System32\svchost.exe

Netzwerkinformationen:
   Arbeitsstationsname:   TA-CLPC20005
   Quellnetzwerkadresse:   127.0.0.1
   Quellport:       0

Detaillierte Authentifizierungsinformationen:
   Anmeldeprozess:       User32
   Authentifizierungspaket:   Negotiate
   ?bertragene Dienste:   -
   Paketname (nur NTLM):   -
   Schl?ssell?nge:       0

zur gleichen Zeit wird auf dem DC folgendes protokolliert:

Ein Kerberos-Dienstticket wurde angefordert.

Kontoinformationen:
   Kontoname:         [Anmeldename]@[DOMAINNAME]
   Kontodomäne:       [DOMAINNAME]
   Anmelde- GUID:       {8ceb624b-4a79-43d5-9f30-fc3eacf3d33c}
   MSDS-SupportedEncryptionTypes:   0x0 (N/A)
   Verfügbare Schlüssel:   N/A

Dienstinformationen:
   Dienstname:       TA-CLPC20005$
   Dienst-ID:        [DOMAINNAME]\TA-CLPC20005$
   MSDS-SupportedEncryptionTypes:   0x1C (RC4, AES128-SHA96, AES256-SHA96)
   Verfügbare Schlüssel:   DES, RC4, AES128-SHA96, AES256-SHA96

Domaincontrollerinformationen:
MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96)
Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96

Netzwerkinformationen:
   Clientadresse:        ::ffff:10.1.10.38
   Clientport:       53570
   Angekündigte ETYPEs:
       AES256-CTS-HMAC-SHA1-96
       AES128-CTS-HMAC-SHA1-96
       RC4-HMAC-NT
       DES-CBC-MD5
       DES-CBC-CRC
       RC4-HMAC-NT-EXP
       RC4-HMAC-OLD-EXP

Zusätzliche Informationen:
   Ticketoptionen:       0x40810000
   Ticketverschlüsselungstyp:   0x12
   Sitzungsverschlüsselungstyp:   0x12
   Fehlercode:       0x0
   Übertragene Dienste:   -

Ticketinformationen
Hash des Anforderungstickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw=

Hash des Antworttickets: Kd0//U3zlF76OWCXt/dK468UjDOx3yRqjxSDZW6014E=

Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert.

Kontoinformationen:
   Kontoname:         [Anmeldename]
   Bereitgestellter Bereichsname:   [DOMAINNAME]
   Benutzer-ID:           [DOMAINNAME]\ [Anmeldename]
   MSDS-SupportedEncryptionTypes:   0x24 (RC4, AES-SK)
   Verfügbare Schlüssel:   DES, RC4, AES128-SHA96, AES256-SHA96

Dienstinformationen:
   Dienstname:       krbtgt
   Dienst-ID:       [DOMAINNAME]\krbtgt
   MSDS-SupportedEncryptionTypes:    0x18 (AES128-SHA96, AES256-SHA96)
   Verfügbare Schlüssel:   DES, RC4, AES128-SHA96, AES256-SHA96

Domaincontrollerinformationen:
MSDS-SupportedEncryptionTypes: 0x18 (AES128-SHA96, AES256-SHA96)
Verfügbare Schlüssel: DES, RC4, AES128-SHA96, AES256-SHA96

Netzwerkinformationen:
   Clientadresse:       ::ffff:10.1.10.38
   Clientport:       53569
   Angekündigte ETYPEs:
       AES256-CTS-HMAC-SHA1-96
       AES128-CTS-HMAC-SHA1-96
       RC4-HMAC-NT
       DES-CBC-MD5

Zusätzliche Informationen:
   Ticketoptionen:       0x40810010
   Ergebniscode:        0x0
   Ticketverschlüsselungstyp:   0x12
   Sitzungsverschlüsselungstyp:   0x12
   Vorauthentifizierungstyp:   2
   Vorauthentifizierungsverschlüsselungstyp:   0x12

Zertifikatinformationen:
   Name des Zertifikatausstellers:
   Seriennummer des Zertifikats:
   Fingerabdruck des Zertifikats:

Ticketinformationen
Hash des Antworttickets: s5yh1FJP7/QGNfIseWEklJBJwrWgI6rnxxwBYFb82qw=

ich weiß leider nicht mehr wo wir ansetzen sollen, es betrifft aktuell nur "wenige" einzelne Rechner, gefühlt werden es aber mehr.

Hat jemand Ideen wo ich noch ansetzen könnte?

Interessanterweise meldet der Client auch folgendes:

13:15:21 Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne DOMAINNAME aufgrund der folgenden Ursache nicht einrichten:
Interner Fehler.

Was interner Fehler hier bedeutet weiß ich nicht - ABER, dieser Fehler kommt erst eine ganze Weile nach den Meldungen oben.

Auch finde ich im Log, dass er erfolgreich die Zeit mit dem DC synchronisiert usw.

Ich wäre glücklich, wenn jemand eine Idee hat.

Liebe Grüße

bearbeitet 21. August von stevenki

cj_berlin · 21. August

Moin,

ich dachte, das wäre weggepatcht worden, aber versucht mal, RC4 auf Domain Controller-Ebene wieder zuzulassen, zumindest bis alle Maschinen ihr Kennwort gerollt haben.

NilsK · 21. August

Moin,

vor 32 Minuten schrieb cj_berlin:

ich dachte, das wäre weggepatcht worden

dafür müsste der Patch ja auch eingespielt worden sein. Darüber wissen wir hier nichts, soweit ich sehe.

Gruß, Nils

stevenki · 22. August

Hallo, danke für eure Antworten.
Leider ist mir das entgangen, gab es da einen manuell zu installierenden Hotfix?

Also Grundlegend sind alle Updates installiert, die über Windows Update zu beziehen sind.

stevenki · 25. August

Also am Computer Kennwort kann es , aus meiner Laiensicht, nicht liegen, denn sollte dann jeder Computer nicht genau nur 1* betroffen sein? Tatsächlich sind die Clients mehrfach betroffen, hatte erst Freitag einen Notebook mal phyisisch in dem Moment vor mir, wo das Problem auftrat.

Keine Anmeldung mit keinem Konto möglich (außer natürlich mit dem lokalen), Neustart, alles wieder iO.

Logs genau auf allen Clients gleich

zahni · 25. August

Ob es bringt, kann ich nicht sagen, es wäre aber mal einen Versuch wert. Setze das Kennwort vom krbtgt-Konto 2x (!) zurück und nach 10 Stunden nochmal. Das Kennwort sollte sicher sein, Du musst es Dir aber nicht merken.

https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password

Das im Übrigen auch Golden-Tickets ungültig...

NilsK · 25. August

Moin,

vor einer Stunde schrieb zahni:

Setze das Kennwort vom krbtgt-Konto 2x (!) zurück und nach 10 Stunden nochmal.

die 10 Stunden liegen zwischen dem ersten und dem zweiten Zurücksetzen. Nicht zwischen dem zweiten und dem dritten - dreimal ist nicht nötig.

Der Zeitabstand dient dazu, dass in einer Nicht-Angriffs-Situation genügend Zeit bleibt, dass auch eine verteilte und AD-replizierte Infrastruktur unterbrechungsfrei weiter arbeiten kann.

Gruß, Nils

MurdocX · 26. August

AFAIR haben Kerberos-Tickets eine default Laufzeit von 10 Stunden, damit wird erstmal kein Ticket unlesbar gemacht.

Zum Problem: Ich würde behaupten "Its always DNS" ;-)

Zusatz: Beim Server 2025 wurde RC4 abgeschaltet, falls an den User-Accounts jemand etwas gedreht haben sollte.

Neuigkeiten in Windows Server 2025 | Microsoft Learn

stevenki · 2. September

Also das Zurücksetzen des Passworts vom krbtgt hat nichts gebracht ...

DNS würde ich an der Stelle eventuell ausschließen?! Weil im Log des Clients steht zb davor, dass er sich die Uhrzeit vom per Name aufgelösten DC geholt hat. Die Auflösung scheint ja also zu klappen und den DC erreicht er ja, sonst würde der DC ja auch nichts Protokollieren oder?

Wegen dem RC4 schaue ich mir mal an, dankeschön

daabm · 2. September

Der PW-Reset ändert ja auch nichts an Problemen in der technischen Infrastruktur :-) Was DNS mit der Uhrzeit zu tun hat, kann ich grad nicht nachvollziehen. Was liefert denn in cmd.exe ein

klist purge & klist get host/%computername%

auf dem problematischen Client in dem Moment? Und man kann auch das Kerberos-Logging ein wenig hochdrehen - https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-kerberos-event-logging

(würde ich in dem Fall erst mal nur auf ein paar Clients machen)

#0 ist das TGT, #1 ist das TGS für den Client.

Aktuelle Anmelde-ID ist 0:0x1818c1
Ein Ticket f?r host/<Clientname> wurde erfolgreich abgerufen.

Zwischengespeicherte Tickets: (2)

#0>	Client: <Username> @ <Domain-FQDN>
	Server: krbtgt/<Domain-FQDN> @ <Domain-FQDN>
	KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96
	Ticketkennzeichen 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize 
	Startzeit: 9/2/2025 17:41:24 (lokal)
	Endzeit:   9/3/2025 3:41:24 (lokal)
	Erneuerungszeit: 9/9/2025 17:36:30 (lokal)
	Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96
	Cachekennzeichen: 0x1 -> PRIMARY 
	KDC aufgerufen: <DC-FQDN>

#1>	Client: <Username> @ <Domain-FQDN>
	Server: host/<Clientname> @ <Domain-FQDN>
	KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96
	Ticketkennzeichen 0x40a10000 -> forwardable renewable pre_authent name_canonicalize 
	Startzeit: 9/2/2025 17:41:24 (lokal)
	Endzeit:   9/3/2025 3:41:24 (lokal)
	Erneuerungszeit: 9/9/2025 17:36:30 (lokal)
	Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96
	Cachekennzeichen: 0 
	KDC aufgerufen: <DC-FQDN>

bearbeitet 2. September von daabm

MurdocX · 10. September

@stevenki

Gibts hier ein Update von Deiner Seite aus?

stevenki · vor 7 Stunden

Hallo, danke für eure Antworten.

War leider krank und das Problem spitzt sich zu ... auch server haben teilweise nun das Problem. Nach einem Neustart ist dann meißt alles wieder iO.

@daabm: Wenn ich deinen Befehl an einen betroffenen Client / Server ausführe erhalte ich bei klist get host/%computername% nur folgende Ausgabe:

Fehler bei klist. Fehler: 0xc000018b/-1073741429: Die SAM-Datenbank des Windows-Servers enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung.

Die Probleme haben wir aus meiner Sicht seit dem wir den 2025er DC mit integriert haben. Davor gab es diese Problematik nie

a) DNS geht ohne Probleme zu der Zeit, ich kann alles ordentlich auflösen am Client / Server
b) es betrifft auch relative neue Clients / Server die vor nicht allzu langer Zeit in der Domain aufgenommen wurden

bearbeitet vor 7 Stunden von stevenki

testperson · vor 7 Stunden

Moin,

schau ggfs. einmal hier (auch wenn das Problem meiner Meinung nach nicht Windows Server 2025 als DC ist, sondern die vermutliche Missachtung aller Dinge, die mit RC4 zusammenhängen): Windows Server 2025 als DC: Finger weg, bei gemischten Umgebungen (RC4-Problem)Borns IT- und Windows-Blog

HTH

Jan

stevenki · vor 6 Stunden

Aktuell habe ich wieder das Problem, dass ich auf die c$ Freigabe eines Server nicht zugreifen kann, im Explorer passiert einfach nichts, per cd in Powershell erhalte ich folgende Fehlermeldung:

cd : Der Pfad "\\[Servername]\c$" kann nicht gefunden werden, da er nicht vorhanden ist.
In Zeile:1 Zeichen:1

Was habe ich geprüft:

1) auf Server und Client (auch ein Server) sind Uhrzeit mit dem DC synchronisiert und identisch

2) Auflösung kein Problem

3) Client sowie Server sagen bei Test-ComputerSecureChannel das alles iO ist

4) wenn ich auf dem Client ein "klist get host/[Servername]" ausführe, bekommt der Client ein Ticket

ich bekomme einfach keinen Zugriff hin, nun habe ich den Server neugestartet und alles funktioniert wieder.

Ich gehe mal den Artikel von dir durch @testperson, vielen Dank erstmal

Wir haben auf einem Server ein dauerhaftes Powershell Skript laufen, welches Daten auf einen Fileshare kopiert. Über eine CSV wird das Share-Ziel ermittelt (unterschiedliche Server) -> auf manche Server klappt es grade, auf andere sagt er Benutzername oder Kennwort falsch. Gleicher Benutzer ... es ist wirklich zum Wahnsinnig werden

bearbeitet vor 6 Stunden von stevenki

stevenki · vor 1 Stunde

Also es ist wirklich komisch, wochenlang geht es (bis auf einzelne Anmeldeprobleme) und dann kommt wieder Tag X wo quasi nichts mehr geht.

Ein repadmin /replsummary hat bei Quell-DSA DC01 als Fehler angezeigt, bei Ziel-DSA DC02 als Fehler.

Ein repadmin /showrepl hat immer das ausgegeben:
CN=Schema,CN=Configuration,DC=domain,DC=xx
Standort\DC01 über RPC
DSA-Objekt-GUID: a514d08f-f9c3-4889-93a6-e6f5c4b9573e
Letzter Versuch am 2025-09-30 11:46:46 ist fehlgeschlagen, Ergebnis 1908 (0x774):
Der Domänencontroller für diese Domäne wurde nicht gefunden.
1 aufeinander folgende Fehler.
Letzte Erfolg um 2025-09-30 10:52:07.

Ein Repadmin /Syncall /APeD hat ohne Fehler funktioniert und plötzlich waren alle anderen Befehle auch wieder ohne Probleme.

Danach konnten manche Server nicht mehr angemeldet werden (Benutzername Passwort falsch) -> da habe ich das MaschinenPasswort zurückgesetzt via Powershell

augenscheinlich läuft jetzt alles wieder.. ABER

ich kann von einem Server nicht auf einen anderen Server per SMB zugreifen.

SMB-Freigabe = Server A

SMB-Client Server = Server B

irgendein dritter Server = Server C

Server B auf Server A, kein Zugriff möglich. Es kommt, dass der Pfad nicht gefunden wurde

von Server C kann ich auf Server A und Server B zugreifen, ohne Probleme

Ich habe alles probiert...

wenn ich den nicht funktionierenden Zugriff von Server B auf A starte, wird im DC folgendes ProtokollierT:

Es wurde ein Kerberos-Dienstticket angefordert.

Kontoinformationen:
   Kontoname:       Administrator@domain.LOCAL
   Kontodomäne:       domain.LOCAL
   Anmelde-GUID:       {8d65f0ca-0efc-dc10-1223-182bee81e08b}
   MSDS-SupportedEncryptionTypes:   N/A
   Verfügbare Schlüssel:   N/A

Dienstinformationen:
   Dienstname:       AG-SRVCLNODE01$
   Dienst-ID:       domain\AG-SRVCLNODE01$
   MSDS-SupportedEncryptionTypes:   0x1C (RC4, AES128-SHA96, AES256-SHA96)
   Verfügbare Schlüssel:   AES-SHA1, RC4

Domänencontrollerinformationen:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Verfügbare Schlüssel: AES-SHA1, RC4

Netzwerkinformationen:
   Client-Adresse:       ::ffff:192.168.1.49
   Client-Port:       49778
   Beworbene E-Typen:
       AES256-CTS-HMAC-SHA1-96
       AES128-CTS-HMAC-SHA1-96
       RC4-HMAC-NT
       RC4-HMAC-NT-EXP
       RC4-HMAC-OLD-EXP

Zusätzliche Informationen:
   Ticketoptionen :       0x40810000
   Ticketverschlüsselungstyp:   0x12
   Sitzungsverschlüsselungstyp:   0x12
   Fehlercode:       0x0
   Übertragene Dienste:   -

Ticketinformationen
Ticket-Hash anfordern: 032kGYblSyvg1A1USYrE5j9ozeSkarob0xy/zEN6NNk=
Antwort Ticket-Hash: WvkSPncrq23CP8RQXMpg8q1714+GGZeBY48Es2cFVGg=

Dieses Ereignis wird jedes Mal generiert, wenn Zugriff auf eine Ressource angefordert wird, wie z. B. auf einen Computer oder einen Windows-Dienst. Der Dienstname steht für die Ressource, auf die der Zugriff angefordert wurde.

Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert werden, indem die Anmelde-GUID-Felder in jedem Ereignis verglichen werden. Das Anmeldeereignis findet auf dem Computer statt, auf den zugegriffen wurde, der oft ein anderer Computer ist als der Domänencontroller, der das Dienstticket ausgestellt hat.

Vorauthentifizierungstypen, Ticketoptionen, Verschlüsselungstypen und Ergebniscodes sind in RFC 4120 definiert.

Server B protokolliert in dem Moment folgendes:

Fehler beim Anmelden eines Kontos.

Antragsteller:
   Sicherheits-ID:       NULL SID
   Kontoname:       -
   Kontodomäne:       -
   Anmelde-ID:       0x0

Anmeldetyp: 3

Konto, für das die Anmeldung fehlgeschlagen ist:
   Sicherheits-ID:       NULL SID
   Kontoname:       Administrator
   Kontodomäne:       domain.LOCAL

Fehlerinformationen:
   Fehlerursache:       Bei der Anmeldung ist ein Fehler aufgetreten.
   Status:           0xC000006D
   Unterstatus::       0x0

Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: -

Netzwerkinformationen:
   Arbeitsstationsname:   -
   Quellnetzwerkadresse:   192.168.1.49
   Quellport:       49775

Detaillierte Authentifizierungsinformationen:
   Anmeldeprozess:       Kerberos
   Authentifizierungspaket:   Kerberos
   Übertragene Dienste:   -
   Paketname (nur NTLM):   -
   Schlüssellänge:       0

Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.

Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".

Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).

Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.

Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.

Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
   - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
   - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
   - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.

Genau die gleichen Logs wie wenn wir die "wir können uns nicht mehr Anmelden" Probleme haben, komisch ist das Sicherheits-ID in dem Moment immer NULL SID steht.

Den Artikel von @testperson bin ich durchgegangen, der passt sehr gut zu "unseren Problemen" . Aber wir haben das geprüft, RC4 scheint bei uns nicht deaktiviert zu sein

Anmelden

Anmeldeprobleme - Benutzername / Passwort falsch

Empfohlene Beiträge

stevenki 2

cj_berlin 1.508

NilsK 3.046

stevenki 2

stevenki 2

zahni 587

NilsK 3.046

MurdocX 1.004

stevenki 2

daabm 1.431

MurdocX 1.004

stevenki 2

testperson 1.860

stevenki 2

stevenki 2

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Benutzerkonto erstellen

Anmelden

Menu

Aktivitäten