27
AD- Benutzer gesperrt - warum?
Hallo zusammen.
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde. Alle sagen das gleiche – es wurde das richtige Kennwort eingegeben und keiner hat sich vertippt.
Ich habe eine GPO erstellt, die einen Benutzer sperrt, wenn man 5x das falsche Kennwort eingibt.
Im Event Viewer (Win Server 2019) unter Security sehe ich unter der Event ID: 4740 nur wann welcher Benutzer gesperrt wurde, das hilft mir aber nicht wirklich weiter, denn das er gesperrt wurde, weiß ich ja. Kann ich irgendwo irgendwie auch sehen, wieso er gesperrt wurde?
Vielen Dank für eure Hilfe.
Viele Grüße
Tom
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde. Alle sagen das gleiche – es wurde das richtige Kennwort eingegeben und keiner hat sich vertippt.
Ich habe eine GPO erstellt, die einen Benutzer sperrt, wenn man 5x das falsche Kennwort eingibt.
Im Event Viewer (Win Server 2019) unter Security sehe ich unter der Event ID: 4740 nur wann welcher Benutzer gesperrt wurde, das hilft mir aber nicht wirklich weiter, denn das er gesperrt wurde, weiß ich ja. Kann ich irgendwo irgendwie auch sehen, wieso er gesperrt wurde?
Vielen Dank für eure Hilfe.
Viele Grüße
Tom
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 31640074772
Url: https://administrator.de/contentid/31640074772
Printed on: May 5, 2024 at 12:05 o'clock
27 Comments
Latest comment
Moin @tom990
schau doch mal nach ob die USER eine Ablaufzeit haben, die sie zum Kennwortwechsel zwingt. Dass ist eigentlich in Windows Server inzwischen voreingestellt so.
Kreuzberger
schau doch mal nach ob die USER eine Ablaufzeit haben, die sie zum Kennwortwechsel zwingt. Dass ist eigentlich in Windows Server inzwischen voreingestellt so.
Kreuzberger
Hallo,
die Klassiker schon überprüft?
Gruß
TA
die Klassiker schon überprüft?
- Zahlen im Passwort werden über den Ziffernblock eingegeben, aber NUM-Lock ist aus. ( -> Zahlen oberhalb der Buchstaben benutzen)
- Passwort wurde geändert, nicht aber am Handy (WLAN [bei RADIUS] oder Mail-Abruf).
Gruß
TA
Zitat von @kreuzberger:
Moin @tom990
schau doch mal nach ob die USER eine Ablaufzeit haben, die sie zum Kennwortwechsel zwingt. Dass ist eigentlich in Windows Server inzwischen voreingestellt so.
Kreuzberger
Moin @tom990
schau doch mal nach ob die USER eine Ablaufzeit haben, die sie zum Kennwortwechsel zwingt. Dass ist eigentlich in Windows Server inzwischen voreingestellt so.
Kreuzberger
Hallo.
Danke für deine schnelle Antwort.
Nein, das ist es nicht, denn ich habe das auf 360 Tage eingestellt und das Konto ist erst knapp eine Woche alt.
Hallo,
gibt es sonst etwas was Anmeldungen über das AD-Postfach ermöglicht? Exchange mit öffentlichen Webinterface, LDAP, WLAN Anmeldung, Web, irgendwas?
Stefan
gibt es sonst etwas was Anmeldungen über das AD-Postfach ermöglicht? Exchange mit öffentlichen Webinterface, LDAP, WLAN Anmeldung, Web, irgendwas?
Stefan
Zitat von @TwistedAir:
Hallo,
die Klassiker schon überprüft?
Gruß
TA
Hallo,
die Klassiker schon überprüft?
- Zahlen im Passwort werden über den Ziffernblock eingegeben, aber NUM-Lock ist aus. ( -> Zahlen oberhalb der Buchstaben benutzen)
- Passwort wurde geändert, nicht aber am Handy (WLAN [bei RADIUS] oder Mail-Abruf).
Gruß
TA
Hallo.
Danke für die Tipps aber leider nein.
Die Benutzer sagen, dass sie den Ziffernblock nicht verwendet haben, sondern die Zahlen über den Buchstaben.
Kennwörter wurden auch nicht verändert. Nachdem ich den Benutzer wieder entsperrt habe, konnten sie sich mit ihrem gewohnten Kennwort wieder normal anmelden.
Ich habe gedacht, dass es vielleicht in den Logfiles etwas gibt, was den Grund der Sperre verrät.
Zitat von @StefanKittel:
Hallo,
gibt es sonst etwas was Anmeldungen über das AD-Postfach ermöglicht? Exchange mit öffentlichen Webinterface, LDAP, WLAN Anmeldung, Web, irgendwas?
Stefan
Hallo,
gibt es sonst etwas was Anmeldungen über das AD-Postfach ermöglicht? Exchange mit öffentlichen Webinterface, LDAP, WLAN Anmeldung, Web, irgendwas?
Stefan
Hallo Stefan,
vielen Dank für deine Antwort.
Nein, das alles gibt es nicht. Es sind ganz normale PCs, der Benutzer ist in AD eingetragen und mit dem Kennwort kann er sich nur am PC anmelden. Sonst gibt es keine anderen Möglichkeiten.
Es gibt ca. 100 Benutzer. Ich fand es nur merkwürdig, dass gestern und heute sich ein paar (4) Benutzer meldeten, dass sie gesperrt wurden. Natürlich, das Erste, was sie sagten, war, dass sie sich nicht vertippt haben.
Moin,
Das soll vorkommen.
Das sagen die immer und es ist immer gelogen. Es gibt afaik zwei Möglichkeiten, warum ein Konto gesperrt ist: Der User hat das PW zu oft falsch eingegeben oder der Admin hat das Konto gesperrt. Mehr gibt es mit Bordmitteln erstmal nicht. Dass die User das falsch eingeben, ohne es zu merken kann sooooooo viele Ursachen haben (naja, so viele sind es dann auch wieder nicht). Num-Lock wurde schon genannt. Falsche Tastaturbelegung. Caps-Lock. Ja, das steht da drunter. Aber User sehen sowas nicht. Ich habe das selbst live und in Farbe erlebt. User gibt sein PW ein. Geht nicht. Er gibt es nochmal ein. Geht nicht. Ich frage ihn, ob ihm an der Maske nichts auffällt. Antwort: "Nein, wieso?" "Guck nochmal genauer hin!" Erst bei der dritten Aufforderung sah er dann, dass da drunter steht, dass die Feststelltaste aktiviert ist.
Glaube nie einem User.
Liebe Grüße
Erik
Zitat von @tom990:
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde.
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde.
Das soll vorkommen.
Alle sagen das gleiche – es wurde das richtige Kennwort eingegeben und keiner hat sich vertippt.
Das sagen die immer und es ist immer gelogen.
Es gibt afaik zwei Möglichkeiten, warum ein Konto gesperrt ist: Der User hat das PW zu oft falsch eingegeben oder der Admin hat das Konto gesperrt. Mehr gibt es mit Bordmitteln erstmal nicht. Dass die User das falsch eingeben, ohne es zu merken kann sooooooo viele Ursachen haben (naja, so viele sind es dann auch wieder nicht). Num-Lock wurde schon genannt. Falsche Tastaturbelegung. Caps-Lock. Ja, das steht da drunter. Aber User sehen sowas nicht. Ich habe das selbst live und in Farbe erlebt. User gibt sein PW ein. Geht nicht. Er gibt es nochmal ein. Geht nicht. Ich frage ihn, ob ihm an der Maske nichts auffällt. Antwort: "Nein, wieso?" "Guck nochmal genauer hin!" Erst bei der dritten Aufforderung sah er dann, dass da drunter steht, dass die Feststelltaste aktiviert ist. Glaube nie einem User.
Liebe Grüße
Erik
Tach,
nutzt Ihr eventuell Terminalserver? Kann es sein, daß die betroffenen Benutzer die Session mit altem Passwort nur getrennt haben? Und sich nicht korrekt abgemeldet oder die Terminalsession korrekt beendet haben?
Der Fehler mit gesperrten Benutzer tritt meistens dan auf, wenn RDP Session mit alten Credentials (Passwort) nurt getrennt werden. Aber am Cleint das Passwort geändert wurde.
Hierzu gab es in der Vergangenheit schon sehr viele Fragen. Nutze mal die Suchfunktion.
P.S. Hat auch schon Administratoren getroffen, weil diese RDP-Session nur getrennt haben, statt korrekterweise zu beenden.
Gruss Penny.
nutzt Ihr eventuell Terminalserver? Kann es sein, daß die betroffenen Benutzer die Session mit altem Passwort nur getrennt haben? Und sich nicht korrekt abgemeldet oder die Terminalsession korrekt beendet haben?
Der Fehler mit gesperrten Benutzer tritt meistens dan auf, wenn RDP Session mit alten Credentials (Passwort) nurt getrennt werden. Aber am Cleint das Passwort geändert wurde.
Hierzu gab es in der Vergangenheit schon sehr viele Fragen. Nutze mal die Suchfunktion.
P.S. Hat auch schon Administratoren getroffen, weil diese RDP-Session nur getrennt haben, statt korrekterweise zu beenden.
Gruss Penny.
Zitat von @erikro:
Moin,
Das soll vorkommen.
Das sagen die immer und es ist immer gelogen. Es gibt afaik zwei Möglichkeiten, warum ein Konto gesperrt ist: Der User hat das PW zu oft falsch eingegeben oder der Admin hat das Konto gesperrt. Mehr gibt es mit Bordmitteln erstmal nicht. Dass die User das falsch eingeben, ohne es zu merken kann sooooooo viele Ursachen haben (naja, so viele sind es dann auch wieder nicht). Num-Lock wurde schon genannt. Falsche Tastaturbelegung. Caps-Lock. Ja, das steht da drunter. Aber User sehen sowas nicht. Ich habe das selbst live und in Farbe erlebt. User gibt sein PW ein. Geht nicht. Er gibt es nochmal ein. Geht nicht. Ich frage ihn, ob ihm an der Maske nichts auffällt. Antwort: "Nein, wieso?" "Guck nochmal genauer hin!" Erst bei der dritten Aufforderung sah er dann, dass da drunter steht, dass die Feststelltaste aktiviert ist.
Glaube nie einem User.
Liebe Grüße
Erik
Moin,
Zitat von @tom990:
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde.
Ich hatte gestern und heute ein paar Fälle wo mich Benutzer anrufen und sagen, dass sie sich in ihr Konto am PC nicht anmelden können, weil der Benutzer gesperrt wurde.
Das soll vorkommen.
Alle sagen das gleiche – es wurde das richtige Kennwort eingegeben und keiner hat sich vertippt.
Das sagen die immer und es ist immer gelogen.
Es gibt afaik zwei Möglichkeiten, warum ein Konto gesperrt ist: Der User hat das PW zu oft falsch eingegeben oder der Admin hat das Konto gesperrt. Mehr gibt es mit Bordmitteln erstmal nicht. Dass die User das falsch eingeben, ohne es zu merken kann sooooooo viele Ursachen haben (naja, so viele sind es dann auch wieder nicht). Num-Lock wurde schon genannt. Falsche Tastaturbelegung. Caps-Lock. Ja, das steht da drunter. Aber User sehen sowas nicht. Ich habe das selbst live und in Farbe erlebt. User gibt sein PW ein. Geht nicht. Er gibt es nochmal ein. Geht nicht. Ich frage ihn, ob ihm an der Maske nichts auffällt. Antwort: "Nein, wieso?" "Guck nochmal genauer hin!" Erst bei der dritten Aufforderung sah er dann, dass da drunter steht, dass die Feststelltaste aktiviert ist. Glaube nie einem User.
Liebe Grüße
Erik
Hallo Erik.
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Also den Kampf gegen den Benutzer kann man definitiv nicht gewinnen.
Moin
- auf dem Server wird bei Event 4740 der Name oder ggf. die IP-Adresse des Rechners aufgeführt
- auf der betreffenden Arbeitsstation findest Du bei Event 4625 den Grund für die fehlgeschlagene Anmeldung.
Gruß
- auf dem Server wird bei Event 4740 der Name oder ggf. die IP-Adresse des Rechners aufgeführt
- auf der betreffenden Arbeitsstation findest Du bei Event 4625 den Grund für die fehlgeschlagene Anmeldung.
Gruß
Hallo @tom990.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Also den Kampf gegen den Benutzer kann man definitiv nicht gewinnen.
Doch den Kampf kann und wird man gewinnen. Einfach auf die DSGVO und due Unternehmenscompliance hinweisen.Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Also den Kampf gegen den Benutzer kann man definitiv nicht gewinnen.
Gegebenenfalls Meldung beim Datenschutzbeauftragten / Vorgesetzten oder Geschäftsleitung machen.
Das hilft. Als Administrator kann und darf man darauf hinweisen.
Und sollte man auch.
Gruss Penny.
Mahlzeit,
als ich las ....
..hätte ich sofort als Admin das Passwort geändert und ihr mitgeteilt, sofern das nochmal passiert wird der/die Vorgesetzte informiert.
Kreuzberger
als ich las ....
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Also den Kampf gegen den Benutzer kann man definitiv nicht gewinnen.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Also den Kampf gegen den Benutzer kann man definitiv nicht gewinnen.
..hätte ich sofort als Admin das Passwort geändert und ihr mitgeteilt, sofern das nochmal passiert wird der/die Vorgesetzte informiert.
Kreuzberger
Zitat von @tom990:
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Das ist ein Grund für eine Abmahnung. Das muss der Admin dem Vorgesetzten oder der Geschäftsleitung melden.
Zitat von @erikro:
Das ist ein Grund für eine Abmahnung. Das muss der Admin dem Vorgesetzten oder der Geschäftsleitung melden.
Zitat von @tom990:
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Bin voll deiner Meinung. Ich hatte vor kurzem eine Kollegin, die während ich im Büro neben ihr stand, ihren Ehemann angerufen hat und ihm dann ihren Benutzernamen und Kennwort für die VPN-Verbindung sagt, damit er mal was auf ihrem Notebook ausprobiert, ob es auch von zu Hause aus funktioniert.
Ich habe ihr gesagt, das darf sie doch nicht machen, worauf sie sagte: „das ist doch bloß mein Mann“.
Das ist ein Grund für eine Abmahnung. Das muss der Admin dem Vorgesetzten oder der Geschäftsleitung melden.
Sehe ich genauso!
Gruss Penny.
Wenn Nutzer sich eine Workstation teilen kommt es oft zu Sperrungen, weil niemand auf den Nutzernamen schaut, sondern alle direkt ihr Passwort einhacken ...
Grund für eine Sperrung KANN im Prizip nur ein "fehlerhaftens" Passwort sein. Entweder weil ein Dienst noch ein altes PW verwendet oder weil es "falsch" eingegeben wird.
Witzig wird es, wenn Funktastaturen sich mit dem falschen PC verbinden und die Nutzer sich wundern, wieso an ihrem PC nichts passiert ...
Grund für eine Sperrung KANN im Prizip nur ein "fehlerhaftens" Passwort sein. Entweder weil ein Dienst noch ein altes PW verwendet oder weil es "falsch" eingegeben wird.
Witzig wird es, wenn Funktastaturen sich mit dem falschen PC verbinden und die Nutzer sich wundern, wieso an ihrem PC nichts passiert ...
Noch witziger wird es, wenn mehrere Benutzer sich PCs teilen, die LogInMaske so eingestellt ist, dass erst einmal nur das Passwort einzugeben ist wobei der letzte Benutzername noch vorgegeben ist, jedoch aber der / die nachfolgende Benutzer/in das identische Passwort hat.
also wenn die Sekretärin mit dem selben Typen ins Bett geht, wie ihre Chefin.
Kreuzberger
also wenn die Sekretärin mit dem selben Typen ins Bett geht, wie ihre Chefin.
Kreuzberger
1
Können Sie sich schon gleich am Anmeldefenster (Name und Passwort) nicht anmelden oder tritt die Sperre mitten drinnen auf wenn sie schon mit VPN verbunden sind bzw. vor haben sich damit zu verbinden?
Man kann ja auch den Usern einen Steich spielen und mit deren Anmeldename sich x mal falsch anmelden. Hast Du mal geschaut ob die User waehrend der Zeit des fehlerhaften Zugriffes auch schon anwesend waren?
1
Ein Grund kann auch sein (so blöd sich das anhört, aber tatsächlich so passiert): das Gerät geht in den Stromsparmodus und der Benutzer verwendet zum "Aufwecken" die Enter-Taste. Und weil die Kiste nicht gleich reagiert (Benutzer haben ja nie Zeit), wird munter weiter auf der Enter-Taste rumgeklopft. Irgendwann ist dann eben ein paar Mal zuviel mit leerem Passwort versucht worden, sich anzumelden, ergo: Konto gesperrt.
Es hat eine Weile gedauert rauszukriegen, was der Benutzer da macht...
Es hat eine Weile gedauert rauszukriegen, was der Benutzer da macht...
Moin @tom990,
ja, im Eventlog der DC's, aber erst nachdem du auf allen deinen DC's das folgende aktiviert hast. 😉
Gruss Alex
Kann ich irgendwo irgendwie auch sehen, wieso er gesperrt wurde?
ja, im Eventlog der DC's, aber erst nachdem du auf allen deinen DC's das folgende aktiviert hast. 😉
Gruss Alex
Moin,
der Hinweis von @MysticFoxDE (aka Alex) ist korrekt und gut. Meine Meinung dazu: Das sollte ein Administrator auf den Domänen Controller grundsätzlich aktivieren.
Was jetzt hilfreich ist, rauszufinden von wo aus der betroffene Benutzer alles angemeldet ist. Bzw. von wo die Sperrung verursacht wird. Ich kan mich daran erinnern, daß bei einem Unternehmen, wo ich tätig war, ein solches Tool (Werkzeug) existierte.
Weil es kam öfter mal vor, daß ein Admin sein Passwort geändert hatte. Und er eine RDP Session nur getrennt hatte, welche dann mit em alten Passwort noch aktiv war. Dadurch wurde sein administrative2 Benutzerkonto immer gesperrt.
Leider habe ich das Tool nicht. Möglicvherweise kann man die aktiven Anmeldungen /Sessions auch mittels einem PowerShell Script überprüfen. Und diese Session dann trennen / abmelden.
Gruss Penny.
der Hinweis von @MysticFoxDE (aka Alex) ist korrekt und gut. Meine Meinung dazu: Das sollte ein Administrator auf den Domänen Controller grundsätzlich aktivieren.
Was jetzt hilfreich ist, rauszufinden von wo aus der betroffene Benutzer alles angemeldet ist. Bzw. von wo die Sperrung verursacht wird. Ich kan mich daran erinnern, daß bei einem Unternehmen, wo ich tätig war, ein solches Tool (Werkzeug) existierte.
Weil es kam öfter mal vor, daß ein Admin sein Passwort geändert hatte. Und er eine RDP Session nur getrennt hatte, welche dann mit em alten Passwort noch aktiv war. Dadurch wurde sein administrative2 Benutzerkonto immer gesperrt.
Leider habe ich das Tool nicht. Möglicvherweise kann man die aktiven Anmeldungen /Sessions auch mittels einem PowerShell Script überprüfen. Und diese Session dann trennen / abmelden.
Gruss Penny.
1
Moin Penny,
👍👍👍
Zudem finde ich es für Microsoft mehr als beschämend, dass solche extrem sicherheitsrelevanten Dingen, nicht schon per Default aktiviert sind. 😔😭
Moment ... 🪄
Das obere Skript spukt sämtlich NTLM/Kerberos Fehlanmeldungen der letzten 24 Stunden aus, die auf dem entsprechenden DC aufgelaufen sind. 😁
Muss aber pro DC separat ausgeführt werden.
Vielleicht hat jemand Bock eins zu schreiben was automatisch die DC ausliest und dann bei allen die entsprechenden Logs durchforstet.
Mir fehlt momentan leider die Zeit dazu, deshalb aktuell nur die obere Sparversion. 🤪
Gruss Alex
Meine Meinung dazu: Das sollte ein Administrator auf den Domänen Controller grundsätzlich aktivieren.
👍👍👍
Zudem finde ich es für Microsoft mehr als beschämend, dass solche extrem sicherheitsrelevanten Dingen, nicht schon per Default aktiviert sind. 😔😭
Leider habe ich das Tool nicht. Möglicvherweise kann man die aktiven Anmeldungen /Sessions auch mittels einem PowerShell Script überprüfen. Und diese Session dann trennen / abmelden.
Moment ... 🪄
Get-EventLog -LogName Security -InstanceId "4625", "4771" -EntryType FailureAudit -after (get-date).AddDays(-1) | FL Das obere Skript spukt sämtlich NTLM/Kerberos Fehlanmeldungen der letzten 24 Stunden aus, die auf dem entsprechenden DC aufgelaufen sind. 😁
Muss aber pro DC separat ausgeführt werden.
Vielleicht hat jemand Bock eins zu schreiben was automatisch die DC ausliest und dann bei allen die entsprechenden Logs durchforstet.
Mir fehlt momentan leider die Zeit dazu, deshalb aktuell nur die obere Sparversion. 🤪
Gruss Alex
@MysticFoxDE,
ist doch schon mal ein Anfang. Wobei es werden nur die DCs abgefragt.
Idealerweise kann man alle Server abfragen. Und in einem Out-GridView anzeigen lassen. Oder in einer HTML Datei abspeichern. Eventuell auch als Scheduled Task.
Gruss Penny.
ist doch schon mal ein Anfang. Wobei es werden nur die DCs abgefragt.
Idealerweise kann man alle Server abfragen. Und in einem Out-GridView anzeigen lassen. Oder in einer HTML Datei abspeichern. Eventuell auch als Scheduled Task.
Gruss Penny.
1
Moin Penny,
wenn ich den TO richtig verstanden habe, dann werden seine AD-Benutzer gesperrt und in dem Fall reicht es vollkommen aus die Authentifizierungen an den DC's zu überwachen, da im Normallfall jede einen AD-Benutzer betreffende Authentifizierungsanfrage, bei dem einen oder anderen DC landen müsste.
In den entsprechenden Ereignismeldungen auf dem DC steht ausserdem meiner Ansicht nach schon alles drin was man für die nächsten Schritte benötigt, sprich die IP des Rechners von dem die Authentifizierungsanfrage gekommen ist und auch der Benutzername der zum einloggen benutzt wurde.
Ja, generell hast du schon damit recht, dass man die Fehlanmeldungen nicht nur an den DC's sondern an allen Server/Clients/FW's/SGW's & Co. überwachen sollte.
Jedoch ist das bei Windows Systemen per Default, wie du bereits bestimmt selber festgestellt hast, leider alles andere als einfach. 😔
Gruss Alex
ist doch schon mal ein Anfang. Wobei es werden nur die DCs abgefragt.
wenn ich den TO richtig verstanden habe, dann werden seine AD-Benutzer gesperrt und in dem Fall reicht es vollkommen aus die Authentifizierungen an den DC's zu überwachen, da im Normallfall jede einen AD-Benutzer betreffende Authentifizierungsanfrage, bei dem einen oder anderen DC landen müsste.
In den entsprechenden Ereignismeldungen auf dem DC steht ausserdem meiner Ansicht nach schon alles drin was man für die nächsten Schritte benötigt, sprich die IP des Rechners von dem die Authentifizierungsanfrage gekommen ist und auch der Benutzername der zum einloggen benutzt wurde.
Idealerweise kann man alle Server abfragen. Und in einem Out-GridView anzeigen lassen. Oder in einer HTML Datei abspeichern. Eventuell auch als Scheduled Task.
Ja, generell hast du schon damit recht, dass man die Fehlanmeldungen nicht nur an den DC's sondern an allen Server/Clients/FW's/SGW's & Co. überwachen sollte.
Jedoch ist das bei Windows Systemen per Default, wie du bereits bestimmt selber festgestellt hast, leider alles andere als einfach. 😔
Gruss Alex
Zitat von @MysticFoxDE:
Moin @tom990,
ja, im Eventlog der DC's, aber erst nachdem du auf allen deinen DC's das folgende aktiviert hast. 😉
Gruss Alex
Moin @tom990,
Kann ich irgendwo irgendwie auch sehen, wieso er gesperrt wurde?
ja, im Eventlog der DC's, aber erst nachdem du auf allen deinen DC's das folgende aktiviert hast. 😉
Gruss Alex
Vielen Dank Alex für diesen Hinweis. Das war tatsächlich nicht aktiviert. Jetzt aber.
Viele Grüße
Tom
1
Moin @tom990,
das ist bei keinem standardmässig aktiv, sprich, ist nicht dein Fehler sondern der von Microsoft
und zwar meiner Meinung nach ein ganz riesiger. 😔
Aber ja, ab jetzt siehst du nun ganz genau wer sich und von wo falsch und oder richtig am AD angemeldet hat. 😁
Den auch eine richtige Anmeldung, kann von der falschen Stelle aus, durchaus auch ein Problem darstellen. 😉
Gruss Alex
Vielen Dank Alex für diesen Hinweis. Das war tatsächlich nicht aktiviert. Jetzt aber.
das ist bei keinem standardmässig aktiv, sprich, ist nicht dein Fehler sondern der von Microsoft
und zwar meiner Meinung nach ein ganz riesiger. 😔
Aber ja, ab jetzt siehst du nun ganz genau wer sich und von wo falsch und oder richtig am AD angemeldet hat. 😁
Den auch eine richtige Anmeldung, kann von der falschen Stelle aus, durchaus auch ein Problem darstellen. 😉
Gruss Alex
