Hi,

damit mal getestet?

https://www.netwrix.de/account_lockout_examiner.html

Gruß,
Ralf

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:

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.

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

Veröffentlicht von: @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.

Veröffentlicht von: @tomtom

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

@tomtom

Veröffentlicht von: @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}
}

Quellenangabe

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 :)

Veröffentlicht von: @tomtom

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.