Hallo alle zusammen,
ich habe bereits seit mehreren Wochen das Problem das mein DC selbst mein Admin-Konto sperrt. Ich habe Anfang Juni ein neues Passwort für den Admin festgelegt. Was bisher immer ohne Probleme funktioniert hatte. Ich habe in sämtlichen mir bekannten Aufgaben und Diensten das Kennwort aktualisiert so wie Anfang des Jahres auch schon, nur mit dem Unterschied das mein Konto da nie gesperrt wurde.
Netzlaufwerke werden über GPO und User Profil im AD gemappt.
Ich habe bereits folgende GPO's zur Überwachung aktiviert:
Anmeldeereignisse überwachen, Anmeldeversuche überwachen, Prozessverfolgung überwachen, Computerkontenverwaltung überwachen, Benutzerkontenverwaltung überwachen, Verzeichnisdienständerung überwachen, Kontosperrung überwachen, Anmelden überwachen, Abmelden überwachen, Spezielle Anmeldung überwachen. Alle GPO's haben die Einstellung "Erfolgreich, Gescheitert".
Ich kann die Kontosperrung in der Ereignisanzeige beobachten dort wird folgendes Protokoliert:
Ein Benutzerkonto wurde gesperrt.
Antragsteller:
Sicherheits-ID: SYSTEM
Kontoname: ServerName$
Kontodomäne: meineDomäne
Anmelde-ID: 0x3E7
Gesperrtes Konto:
Sicherheits-ID: meineDomäne\adminkonto
Kontoname: adminkonto
Weitere Informationen:
Aufrufcomputername: ServerName
Wird vor der Sperrung des AdminKontos nicht protokolliert.
Ist das AdminKonto gesperrt wird auch die Event-ID 4625 protokolliert.
User Name: AdminKonto
User DN: CN=AdminKonto ,CN=Users,DC=TB,DC=meineDomäne,DC=DE
Domain Name: TB.meineDomäne.DE
DNS Domain Name: TB.meineDomäne.DE
Server Name,Site Name,User State,Bad Password Count,Last Bad Password,Pwd Last Set,Lockout Time,Original Lock
ServerName[PDC],Default-First-Site,Not Locked (Auto Unlocked),5,06.07.2022 09:12:06,09.06.2022 12:40:42,06.07.2022 09:12:06,ServerName
Ich komme nun an meine Grenzen und somit nicht weiter. Eventuell hat von euch jemand eine Idee wo ich noch ansetzen kann.
MfG
tomtom
Guten Morgen Ralf,
danke für den Hinweis.
Die Aufgaben & Dienste die mir angezeigt wurden habe ich bereits aktualisiert. Im Verlauf kann ich auch erkennen das das die Aufgaben ohne Fehler laufen. Die gelisteten Dienste habe ich deaktiviert, da sie nur sporadisch benötigt werden. Kennwort wurde aber dennoch aktualisiert. Das Admin-Konto wird weiterhin gesperrt.
Netwrix gibt folgenden Hinweis aus:
Anmeldeinformationen auf 'ServerName.TB.meineDomäne.DE' konnten nicht gelesen werden. Die Sitzungs-ID für den Benutzer „TB.meineDomäne.DE\adminkonto“ kann nicht gefunden werden.
Gruß
tomtom
hast du irgenwelche Scheduled Tasks auf irgendwelchen Servern, welche im Kontext des Admins eingerichtet wurden? Das könntest du auch per Script rauskriegen, indem du dir für jeden Server die sched. Tasks abfragst und dort dann den User, der sie eingerichtet hat.
was anderes würde mir ad hoc nicht einfallen.
Gruß,
Ralf
Hallo,
ich habe alle Aufgaben durchgesehen. Geht händisch recht schnell habe nicht so viele Server am laufen.
Alle Aufgaben die das "adminkonto" hinterlegt haben laufen durch sofern das "adminkonto" nicht gesperrt ist. Mittlerweile dauert es keine 20 Minuten mehr bis das Konto gesperrt wird. Anfangs waren es fast immer 60 Minuten.
Gruß
tomtom
hmm, hier noch ein guter Beitrag, vielleicht bekommst du es damit raus:
https://activedirectorypro.com/find-the-source-of-account-lockouts/
Gruß,
Ralf
Hallo Monthy,
zunächst Danke für deine Tipps. Ich habe auch mit dem neuem Artikel keine Lösung gefunden. Das Tool wertet auch "nur" die Ereignisanzeige aus.
Was ich noch nicht erwähnt hatte war das ich auch das Netlogon Debugging aktiviert habe aber nicht schlau draus geworden bin. Der Artikel brachte mich nochmal auf den Gedanken das Debugging zu betrachten. Dabei sind mir folgende Zeilen aufgefallen, kann sie aber nicht eindeutig auswerten. Eventuell hat hier jemand mehr Erfahrung damit und kann mir weiterhelfen.
07/07 13:20:00 [LOGON] [3844] meineDomäne: SamLogon: Transitive Network logon of meineDomäne\adminkonto from serverName(via serverName2) Returns 0xC0000234
07/07 13:20:00 [LOGON] [7380] meineDomäne: SamLogon: Transitive Network logon of meineDomäne\adminkonto from serverName(via serverName2) Entered
07/07 13:20:00 [LOGON] [7380] Calling LsaIFilterInboundNamespace for TrustName:'TC.meineDomäne.de' Flags:0x0 MsvAvNbDomainName:'meineDomäne2' MsvAvDnsDomainName:'TC.meineDomäne.DE'
07/07 13:20:00 [LOGON] [7380] LsaIFilterInboundNamespace succeeded - FilterInboundNamespaceSucceeded
Das Netzwerk ist wie so oft historisch gewachsen. Meine Vorgänger haben bei zwei Häusern zwei Netzwerke mit eigenen Domänen und DC eingerichtet. Anschließend haben Sie zwischen den Domänen eine Vertrauensstellung eingerichtet. Wenn ich die Zeilen richtig interpretiere dann heißt das, dass das adminKonto zwar vom DC, aus TB.meineDomäne.DE, gesperrt wird aber die Login-Anforderung vom DC aus TC.meineDomäne.DE kommt? Wen dem so ist dann muss ich mir doch den DC im vertrauten Netzwerk ansehen, oder irre ich mich?
Gruß
tomtom
Wenn ich die Zeilen richtig interpretiere dann heißt das, dass das adminKonto zwar vom DC, aus TB.meineDomäne.DE, gesperrt wird aber die Login-Anforderung vom DC aus TC.meineDomäne.DE kommt? Wen dem so ist dann muss ich mir doch den DC im vertrauten Netzwerk ansehen, oder irre ich mich?
ja, dann musst du ebenfalls die Quelle ansehen und auch da ggf. das Logging hochdrehen.
Grundfrage wäre, ob das mit der AD Trennung so sein soll/bleiben muss, oder ob du nicht migrieren kannst. Hat mit dem jetzigen Problem nichts zu tun, aber momentan erschwert es dir ja deine Fehlereingrenzung.
Gruß,
Ralf
Hallo,
die Zusammenlegung der beiden Domänen ist definitiv geplant. Der Verwaltungsaufwand ist mir zu hoch. Leider steht in der zweiten Domäne unser Exchange-Server. Auf dem DC in der zweiten Domäne liegen alle Verknüpften Konten aus der ersten Domäne für den Exchange. Dann wurde viel mit NAT gearbeitet und nichts aber auch rein gar nichts dokumentiert. Ich traue mich daher an die Migration noch nicht ran.
Noch zu meiner Sperrung. Ich habe auf dem DC in der zweiten Domäne das Logging aktiviert. Ich kann aber in den Log's nichts finden was die Sperrung des AdminKontos in der ersten Domäne erklären würde. Ich habe alle Dienste und Tasks geprüft. Es ist mir schleierhaft wo die Sperrung ausgelöst wird. Es müssten doch irgendwo zeitliche Überschneidungen vorhanden sein es ist aber nichts zu finden.
Ich werde am Wochenende nochmal tief in mich gehen und überlegen was zwischen der letzten und dieser Kennwortänderung dazugekommen ist. Denn wie ich anfangs schon erwähnte, die Kennwörter des Admins ändere ich regelmäßig in unregelmäßigen abständen und nie hatte ich diese Probleme.
Gruß und schönes Wochenende
tomtom
dann empfehle ich ja fast grüne Wiese, bevor du dir da das Migrieren antust. Oder direkt gleich alles nach O365/Azure. Kommt halt auf die Unternehmensgröße an und die Vorgaben von der GF.
Denn wie ich anfangs schon erwähnte, die Kennwörter des Admins ändere ich regelmäßig in unregelmäßigen abständen und nie hatte ich diese Probleme.
mal zum Spass auf das letzte Kennwort manuell gesetzt und beobachtet, ob dann wieder alles gut ist?
Gruß
Guten Morgen,
Cloud kommt mir nicht ins Haus. Ich hatte mal einen Exchange in der Cloud. Das teil lief vorn und hinten nicht. Der Support hat die Schuld von Microsoft zum Anbieter und der Anbieter wieder zurück zu Microsoft geschoben und wir als Kunde haben in die Röhre gesehen. Für mich ist das Thema Cloud beendet.
Die grüne Wiese ein Traum...
Ich verfolge gerade einen anderen Ansatz. Im Protokoll zur Ereignis-ID 4625 auf dem DC im vertrauten Netz steht der Quellport. Somit kenn ich das Netzt und den Port. In den Protokollen meiner Firewall konnte ich nun nach dem Quellport Filtern und habe einen Rechner identifizieren können. Ich mach mich heute auf die Suche nach diesen Rechner und hoffe das ich endlich den Verursacher gefunden habe.
Anderenfalls bleibt mir nur noch die Möglichkeit einen neuen Admin einzurichten und den alten stillzulegen und zu hoffen das es irgendjemanden mal auffällt das irgendein Dienst nicht funktioniert.
Gruß
tomtom
In den Protokollen meiner Firewall konnte ich nun nach dem Quellport Filtern und habe einen Rechner identifizieren können. Ich mach mich heute auf die Suche nach diesen Rechner und hoffe das ich endlich den Verursacher gefunden habe.
klingt vielversprechend. Ich tippe bei diesem Rechner trotzdem auf einen Scheduled Task, der mit den abgelaufenen Creds versucht, Aktion XY durchzuführen und dir dann das Konto sperrt.
kannst ja mal die Tasks remote abfragen (Abfrage noch anpassen)
Get-ScheduledTask -CimSession <servername>|? ({$_.author -ne $null -and $_.author -notlike "*microsoft*"})|select taskname, author
Gruß,
Ralf
Hallo,
Leider ist auch dieser Strohhalm gebrochen. Auf dem Rechner in der Domäne TC ist alles in Ordnung. Es werden keine Tasks ausgeführt. Keine veralteten Windows Anmeldeinformationen, keine Netzlaufwerke oder Dienste die dazwischen funken.
In der Netlogon.log wird der Anmeldeversuch erst protokolliert wenn das Konto bereits gesperrt ist. Der verdacht das der Aufrufer im vertrauten Netz steht hat sich zerschlagen. Bei anderen Anmeldungen steht ebenfalls (via ServerTC). Ich vermute das mir der DNS Server zwischenfunkt. Warum MS meint hier den entfernten DNS zur Auflösung zur nehmen leuchtet mir nicht ein.
Ich stehe also wieder am Anfang und gehe davon aus das der DC auf dem das Admin Konto liegt auch der Verursacher ist.
Ich habe nochmal alle Aufgaben deaktiviert und die Sperrung des Kontos ist nach ca. 50 - 60 min wieder aktiv.
Ich bin mit meinem Wissen am Ende und habe nur noch Fragezeichen im Kopf.
Gruß
tomtom
hmm, unschön. Aber dann würde ich vielleicht so vorgehen:
mittels Script alle Domain Servers "abklappern" und jeweils die Tasks auslesen hinsichtlich von dem Adminkonto eingerichteten Tasks (bzw in dessen Kontext ausgeführten Tasks).
Dann neuen Admin erstellen/ kopieren vom jetzigen (oder gleich umbau auf pers. Adminaccounts) und entsprechend berechtigen.
Alten Admin Account deaktivieren und warten, wer wann schreit.
Nachtrag, grad gefunden, nicht selber getestet...aber klingt gut:
Hiermit sollten alle DC's abgefragt werden und dir den Computer ausgeben, von dem der Lockout für den User kam.
Natürlich halten die DC's das nicht ewig vor (Log Rotation nach ich meine 10MB), aber das kannst du ja in den Eventlogeigenschaften anpassen.
$Usr = ‘username1’
Get-ADDomainController -fi * | select -exp hostname | % {
$ParamsEvn = @{
‘Computername’ = $Pdc
‘LogName’ = ‘Security’
‘FilterXPath’ = "*[System[EventID=4740] and EventData[Data[@Name='TargetUserName']='$Usr']]"
}
$Evnts = Get-WinEvent @ParamsEvn
$Evnts | foreach {$_.Computer + " " +$_.Properties[1].value + ' ' + $_.TimeCreated}
}
Gruß,
Ralf
Und wenn das nicht hilft, hat zumindest mir bisher immer das Netlogon.log geholfen. Ich habe aber auch nirgends so eine "schräge" Umgebung, wie die hier beschriebene. ;)
Guten Morgen,
Monthy dir erstmal vielen Dank für deine Tipps und Ratschläge. Das Skript lief nachdem ich die Variable $Pdc mit (Get-AdDomain).PDCEmulator ersetzt hatte durch. Das Skript sagte Schlussendlich auch nur das, was ich bzw. wir schon wussten der DC sperrt das Konto.
Ich habe mir darauf und auf Norbert aussage hin noch mal das Netlogon.log vorgenommen und mir alle Return-Werte angesehen. Schließlich viel mir auf das ich nur oberflächlich ausgewertet habe. Nach dem ich nach dem Return-Wert 0xc00006a gesucht habe viel der Groschen. Alle Rechner aus der Domäne TB konnten sich nicht mit dem AdminKonto anmelden. Auf den Arbeitsstationen selbst wurde der fehlerhafte Login protokolliert. Durch die zuvor bereits aktivierte Prozessverfolgung konnte dann der G-Data Agent Server identifiziert werden. Anhand der Anmelde-ID 4 war schnell klar das es der Gruppenauftrag zum täglichen Scan war.
Ich gehe davon aus dass das Konto jetzt aktiv bleibt. Ich werde es noch weiter beobachten und melde mich abschließend nach meinem 3 wöchigen Urlaub zurück.
Bis dahin euch beiden mein Dank für die Unterstützung.
Gruß
tomtom
dann mal schönen Urlaub :)
Anhand der Anmelde-ID 4 war schnell klar das es der Gruppenauftrag zum täglichen Scan war
meint das, dass der Scanauftrag/Task im Kontext des Admins ausgelöst wurde auf den Workstations?
Gruß,
Ralf
Richtig. In der Aufgabe konnte man zusätzlich wie auch bei den Windows Aufgaben ein Konto mit Admin Rechten angeben.
Somit soll laut Aussage G-Data der Datei-Zugriffsfehler beim Scan minimiert werden.
Wäre das Admin-Konto in beiden Domänen gesperrt worden, wäre ich eventuell eher darauf gekommen. Aber in der Domäne TC wurde im Scanauftrag kein Admin-Benutzer hinterlegt. Aus diesem Grund habe ich G-Data gar nicht weiter betrachtet. Ein Fehler der mir kein zweites Mal passiert.
Hallo alle zusammen,
Urlaub vorbei und siehe da das Konto wird noch immer gesperrt. Ich spring bald im Dreieck.
Ich werde weiter suchen und meine Ergebnisse hier berichten. Eventuell hilft es jemanden der auch mal vor diesem Problem steht.
Gruß und schönes Wochenende
tomtom
interessanterweise hatte ich das Problem Juni/Juli über auch. Hat sich dann aber mit mehrmaligem rebooten (gefühlt vor allem reboots der ADC) und Udpates installieren speziellerweise gelöst. Netwrix und Konsorten haben leider nichts gebracht.