“Neuer PC, neue Probleme” könnte man sagen. Vor ein paar Tagen wurde bei einem Kunden damit begonnen, diverse PCs auszutauschen, leider tauchte ein unerwartetes Problem auf.
Gleich beim ersten PC tritt sehr häufig das Phänomen auf, das man bei der Anmeldung trotz der Angabe von richtigen Benutzername samt Kennwort dennoch eine Meldung erscheint, das die Daten falsch wären. Versucht man es dann weiter oder startet den PC ein paar Male neu, klappt es dann plötzlich. Gleiches gilt, wenn der PC mal gesperrt war.
Oft, aber nicht immer wird die der ganzen Show nicht im Ereignisprotokoll (Sicherheit) erfasst. Wenn dann mal doch, dann sieht es so aus:
Protokollname: Security Quelle: Microsoft-Windows-Security-Auditing Datum: 01.02.2022 08:28:53 Ereignis-ID: 4625 Aufgabenkategorie:Logon Ebene: Informationen Schlüsselwörter:Überwachung gescheitert Benutzer: Nicht zutreffend Computer: pc07.domain.local Beschreibung: Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: SYSTEM Kontoname: PC07$ Kontodomäne: domain Anmelde-ID: 0x3E7 Anmeldetyp: 2 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: benutzername Kontodomäne: domain Fehlerinformationen: Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort. Status: 0xC000006D Unterstatus:: 0xC000006A Prozessinformationen: Aufrufprozess-ID: 0x6b8 Aufrufprozessname: C:\Windows\System32\svchost.exe Netzwerkinformationen: Arbeitsstationsname: PC07 Quellnetzwerkadresse: 127.0.0.1 Quellport: 0 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: User32 Authentifizierungspaket: Negotiate Ü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.
Am Server (Windows Server 2019 Standard, AD-Domänennetzwerk) sieht man nichts von den Anmeldeproblemen. Bei anderen baugleichen PCs die vorher oder nachfolgend von diesem einem System beim Kunden platziert wurden gibt es dieses Anmeldeproblem auch nicht.
DNS, die Verarbeitung der GPOs, usw. ist alles in Ordnung, dennoch klingt das Ganze irgendwie nach Timing. Kurios dabei ist: Die Anmeldung via pcvisit und rdp klappt dagegen immer, es hängt also nur an der interaktiven Konsolensitzung. Wenn man mal angemeldet ist und nicht neu startet oder den Computer sperrt klappt auch alles.
Gelöst ist es noch nicht. Zum jetzigen Zeitpunkt ist der PC-Hersteller informiert und wir warten auf Rückmeldung. Testweise habe ich mal via GPO konfiguriert das beim (Neu-)Starten immer auf das Netzwerk gewartet werden soll.
Als weiteres könnte ich mir noch Probleme speziell mit der USB-Tastatur oder USB im Allgemeinen oder mit der Netzwerkkarte und deren Treiber vorstellen, wobei ich irgendwie (noch nicht) ans Netzwerk oder USB glaube. Wäre der Computer schneller hochgefahren, als dass das Netzwerk bereit wäre, hat man bestimmte Einträge im Ereignisprotokoll und weiteres funktioniert nicht, das ist aber hier soweit aktuell bekannt ist nicht der Fall.
Das die USB-Tastatur richtig funktioniert lässt sich beim Eintippen von Benutzername samt Kennwort und vor dem Drücken der Eingabetaste durch das Anzeigen des Kennworts prüfen. Hier stimmt einfach alles und dennoch scheitert die Anmeldung.
In der Vergangenheit hatte ich sowas nur mal mit G Data oder einer PS/2-USB-Kombi. In diesem Fall kommt allerdings Securepoint AntiVirus Pro zum Einsatz, da gibt’s kein (problematischen) USB-Guard.
Kennt jemand dieses Phänomen oder ähnliches?
Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.