13
Permanente Sperrung eines Adminkontos
Hallo Leute,
wir haben seit mehreren Monaten das Problem bei einem Admin-User, dass dieser mehrmals täglich in der AD gesperrt wird. Regelmäßig heißt so 3-4 mal am Tag (morgens bei Arbeitsbeginn, um 11 Uhr und nachmittags noch 2 - 3 mal). Wir haben auch bereits über das Rechenzentrum die Info erhalten, von welchem Win2k3-Server die Sperrung ausgeht. Auf diesem betreffenden Server laufen neben 2-3 Webservern (Tomcat, IIS) mit diversen Webanwendungen auch ein SQL-Express Server. Wir haben auch bereits getestet, wie es sich äußert, wenn der SQL-Server für nen halben Tag gestoppt ist. Dann kommt es zu ca. einer Sperrung am Nachmittag.
Ich persönlich vermute, dass in irgendeiner Webanwendung (in Verbindung mit dem SQL-Server) der User zum Test eingetragen wurde mit einem damals gültigen Kennwort. Wir haben auch bereits den Windowsuser gelöscht und neu angelegt, damit er eine neue SID erhält. Daher muss es irgendwo ein Klartextuser auf dem Server sein. Aber das Durchsuchen nach Klartext hat keinen Erfolg gebracht. Wir sind auch bereits mit den Softwareherstellern in Kontakt gewesen und die Anwendungen durch gegangen - aber nichts zu finden
Die Quelle der Sperrung ist aber definitiv von diesem Server aus.
Hat von Euch noch jemand ne Idee, wie wir der Userkennung auf die Schliche kommen können oder mit ner Protokollierung auf dem Server zu potte kommen? Die Lösung eine neue Adminkennung zu erstellen gefällt mir nicht
Viele Grüße
Sascha
wir haben seit mehreren Monaten das Problem bei einem Admin-User, dass dieser mehrmals täglich in der AD gesperrt wird. Regelmäßig heißt so 3-4 mal am Tag (morgens bei Arbeitsbeginn, um 11 Uhr und nachmittags noch 2 - 3 mal). Wir haben auch bereits über das Rechenzentrum die Info erhalten, von welchem Win2k3-Server die Sperrung ausgeht. Auf diesem betreffenden Server laufen neben 2-3 Webservern (Tomcat, IIS) mit diversen Webanwendungen auch ein SQL-Express Server. Wir haben auch bereits getestet, wie es sich äußert, wenn der SQL-Server für nen halben Tag gestoppt ist. Dann kommt es zu ca. einer Sperrung am Nachmittag.
Ich persönlich vermute, dass in irgendeiner Webanwendung (in Verbindung mit dem SQL-Server) der User zum Test eingetragen wurde mit einem damals gültigen Kennwort. Wir haben auch bereits den Windowsuser gelöscht und neu angelegt, damit er eine neue SID erhält. Daher muss es irgendwo ein Klartextuser auf dem Server sein. Aber das Durchsuchen nach Klartext hat keinen Erfolg gebracht. Wir sind auch bereits mit den Softwareherstellern in Kontakt gewesen und die Anwendungen durch gegangen - aber nichts zu finden
Die Quelle der Sperrung ist aber definitiv von diesem Server aus.Hat von Euch noch jemand ne Idee, wie wir der Userkennung auf die Schliche kommen können oder mit ner Protokollierung auf dem Server zu potte kommen? Die Lösung eine neue Adminkennung zu erstellen gefällt mir nicht
Viele Grüße
Sascha
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: 205490
Url: https://administrator.de/forum/permanente-sperrung-eines-adminkontos-205490.html
Ausgedruckt am: 23.12.2024 um 12:12 Uhr
13 Kommentare
Neuester Kommentar
Hey,
du kannst doch sicherlich die fehlgeschlagenen Anmeldeversuche in den Eventlogs nachgucken, evtl. kommst du darüber weiter.
Gruß XenClient
du kannst doch sicherlich die fehlgeschlagenen Anmeldeversuche in den Eventlogs nachgucken, evtl. kommst du darüber weiter.
Gruß XenClient
Hi,
im Log des betreffenden Servers selbst finde ich nichts davon. Das Rechenzentrum hat uns aber ein Protokoll zugeschickt, dass aufzeigt, dass die Sperrungen von diesem Server ausgehen und wann genau die Anmeldeversuche geschahen. Darüber hinaus können Sie uns aber keine Infos geben. Nur diese Fakten, die mich aber leider so nicht weiter bringen. Ich gehe davon aus, dass die Authentifizierung nicht für den Server selbst bestimmt ist, daher ist natürlich auf dem Server , von dem die Anfrage kommt auch keine fehlerhafte Anmeldung im Protokoll.
Gruß
Sascha
im Log des betreffenden Servers selbst finde ich nichts davon. Das Rechenzentrum hat uns aber ein Protokoll zugeschickt, dass aufzeigt, dass die Sperrungen von diesem Server ausgehen und wann genau die Anmeldeversuche geschahen. Darüber hinaus können Sie uns aber keine Infos geben. Nur diese Fakten, die mich aber leider so nicht weiter bringen. Ich gehe davon aus, dass die Authentifizierung nicht für den Server selbst bestimmt ist, daher ist natürlich auf dem Server , von dem die Anfrage kommt auch keine fehlerhafte Anmeldung im Protokoll.
Gruß
Sascha
Hi,
weiß nicht warum du eine neue Kennung ablehnst. Würde den entsprechenden Benutzer deaktivieren (nicht löschen) und einen neuen anlegen.
Vielleicht sieht man durch die Deaktivierung, was dann nicht mehr funktioniert - und schaut da bei den Scripten nach. Und wenn`s nicht trivial ist kann man den Benutzer schnell wieder aktivieren.
Ansonsten mal sämtliche Logs duschschauen, irgendwo müsste ja ein "Anmeldung fehlgeschlagen" auftauchen. Aber welche Log - musst mal suchen
greetz
Ravers
weiß nicht warum du eine neue Kennung ablehnst. Würde den entsprechenden Benutzer deaktivieren (nicht löschen) und einen neuen anlegen.
Vielleicht sieht man durch die Deaktivierung, was dann nicht mehr funktioniert - und schaut da bei den Scripten nach. Und wenn`s nicht trivial ist kann man den Benutzer schnell wieder aktivieren.
Ansonsten mal sämtliche Logs duschschauen, irgendwo müsste ja ein "Anmeldung fehlgeschlagen" auftauchen. Aber welche Log - musst mal suchen
greetz
Ravers
Hi Ravers,
es funktioniert ja alles seit Monaten. Der betroffene User wird automatisiert immer mit dem falschen Passwort angemeldet und nach X-Versuchen gesperrt. Dadurch, dass der Admin ja selbst mit dem Benutzer gleichzeitig arbeitet, hebt er die Sperrungen durch Authentifizierungen, die korrekt sind wieder auf. Aber irgendwann kommts dann halt mal zu aufeinanderfolgende Fehlanmeldungen durch den Automatismus.
Problem ist, dass wir nicht alles im Zugriff haben, da einige Systeme vom Rechenzentrum verwaltet werden und wir dort nur gesagt bekommen, dass es die Authentifizierung von diesem Server aus geht.
Gruß
Sascha
es funktioniert ja alles seit Monaten. Der betroffene User wird automatisiert immer mit dem falschen Passwort angemeldet und nach X-Versuchen gesperrt. Dadurch, dass der Admin ja selbst mit dem Benutzer gleichzeitig arbeitet, hebt er die Sperrungen durch Authentifizierungen, die korrekt sind wieder auf. Aber irgendwann kommts dann halt mal zu aufeinanderfolgende Fehlanmeldungen durch den Automatismus.
Problem ist, dass wir nicht alles im Zugriff haben, da einige Systeme vom Rechenzentrum verwaltet werden und wir dort nur gesagt bekommen, dass es die Authentifizierung von diesem Server aus geht.
Gruß
Sascha
Hi,
dann sollen die das im Rechenzentrum ändern. Kannst den Fall ja schildern. Wenn die dann keine bessere Idee haben (und das werden Sie vermutlich nicht), werden die es schon ohne murren ändern.
Denn permanentes Entsperren bringt auch nix, wie soll man dann bei einem richtigen "Einbruchsversuch" das lokalisieren??
Und "das alles seit Monaten läuft" - stimmt, bei mir auch - warum geh ich eigentlich noch zur Arbeit ??
Ansonsten mal mit Wireshark o.ä. den Server überwachen, und schauen, wo der Benutzername dann wieder auftaucht. Dann Zeit und die Serverjobs vergleichen - und hoffen, das man so weiterkommt.
Den Satz - "haben den SQL-Server einen halben Tag" ... "nachmittags einmal gesperrt" - was soll uns das sagen?
Habt ihr vormittags den Server gestoppt oder Nachmittags? - Sprich liegt es nun am SQL-Server??
greetz
Ravers
dann sollen die das im Rechenzentrum ändern. Kannst den Fall ja schildern. Wenn die dann keine bessere Idee haben (und das werden Sie vermutlich nicht), werden die es schon ohne murren ändern.
Denn permanentes Entsperren bringt auch nix, wie soll man dann bei einem richtigen "Einbruchsversuch" das lokalisieren??
Und "das alles seit Monaten läuft" - stimmt, bei mir auch - warum geh ich eigentlich noch zur Arbeit ??
Ansonsten mal mit Wireshark o.ä. den Server überwachen, und schauen, wo der Benutzername dann wieder auftaucht. Dann Zeit und die Serverjobs vergleichen - und hoffen, das man so weiterkommt.
Den Satz - "haben den SQL-Server einen halben Tag" ... "nachmittags einmal gesperrt" - was soll uns das sagen?
Habt ihr vormittags den Server gestoppt oder Nachmittags? - Sprich liegt es nun am SQL-Server??
greetz
Ravers
Hi Ravers,
den SQL hatten wir nachmittags mal stillgelegt mit dem Resultat, dass der betreffende User dann statt 3x nur 1x gesperrt war an diesem Nachmittag.
Die Frage ist, ob es ein Tool gibt, mit dem wir ausgehende Windows-Authentifizierungsanfragen von diesem Server aus loggen können und von welcher Anwendung diese Anfrage ausgeht.
Gruß
Sascha
den SQL hatten wir nachmittags mal stillgelegt mit dem Resultat, dass der betreffende User dann statt 3x nur 1x gesperrt war an diesem Nachmittag.
Die Frage ist, ob es ein Tool gibt, mit dem wir ausgehende Windows-Authentifizierungsanfragen von diesem Server aus loggen können und von welcher Anwendung diese Anfrage ausgeht.
Gruß
Sascha
Moin.
Die Frage ist ein Evergreen. Checke die üblichen Verdächtigen:
-gespeicherte Netzwerkcredentials -> http://windows.microsoft.com/en-id/windows7/remove-stored-passwords-cer ... ggf. entfernen
-geplante Tasks und ebenso benutzerdefinierte Dienste prüfen: ist dort evtl. dieser Nutzer samt Kennwort eingetragen?
Die Frage ist ein Evergreen. Checke die üblichen Verdächtigen:
-gespeicherte Netzwerkcredentials -> http://windows.microsoft.com/en-id/windows7/remove-stored-passwords-cer ... ggf. entfernen
-geplante Tasks und ebenso benutzerdefinierte Dienste prüfen: ist dort evtl. dieser Nutzer samt Kennwort eingetragen?
Hi,
es handelt sich um einen Win2k3-Server, von dem aus die Authenzifizierungen ausgehen. Daher, dass wir den User gelöscht und neu angelegt haben hat er auch eine neue SID bekommen, daher muss es eine Userangabe im Klartext irgendwo in einer Anwendung auf dem Server sein.
Gruß
Sascha
es handelt sich um einen Win2k3-Server, von dem aus die Authenzifizierungen ausgehen. Daher, dass wir den User gelöscht und neu angelegt haben hat er auch eine neue SID bekommen, daher muss es eine Userangabe im Klartext irgendwo in einer Anwendung auf dem Server sein.
Gruß
Sascha
Soso. Und meinen Beitrag hast Du gelesen und umgesetzt?
Klaro. Bei "Gespicherte Benutzernamen..." steht auch nichts drin. Die Tasks und Dienste hatte ich bereits als das Problem aufgetaucht ist durchgesehen, es ist aber leider nichts zu finden.
Gespeicherte Benutzernamen ist keine systemweite Liste, sondern benutzergebunden. Du musst sie für alle Benutzer, die sich am Server lokal oder per RDP anmelden können durchsehen.
Hi DerWoWusste,
also um ehrlich zu sein denke ich nicht, dass dies in unserem Fall ein Lösungsansatz ist. Da es sich um einen Server handelt und wir diesen administrieren, wird hier mit Sicherheit keiner einen derartigen Eintrag drin haben. Zudem ist durch eine Policy die Nutzung dieser Anmeldeverwaltung unterbunden. Ich würde Dir vielleicht recht geben, wenn ein Benutzer permanent am System angemeldet ist, aber auf einem Server ist das, wie auch in unserem Szenario, normalerweise nicht der Fall.
Gruß
Sascha
also um ehrlich zu sein denke ich nicht, dass dies in unserem Fall ein Lösungsansatz ist. Da es sich um einen Server handelt und wir diesen administrieren, wird hier mit Sicherheit keiner einen derartigen Eintrag drin haben. Zudem ist durch eine Policy die Nutzung dieser Anmeldeverwaltung unterbunden. Ich würde Dir vielleicht recht geben, wenn ein Benutzer permanent am System angemeldet ist, aber auf einem Server ist das, wie auch in unserem Szenario, normalerweise nicht der Fall.
Gruß
Sascha
Dann musst Du wohl oder übel mit procmon auf dem Server mitloggen (enable advanced output), was zum Zeitpunkt der Sperrung passiert.
