25
AD Passwortfalscheingaben ohne Grund oder Quelle
Hallo zusammen,
wir haben seid einer weile das Problem das einige Kollegen über die Sperrung Ihrer Konten klagen ohne erkennbaren Grund.
Das lokale AD sagt mir das die temp. Sperrung auf 10 falscheingaben des Passwortes zurückzuführen ist.
Parallel synchronisieren wir das AD noch mit dem Entra um div. Office 365 Features zu nutzen.
Hat jemand eine Idee wie ich die Quelle finden kann?
Da es mehr als 4 User unterschiedlicher Bereiche sind, würde ich Anwenderfehler durch falsche Useranmeldungen ausschließen.
wir haben seid einer weile das Problem das einige Kollegen über die Sperrung Ihrer Konten klagen ohne erkennbaren Grund.
Das lokale AD sagt mir das die temp. Sperrung auf 10 falscheingaben des Passwortes zurückzuführen ist.
Parallel synchronisieren wir das AD noch mit dem Entra um div. Office 365 Features zu nutzen.
Hat jemand eine Idee wie ich die Quelle finden kann?
Da es mehr als 4 User unterschiedlicher Bereiche sind, würde ich Anwenderfehler durch falsche Useranmeldungen ausschließen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668681
Url: https://administrator.de/contentid/668681
Ausgedruckt am: 24.11.2024 um 10:11 Uhr
25 Kommentare
Neuester Kommentar
Outlook im Browser oder auf einem Smartphone.
Schau mal, wann die das letzte Mal das Passwort geändert haben.
Schau mal, wann die das letzte Mal das Passwort geändert haben.
Moin,
Hast du mal geschaut von welchem Dienst / Computer die fehlerhaften Anmeldungen kommen?
Dann kann man dort mal in Logs etc. schauen.
Kann z.B. OWA vom Exchange sein, IMAP oder SMPTS Dienste.
Gruß
Hast du mal geschaut von welchem Dienst / Computer die fehlerhaften Anmeldungen kommen?
Dann kann man dort mal in Logs etc. schauen.
Kann z.B. OWA vom Exchange sein, IMAP oder SMPTS Dienste.
Gruß
Moin,
auf dem/den DCs im Security Log nach EventID 4625 suchen (Failed Login), da steht dann zumindest der Hostname/di IP das Gerätes das die Auth versucht hat.
lg,
Slainte
auf dem/den DCs im Security Log nach EventID 4625 suchen (Failed Login), da steht dann zumindest der Hostname/di IP das Gerätes das die Auth versucht hat.
lg,
Slainte
3
+1 für die Logs. Da wäre auch noch eine Überprüfungsmethode: Alle Clients vom User ausschalten und schauen, ob die Failed Logins immer noch steigen.
Wow, danke für die fixen Reaktioen.
EventID 4625 bringt mir leider keine Daten.
Da ist nur ein Altgerät das über falscheingaben klagt, da sitzen aber Azubis dran und daher kommt das öfter vor.
Alle anderen User die betroffen sind tauchen nicht auf.
Passwortalter habe ich alles dabei, von 4 Wochen alt bis hin zu bockalte Systemaccounts.
OWA nutzen wir hier nicht, Smartphones haben die meisten davon auch nicht.
Die Eingaben erfolgen ja nicht systematisch, eher sporadisch ... ein Kollege hatte 2 Tage Ruhe, dann kam es wieder.
Aber auch so unnatürlich ... nicht 10 mal direkt falsch sondern teilweise über einen gewissen Zeitraum daher ist es schwer das nachzustellen.
EventID 4625 bringt mir leider keine Daten.
Da ist nur ein Altgerät das über falscheingaben klagt, da sitzen aber Azubis dran und daher kommt das öfter vor.
Alle anderen User die betroffen sind tauchen nicht auf.
Passwortalter habe ich alles dabei, von 4 Wochen alt bis hin zu bockalte Systemaccounts.
OWA nutzen wir hier nicht, Smartphones haben die meisten davon auch nicht.
Die Eingaben erfolgen ja nicht systematisch, eher sporadisch ... ein Kollege hatte 2 Tage Ruhe, dann kam es wieder.
Aber auch so unnatürlich ... nicht 10 mal direkt falsch sondern teilweise über einen gewissen Zeitraum daher ist es schwer das nachzustellen.
EventID 4625 bringt mir leider keine Daten.
Wo hast du geschaut? Auf dem Domain Controller? Der schreibt sich bestimmt was rein. Auch kannst du die Events dann monitoren, dann bekommst du schnell mit, wenn es wieder kommt.
normalerweise kommt man da nur mit den iis logs per parser tools wie IASViewer weiter
+1 für die Logs
Ansonsten: Sind die Logindaten irgendwo hinterlegt? Gerade heute morgen den Fall noch gehabt... User war auch als E-Mail Nutzer in einer Fachsoftware hinterlegt... Benutzer hat neues Passwort, aber natürlich nicht in der Fachsoftware geändert. (ich bin ja eh für Service-User für solche Dinge, aber naja...). Jedes mal wenn versucht wurde eine Mail zu versenden, war das natürlich ein falscher Anmeldeversuch.
Ansonsten: Sind die Logindaten irgendwo hinterlegt? Gerade heute morgen den Fall noch gehabt... User war auch als E-Mail Nutzer in einer Fachsoftware hinterlegt... Benutzer hat neues Passwort, aber natürlich nicht in der Fachsoftware geändert. (ich bin ja eh für Service-User für solche Dinge, aber naja...). Jedes mal wenn versucht wurde eine Mail zu versenden, war das natürlich ein falscher Anmeldeversuch.
Ich hatte das auch schon dreimal mit unterschiedlichen Usern. Ich hab nie herausgefunden, was tatsächlich der Grund war. Das ist wie die Nadel im Heuhaufen. Man kann entsprechende Überwachung aktivieren um dann die Event IDs (4624, 4625, 4740,4776) auszulesen. Ich wusste dann, von welchem Gerät die Anmeldeversuche stammten, aber auch nicht mehr. Meine einzige Lösung war es, den betroffenen User zu deaktivieren und einen neuen anzulegen.
Wenn du die Überwachung aktiviert hast, dann erstelle dir im Ereignisprotokoll des DC benutzerdefinierte Ansichten welche die entsprechenden EventIDs filtern. Für jede ID eine Ansicht. Dann hat man das auch gleich mit einem Klick.
Schau Dir mal z.B. diese Anleitung an:
www.windows-active-directory.com/account-lockout-event-id-how-to-find-account-lockouts.html
Wenn du die Überwachung aktiviert hast, dann erstelle dir im Ereignisprotokoll des DC benutzerdefinierte Ansichten welche die entsprechenden EventIDs filtern. Für jede ID eine Ansicht. Dann hat man das auch gleich mit einem Klick.
Schau Dir mal z.B. diese Anleitung an:
www.windows-active-directory.com/account-lockout-event-id-how-to-find-account-lockouts.html
1
Ein ganz nützliches Tool ist auch z.B. EventCombMT aus dem 2003er Ressource Kit:
www.msxfaq.de/tools/mswin/eventcombmt.htm
bzw LockoutStatus
learn.microsoft.com/de-de/troubleshoot/windows-server/windows-security/account-lockout-and-management-tool
www.msxfaq.de/tools/mswin/eventcombmt.htm
bzw LockoutStatus
learn.microsoft.com/de-de/troubleshoot/windows-server/windows-security/account-lockout-and-management-tool
1
Moin,
habt Ihr Terminalserver im Einsatz? Ich kenne das Phänomen, wenn eine terminalsession nur getrennt wird, statt ordnungsgemäß abzumelden. Wenn dann eine person Ihr Passwort ändern, wird dieses von der noch aktiven Session wieder auf das vorhergehende Passwort geändert.
Gruss Penny.
habt Ihr Terminalserver im Einsatz? Ich kenne das Phänomen, wenn eine terminalsession nur getrennt wird, statt ordnungsgemäß abzumelden. Wenn dann eine person Ihr Passwort ändern, wird dieses von der noch aktiven Session wieder auf das vorhergehende Passwort geändert.
Gruss Penny.
Wir haben für solche Fälle SolarWinds Server & Application Monitor installiert, funktioniert auch ganz gut und man bekommt grafisch zusammengefasst die Anmeldungen angezeigt.
Kannst ja mal eine Proberversion installieren wenn du es nicht zu Fuß machen möchtest.
Kannst ja mal eine Proberversion installieren wenn du es nicht zu Fuß machen möchtest.
Moin
Weil es eben doch zu 99,9% an irgendeinem Login auf irgendeinem Gerät und einem geänderten Kennwort liegt: Du änderst einfach den Kontonamen des betroffenen Benutzerkontos und schon ist normalerweise Ruhe.
Gruß
Weil es eben doch zu 99,9% an irgendeinem Login auf irgendeinem Gerät und einem geänderten Kennwort liegt: Du änderst einfach den Kontonamen des betroffenen Benutzerkontos und schon ist normalerweise Ruhe.
Gruß
Moin,
habt ihr einen RADIUS-Server im Einsatz, wo sich die Kollegen mit Benutzername/Passwort anmelden (z. B. WLAN fürs Handy/Tablet)? So kann auch ein Mobilteil den Account für den Rechner sperren.
Gruß
TA
habt ihr einen RADIUS-Server im Einsatz, wo sich die Kollegen mit Benutzername/Passwort anmelden (z. B. WLAN fürs Handy/Tablet)? So kann auch ein Mobilteil den Account für den Rechner sperren.
Gruß
TA
Moin,
kannst auch mal im Entra Sign-in Log nachschauen ob es vom O365 kommt.
Parallel synchronisieren wir das AD noch mit dem Entra um div. Office 365 Features zu nutzen.
kannst auch mal im Entra Sign-in Log nachschauen ob es vom O365 kommt.
Zitat von @beck2oldschool:
Ich hatte das auch schon dreimal mit unterschiedlichen Usern. Ich hab nie herausgefunden, was tatsächlich der Grund war. Das ist wie die Nadel im Heuhaufen. Man kann entsprechende Überwachung aktivieren um dann die Event IDs (4624, 4625, 4740,4776) auszulesen. Ich wusste dann, von welchem Gerät die Anmeldeversuche stammten, aber auch nicht mehr. Meine einzige Lösung war es, den betroffenen User zu deaktivieren und einen neuen anzulegen.
Wenn du die Überwachung aktiviert hast, dann erstelle dir im Ereignisprotokoll des DC benutzerdefinierte Ansichten welche die entsprechenden EventIDs filtern. Für jede ID eine Ansicht. Dann hat man das auch gleich mit einem Klick.
Schau Dir mal z.B. diese Anleitung an:
www.windows-active-directory.com/account-lockout-event-id-how-to-find-account-lockouts.html
Ich hatte das auch schon dreimal mit unterschiedlichen Usern. Ich hab nie herausgefunden, was tatsächlich der Grund war. Das ist wie die Nadel im Heuhaufen. Man kann entsprechende Überwachung aktivieren um dann die Event IDs (4624, 4625, 4740,4776) auszulesen. Ich wusste dann, von welchem Gerät die Anmeldeversuche stammten, aber auch nicht mehr. Meine einzige Lösung war es, den betroffenen User zu deaktivieren und einen neuen anzulegen.
Wenn du die Überwachung aktiviert hast, dann erstelle dir im Ereignisprotokoll des DC benutzerdefinierte Ansichten welche die entsprechenden EventIDs filtern. Für jede ID eine Ansicht. Dann hat man das auch gleich mit einem Klick.
Schau Dir mal z.B. diese Anleitung an:
www.windows-active-directory.com/account-lockout-event-id-how-to-find-account-lockouts.html
Also für andere >> die Logs können bei verschiedenen DCs liegen also muss man alle Eventlogs aller DCs checken, das nur vorab.
So wenn man weiss welche maschine das sperrt kann das verschiedene Ursachen haben:
1. User ist dort noch angemeldet, zwischenzeitlich hat er das PW an seinem Haupt PC geändert und der alte gesperrte PC sperrt dann den account. Lösung neu starten des verursachenden PCs.
2. User hat an dem PC der den Account loggt irgend nen Müll eingestellt.
z.B. Sceduled Task mit Login und PW hinterlegt der dann immer mal läuft und dann account sperrt.
Entsprechend dort halt PW ändern
3. User hat admin rechte und hat irgend was installiert und unter DIENSTE einen Dienst am laufen mit seinen Credentials.... die nach einem PW change natürlich falsch sind...
Oder scripts die Login und PW hinterlegt haben oder oder oder....
Meisst tritt das problem auf wenn user ihr PW gechanged haben....
wenn man aber schon mal den verursachenden PCs ausm Eventlog identifizieren kann dann sollte man auch das problem finden können.
Dann auch unter systemsteuerung dann Anmeldeinformations Verwaltung da alle Anmelde Informationen rauslöschen, da kann auch mal was falsches drin gespeichert worden sein.
Oder Webseiten Intranet mit Login und PW des Domain User gespeichert und falsch.... etc....
auch beliebt handy mit EMail verbunden über aktive sync, also domain login + pw im handy gespeichert...
So denke genug Ideen hier geschrieben
Stimmt der Zeitpunkt des Auftauchens des Fehlers überein mit dem Datum der letzten Passwort Änderung des Anwenders? Wenn ja, war es vorher ein gültiges Passwort und ein Indiz, dass es irgendwo noch gespeichert ist.
Das kann man ja im AD ganz einfach anschauen.
Das kann man ja im AD ganz einfach anschauen.
Zitat von @ThePinky777:
Also für andere >> die Logs können bei verschiedenen DCs liegen also muss man alle Eventlogs aller DCs checken, das nur vorab.
Selbstverständlich. Vollkommen richtig. Kommt halt drauf an welcher DC der aktuelle %logonserver% des Users ist. Logischerweise müssen dann auch alle DC überprüft werden. Und genau das geht mit EventCombMT ganz gutAlso für andere >> die Logs können bei verschiedenen DCs liegen also muss man alle Eventlogs aller DCs checken, das nur vorab.
Moin @Akrosh,
als erstes solltest du ganz genau die Anleitung die @beck2oldschool unter ...
AD Passwortfalscheingaben ohne Grund oder Quelle
... gepostet hat durchgehen, insbesondere den folgenden Punkt ...
..., denn per Default werden die entsprechenden Events nicht erfasst!
Wenn du auf deinen internen DC nach erfolgreicher Aktivierung der Protokollierung immer noch keine fehlerhaften Anmeldungen siehst, dann kommen die Fehlanmeldungen nicht von innen sondern von aussen, sprich über eure M365 Konten.
In diesem Fall solltest du die Sicherheitseinstellungen eures Azure-AD's/Entra kontrollieren und z.B. sicherstellen, dass Authentifizierungen nur aus bestimmten Ländern, oder am besten nur von bestimmten IP's möglich sind.
https://learn.microsoft.com/de-de/azure/security/fundamentals/steps-secu ...
😉
Zu dem Thema Härtung eines Microsoft Tenants, kann ich jedoch nicht wirklich viel mit praktischer Erfahrung beitragen, da wir fast ausschliesslich auf On-Premise, sprich nur Private-Clud spezialisiert sind und das auch bleiben.
Gruss Alex
Hat jemand eine Idee wie ich die Quelle finden kann?
als erstes solltest du ganz genau die Anleitung die @beck2oldschool unter ...
AD Passwortfalscheingaben ohne Grund oder Quelle
... gepostet hat durchgehen, insbesondere den folgenden Punkt ...
..., denn per Default werden die entsprechenden Events nicht erfasst!
Wenn du auf deinen internen DC nach erfolgreicher Aktivierung der Protokollierung immer noch keine fehlerhaften Anmeldungen siehst, dann kommen die Fehlanmeldungen nicht von innen sondern von aussen, sprich über eure M365 Konten.
In diesem Fall solltest du die Sicherheitseinstellungen eures Azure-AD's/Entra kontrollieren und z.B. sicherstellen, dass Authentifizierungen nur aus bestimmten Ländern, oder am besten nur von bestimmten IP's möglich sind.
https://learn.microsoft.com/de-de/azure/security/fundamentals/steps-secu ...
😉
Zu dem Thema Härtung eines Microsoft Tenants, kann ich jedoch nicht wirklich viel mit praktischer Erfahrung beitragen, da wir fast ausschliesslich auf On-Premise, sprich nur Private-Clud spezialisiert sind und das auch bleiben.
Gruss Alex
Hallo zusammen,
danke für die vielen Infos!
Nach einigen Stunden des Log lesens habe ich nun unseren On-Premise Exchange als Quelle gefunden und das jemand von außerhalb des europäischen Raumes versucht hat sich per SMTP mit div. bekannten Mail-Adressen zu verbinden.
Nun haben wir den Zaun um Datenverkehr auf den europäischen Raum beschränkt und derzeit sieht es gut aus.
Mir war leider nicht bekannt das nur der angesprochene DC die richtigen Logs anzeigt, ich war immer der Meinung das beide identisch loggen.
danke für die vielen Infos!
Nach einigen Stunden des Log lesens habe ich nun unseren On-Premise Exchange als Quelle gefunden und das jemand von außerhalb des europäischen Raumes versucht hat sich per SMTP mit div. bekannten Mail-Adressen zu verbinden.
Nun haben wir den Zaun um Datenverkehr auf den europäischen Raum beschränkt und derzeit sieht es gut aus.
Mir war leider nicht bekannt das nur der angesprochene DC die richtigen Logs anzeigt, ich war immer der Meinung das beide identisch loggen.
Moin,
etwas Off-Topic, aber warum hängt euer OnPrem Exchange für alle erreichbar mit SMTP in Internet wenn ihr doch M365 verwendet? Hier würde ich die Konnektivität auf die Microsoft Exchange Online Adressen beschränken. IP-Einschränkungen auf "Länder" machen in Zeiten von Residential Proxies kaum noch sinn.
lg,
Slainte
etwas Off-Topic, aber warum hängt euer OnPrem Exchange für alle erreichbar mit SMTP in Internet wenn ihr doch M365 verwendet? Hier würde ich die Konnektivität auf die Microsoft Exchange Online Adressen beschränken. IP-Einschränkungen auf "Länder" machen in Zeiten von Residential Proxies kaum noch sinn.
lg,
Slainte
2
Moin @Akrosh,
OK, abgesehen von dem was @SlainteMhath schon geschrieben hat, hätte ich dann noch zwei Fragen.
Warum zur Hölle, hängt der SMTP-Empfangs-Connector eures Exchange Servers direkt im Internet?
Hier sollte unbedingt noch ein SMTP-Security-Gateway dazwischen hängen!
Und warum akzeptiert euer im Internet hängender SMTP-Empfangs-Connector überhaupt Domain-Authentifizierung?
Das ist für einen Mailempfang aus dem Internet überhaupt nicht notwendig.
Upps, verflixt, das wollte ich noch dazuschreiben, dass du die Logs auf allen deinen DC's im Auge behalten musst, da jeder DC für sich Protokoliert und jeder Client, sich theoretisch gegen jeden DC Authentifizieren kann.
Na ja, jetzt ist es schon rum. 🙃
Gruss Alex
Nach einigen Stunden des Log lesens habe ich nun unseren On-Premise Exchange als Quelle gefunden und das jemand von außerhalb des europäischen Raumes versucht hat sich per SMTP mit div. bekannten Mail-Adressen zu verbinden.
OK, abgesehen von dem was @SlainteMhath schon geschrieben hat, hätte ich dann noch zwei Fragen.
Warum zur Hölle, hängt der SMTP-Empfangs-Connector eures Exchange Servers direkt im Internet?
Hier sollte unbedingt noch ein SMTP-Security-Gateway dazwischen hängen!
Und warum akzeptiert euer im Internet hängender SMTP-Empfangs-Connector überhaupt Domain-Authentifizierung?
Das ist für einen Mailempfang aus dem Internet überhaupt nicht notwendig.
Mir war leider nicht bekannt das nur der angesprochene DC die richtigen Logs anzeigt, ich war immer der Meinung das beide identisch loggen.
Upps, verflixt, das wollte ich noch dazuschreiben, dass du die Logs auf allen deinen DC's im Auge behalten musst, da jeder DC für sich Protokoliert und jeder Client, sich theoretisch gegen jeden DC Authentifizieren kann.
Na ja, jetzt ist es schon rum. 🙃
Gruss Alex
1
also ich tippe ja drauf er hat SMTP geschrieben meint aber vermutlich OWA Seite des Exchange
Altbekanntes Problem >> bedeutet kommt immer mal vor.
Das abzudichten ist aber ein Extra Thema für sich...
Altbekanntes Problem >> bedeutet kommt immer mal vor.
Das abzudichten ist aber ein Extra Thema für sich...
Mir fiele noch eine 4 Variante ein. Der User hat unter seinen "Windows-Anmeldeinformationen" Passwörter gespeichert. Gerne auch auch mal verwendet bei Mappings, von Netzlaufwerken.
Und das ist Dir ganz alleine eingefallen? Ohne weiter oben abzuschreiben?
2
