Fragensteller
Manche User werden immer wieder gesperrt

Allgemeine Diskussion
-
Liebe NG!
ich habe das Problem, daß manche (admin User) immer wieder gesperrt werden.
Wenn ich am DC im EventLog Security nach Event ID 4740 suche, wird mir der gesperrte User angezeigt.
Die Information dort, sagt aber nicht aus, warum der User gesperrt wurde.
Es handelt sich um eine W2012R2 Domäne.
Wie kann ich nähere Informationen dazu finden, warum dieser einer Account gesperrt wird?
Mögliche Ursachen, was ich mir vorstellen kann, daß nach einer Kennwortänderung durch die Aufgabenplanung eine Usersperre verursacht werden kann?
Wenn es durch das Anmelden mit einem falschen Kennwort verursacht wird, würde ich gerne wissen von welchem PC aus die Anmeldung statt fand. Gibt es dazu auch ein EventLog?
Vielen Dank voraus!
Alle Antworten
-
Moin,
Du brauchst die Event ID 4625, da steht alles nötige drin (Computer, Logon-Typ usw.).
Evgenij Smirnov
-
Hallo Evgenij,
vielen Dank! Die ID sagt viel aus, wovon ich aber dennoch nicht schlau werde. Möglicherweise kann mir jemand mehr darüber sagen:
Protokollname: Security
Quelle: Microsoft-Windows-Security-Auditing
Datum: 02.05.2019 19:58:08
Ereignis-ID: 4625
Aufgabenkategorie:Anmelden
Ebene: Informationen
Schlüsselwörter:Überwachung gescheitert
Benutzer: Nicht zutreffend
Computer: TermServ01.compassio.local
Beschreibung:
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: SYSTEM
Kontoname: TermServ01$
Kontodomäne: MyDom
Anmelde-ID: 0x3E7
Anmeldetyp: 4
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: MAXWILD
Kontodomäne: MyDom
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder ungültiges Kennwort.
Status: 0xC000006D
Unterstatus:: 0xC000006A
Prozessinformationen:
Aufrufprozess-ID: 0x5dc
Aufrufprozessname: C:\Windows\System32\svchost.exe
Netzwerkinformationen:
Arbeitsstationsname: TermServ01
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.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>4625</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2019-05-02T17:58:08.020916200Z" />
<EventRecordID>1953813</EventRecordID>
<Correlation />
<Execution ProcessID="1744" ThreadID="4412" />
<Channel>Security</Channel>
<Computer>TermServ01.compassio.local</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">TermServ01$</Data>
<Data Name="SubjectDomainName">MyDom</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
<Data Name="TargetUserSid">S-1-0-0</Data>
<Data Name="TargetUserName">MAXWILD</Data>
<Data Name="TargetDomainName">MyDom</Data>
<Data Name="Status">0xc000006d</Data>
<Data Name="FailureReason">%%2313</Data>
<Data Name="SubStatus">0xc000006a</Data>
<Data Name="LogonType">4</Data>
<Data Name="LogonProcessName">Advapi </Data>
<Data Name="AuthenticationPackageName">Negotiate</Data>
<Data Name="WorkstationName">TermServ01</Data>
<Data Name="TransmittedServices">-</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x5dc</Data>
<Data Name="ProcessName">C:\Windows\System32\svchost.exe</Data>
<Data Name="IpAddress">-</Data>
<Data Name="IpPort">-</Data>
</EventData>
</Event> -
Moin,
Logon Type 4 ist "Batch", also in der Regel ein geplanter Task.
Evgenij Smirnov
-
Da die Aufgabenplanung nun mal das geänderte Kennwort nicht kennt, und die Aufgabe nun nicht mehr existiert, hast du dein Problem wohl gefunden.
Wenn man ein Kennwort regelmäßig ändert, so ist es doch ganz normal, dass man alle Stellen, an denen man das Kennwort verwendet, ebenso anpassen muss.
Eine Dokumentation ist da manchmal schon hilfreich;-).