Fehler beim Anmelden eines Kontos.

Antragsteller:
	Sicherheits-ID:		SYSTEM
	Kontoname:		ANDI$
	Kontodomäne:		ANDILING
	Anmelde-ID:		0x3E7

Anmeldetyp:			4

Konto, für das die Anmeldung fehlgeschlagen ist:
	Sicherheits-ID:		NULL SID
	Kontoname:		@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAADAwAgRAMEA5AQOAMDAyAQLAADAwAgRAgDAtAANAYEAwAgNA0CA4AQRAUDA2AQLAQDAyAAOAADAwAANAUDAFBAOAYEA3AANA0HA
	Kontodomäne:		

Fehlerinformationen:
	Fehlerursache:		Unbekannter Benutzername oder ungültiges Kennwort.
	Status:			0xC000006D
	Unterstatus::		0xC0000064

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

Netzwerkinformationen:
	Arbeitsstationsname:	ANDI
	Quellnetzwerkadresse:	-
	Quellport:		-

Detaillierte Authentifizierungsinformationen:
	Anmeldeprozess:		Advapi  
	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.

Genau, das sind die Daten von SYSTEM und das ist auch so wie es vom System her sein soll, nur ich hätte es gerne als bestimmten Benutzer (ist aber nicht tragisch, wie geschrieben, muss ich halt die Skripte etwas anpassen).

[code]Fehler beim Anmelden eines Kontos.

Antragsteller:
Sicherheits-ID: SYSTEM
Kontoname: ANDI$
Kontodomäne: ANDILING
Anmelde-ID: 0x3E7

Anmeldetyp: 4

Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: @@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAADAwAgRAMEA5AQOAMDAyAQLAADAwAgRAgDAtAANAYEAwAgNA0CA4AQRAUDA2AQLAQDAyAAOAADAwAANAUDAFBAOAYEA3AANA0HA
Kontodomäne:

Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC0000064

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

Netzwerkinformationen:
Arbeitsstationsname: ANDI
Quellnetzwerkadresse: -
Quellport: -

Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: Advapi
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.[/code]

USERNAME=LAPTOP$
USERPROFILE=C:\WINDOWS\system32\config\systemprofile

Wenn Du robocopy als SYSTEM ausführst, dann befindest Du Dich auch im Profil des Benutzers "SYSTEM":

[code]USERNAME=LAPTOP$
USERPROFILE=C:\WINDOWS\system32\config\systemprofile[/code]
Das ist so vollkommen richtig und muss auch so sein. Hat nichts mit Device/Credential Guard zu tun.

Dein ursprüngliches Problem verstehe ich da aber noch nicht so ganz. Wenn das Problem noch besteht, was steht denn genau in Event ID 4625 drin?

Na "Timeout Zugriff Credential Manager?" passt wohl nicht mehr so ganz.
Ja, es läuft überall die .207.

:dankeschoen:

Was möchtest du denn ändern?

Und sorry, deine Frage ist wohl untergegangen. Daher nachträglich :willkommen:
Hast du inzwischen die *.207 installiert?

Frage vorweg: kann man die Überschrift nachträglich ändern?

Durch Zufall (bei Installation eines PCs und dann dort ebenfalls auftretendem Fehler) bin ich der Sache auf die Spur gekommen...

Sobald ein Task mit der Option "Kennwort nicht speichern. Die Aufgabe greift nur auf lokale Computerresourcen zu." ausgeführt wird geht der Zugriff auf die Logindaten futsch. Wenn ich den Task mit Kennwort abspeichere funktioniert alles wie gewünscht.

Nur auf meinem Hauptrechner bekomme ich dann die Tasks nicht mehr zum Laufen (Event ID 4625 mit einem kryptischen Nutzernamen, den es nicht gibt, wird dann protokolliert). Jetzt laufen sie halt als SYSTEM, das klappt, allerdings gibt er dann bei den Umgebungsvariablen (USERNAME, USERPROFILE, APPDATA, LOCALAPPDATA) halt SYSTEM als Konto zurück und ein bisschen Anpassungsarbeit ist von Nöten, damit die richtigen Verzeichnisse angesprochen werden. Vielleicht liegt es daran, dass dort Enterprise und Device/Credential Guard läuft.

Ich konnte das jetzt bei diversen Rechnern (zumeist frisch installierten) ausnahmslos so nachstellen.

Hallo,
vielleicht weiß ja jemand von den Fachleuten hier Rat... ich habe ein Inplace-Upgrade von 18362 auf 19041 gemacht.
Seitdem habe ich Probleme mich mit Netzlaufwerken zu verbinden, auch Outlook verlangt öfters beim Start das Passwort zum Mailserver bzw. bringt eine Fehlermeldung beim Versand einer signierten / verschlüsselten Mail weil es wohl auf das Zertifikat nicht zugreifen kann.
Der Rechner, der 7x24 angemeldet läuft, ist zwar kein Teil eines AD aber auf den verschiedenen Geräten ist der Nutzer mit dem gleichen Benutzernamen / dem gleichen Passwort angelegt (um ein Ändern des Passwortes übersichtlich zu gestalten bzw. um nicht jeden einzelnen Host in der Anmeldeinformationsverwaltung anlegen bzw. wieder ändern zu müssen, außerdem laufen im Hintergrund geplante robocopy-Scripte).
Das Problem ist erst einmal für mich überhaupt der Ursache auf den Grund zu gehen, da es ja außer "Benutzername/Passwort falsch" keine Fehlermeldungen gibt. Auffällig ist, dass es direkt nach dem Entsperren funktioniert aber nach einer Zeit x dann nicht mehr klappt (daher "timeout" im Betreff). Wenn ich den Computer dann sperre und wieder entsperre klappt es erneut für eine zeitlang. Das Problem existiert bei der .84 (dort bin ich dann wieder zurück) und der .113 (läuft aktuell noch). Wenn ich einen Nutzer neu anlege hat der das gleiche Problem.
Gibt es da irgendwo eine Einstellung oder sonst was oder woran könnte das liegen?
Vielen Dank!
Andreas