16
Windows Domänen User werden immer wieder gesperrt
Hallo zusammen,
derzeit hält mich folgendes Thema auf:
Ich administriere eine Domäne (Windows Server 2012 R2) mit ca. 70 Usern und ca. 100 Clients. vor kurzem (ca. 2 Wochen) haben wir die Passwortrichtlinien angepasst. Die MA müssen nun 10 Zeichen als Passwort haben und der Komplexitätsrichtline entsprechen. Des Weiteren wurde festgelegt, dass nach 10 gescheiterten Anmeldeversuchen der User gesperrt wird. Als nach der Ankündigung die User ihre Passwörter geändert hatten, habe ich in den GPOs die entsprechende Anpassung vorgenommen. Als nun ein paar Stunden vergingen klingelten bei uns die Telefone... der Domänenserver sperrte die User, die 100% ihre Passwörter richtig eingeben haben.
Häufig die gleichen Personen. Die User werden erst nicht mehr gesperrt, wenn ich bei den jeweiligen Usern im AD sage: Kerberos Pre-Authentication deaktivieren.
Kurz und knapp meine bisherigen Lösungsversuche:
-Windows Server Update
-Kerberos Update Patch
-Sämtliche von mir hierzu gesetzten oder geänderten GPOs gelöscht
Ich hoffe ihr könnt mir in diesem Fall helfen.
Grüße
Marco
derzeit hält mich folgendes Thema auf:
Ich administriere eine Domäne (Windows Server 2012 R2) mit ca. 70 Usern und ca. 100 Clients. vor kurzem (ca. 2 Wochen) haben wir die Passwortrichtlinien angepasst. Die MA müssen nun 10 Zeichen als Passwort haben und der Komplexitätsrichtline entsprechen. Des Weiteren wurde festgelegt, dass nach 10 gescheiterten Anmeldeversuchen der User gesperrt wird. Als nach der Ankündigung die User ihre Passwörter geändert hatten, habe ich in den GPOs die entsprechende Anpassung vorgenommen. Als nun ein paar Stunden vergingen klingelten bei uns die Telefone... der Domänenserver sperrte die User, die 100% ihre Passwörter richtig eingeben haben.
Häufig die gleichen Personen. Die User werden erst nicht mehr gesperrt, wenn ich bei den jeweiligen Usern im AD sage: Kerberos Pre-Authentication deaktivieren.
Kurz und knapp meine bisherigen Lösungsversuche:
-Windows Server Update
-Kerberos Update Patch
-Sämtliche von mir hierzu gesetzten oder geänderten GPOs gelöscht
Ich hoffe ihr könnt mir in diesem Fall helfen.
Grüße
Marco
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: 649627
Url: https://administrator.de/contentid/649627
Ausgedruckt am: 25.11.2024 um 02:11 Uhr
16 Kommentare
Neuester Kommentar
Die MA müssen das in ihren Handies auch umstellen. Sonst 10x Login mit alten Creds. Darum wird gesperrt.
Henere
Henere
Haben wir auch gedacht.
Aber es sind auch User betroffen die keine Handys nutzen.
Aber es sind auch User betroffen die keine Handys nutzen.
Gibt es auch noch paar mehr Informationen ?
Es wird ein Exchangeserver genutzt und die UC Server Software Estos ProCall mit der Outlook Schnittstelle welche auch sehr oft das Passwort anfragt.
Es ist zum Beispiel ein Meister aus der Metallwerkstatt betroffen, der nutzt seinen PC zwei mal am Tag nur für emails (Outlook) und procall. Mehr Programme nutzt er nicht.
Es ist zum Beispiel ein Meister aus der Metallwerkstatt betroffen, der nutzt seinen PC zwei mal am Tag nur für emails (Outlook) und procall. Mehr Programme nutzt er nicht.
Zitat von @mko1502:
Es wird ein Exchangeserver genutzt und die UC Server Software Estos ProCall mit der Outlook Schnittstelle welche auch sehr oft das Passwort anfragt.
Es ist zum Beispiel ein Meister aus der Metallwerkstatt betroffen, der nutzt seinen PC zwei mal am Tag nur für emails (Outlook) und procall. Mehr Programme nutzt er nicht.
Es wird ein Exchangeserver genutzt und die UC Server Software Estos ProCall mit der Outlook Schnittstelle welche auch sehr oft das Passwort anfragt.
Es ist zum Beispiel ein Meister aus der Metallwerkstatt betroffen, der nutzt seinen PC zwei mal am Tag nur für emails (Outlook) und procall. Mehr Programme nutzt er nicht.
Ich werde jetzt nichts mehr sagen ! Weil eine Firma die dranne hängt, die sollte den IT Dienstleister Verklagen wenn nichts geht, und jeder wirklich, wohl jeder, der meint ein Administrator zu sein !
Maulkorb auf und Tschüss
Danke für dein konstruktives Feedback.
Vllt.liegen im Anmeldetresor noch alte bzw. ungültige Credentials, ansonsten hätte ich mal auf activesync bzw. Smartphone getippt
Moin Marco,
bei sowas empfiehlt es sich in die Ereignisanzeige des Domain Controllers zu schauen, welcher die Rolle PDC Emulator hält. Relevant ist das Protokoll Sicherheit. Da hier sehr viel protokolliert wird, empfiehlt es sich die Option "Archiv" zu aktivieren. Damit ist die Chance groß, dass du die relevante Einträge findest. Wichtig ist natürlich auch, dass die betroffenen Personen Datum und Uhrzeit nennen können. Damit du schneller fündig wirst.
Im dem entsprechenden Eintrag stehen weitere Informationen (z.B. Rechnername, IP-Adresse, etc...). Damit sind evtl. schon Rückschlüsse des möglichen Auslösers möglich. Wichtig ist, dass der Nutzer keine Zugangsdaten im Tresor bzw. Anmeldeinformationsverwaltun abgelegt hat. Wenn dort Einträge vorhanden sind, löschen. Sicher ist sicher.
Anwendungen welche SSO/Kerberos zurückgreifen, können eigentlich nicht der Auslöser sein. Habt ihr evtl. Anwendungen im Einsatz, an denen sich der Nutzer mit seinem Benutzername und Passwort aktiv anmelden kann/muss?!
Gruß,
Dani
bei sowas empfiehlt es sich in die Ereignisanzeige des Domain Controllers zu schauen, welcher die Rolle PDC Emulator hält. Relevant ist das Protokoll Sicherheit. Da hier sehr viel protokolliert wird, empfiehlt es sich die Option "Archiv" zu aktivieren. Damit ist die Chance groß, dass du die relevante Einträge findest. Wichtig ist natürlich auch, dass die betroffenen Personen Datum und Uhrzeit nennen können. Damit du schneller fündig wirst.
Im dem entsprechenden Eintrag stehen weitere Informationen (z.B. Rechnername, IP-Adresse, etc...). Damit sind evtl. schon Rückschlüsse des möglichen Auslösers möglich. Wichtig ist, dass der Nutzer keine Zugangsdaten im Tresor bzw. Anmeldeinformationsverwaltun abgelegt hat. Wenn dort Einträge vorhanden sind, löschen. Sicher ist sicher.
Anwendungen welche SSO/Kerberos zurückgreifen, können eigentlich nicht der Auslöser sein. Habt ihr evtl. Anwendungen im Einsatz, an denen sich der Nutzer mit seinem Benutzername und Passwort aktiv anmelden kann/muss?!
Gruß,
Dani
2
Moin Dani!
Danke für deinen Hinweis, Anmeldeinformationsverwaltung und Tresor sind leer.
Ich habe auch bereits das lockedout tool von Mircosoft hierfür verwendet und den Entsprechenden Eintrag gefunden.
Dort steht immer Event ID: 4740...
Mittlerweile hat mir ein Kollege auch mitgeteilt dass es wohl keine Geige mehr spielt ob Kerberos an oder aus ist.
Trotzdem lockedout
Hast du da noch ne Idee?
Grüße
Marco
Danke für deinen Hinweis, Anmeldeinformationsverwaltung und Tresor sind leer.
Ich habe auch bereits das lockedout tool von Mircosoft hierfür verwendet und den Entsprechenden Eintrag gefunden.
Dort steht immer Event ID: 4740...
Mittlerweile hat mir ein Kollege auch mitgeteilt dass es wohl keine Geige mehr spielt ob Kerberos an oder aus ist.
Trotzdem lockedout
Hast du da noch ne Idee?
Grüße
Marco
Was passiert, wenn du einem User ein entsprechendes Passwort über den DC vorgibst und er das nicht bei Anmeldung ändern muss?
Gruß
Looser
Gruß
Looser
Hallo.
Ist eventuell OWA von außen erreichbar?
Nicht das jemand eure Domäne auf dem Kieker hat und von extern wahllos Konten ausprobiert und diese dann entsprechend durch Falscheingabe sperrt.
Leider ist der Komfort von OWA ja immer auch mit dem Preis eines Einfallstores zu bezahlen. Wir haben den Dienst nur temporär (maximal eine Arbeitswoche) bei einzelnen Konten aktiv.
Gruß
Marc
Ist eventuell OWA von außen erreichbar?
Nicht das jemand eure Domäne auf dem Kieker hat und von extern wahllos Konten ausprobiert und diese dann entsprechend durch Falscheingabe sperrt.
Leider ist der Komfort von OWA ja immer auch mit dem Preis eines Einfallstores zu bezahlen. Wir haben den Dienst nur temporär (maximal eine Arbeitswoche) bei einzelnen Konten aktiv.
Gruß
Marc
Im Eventlog steht immer dass es von seinem PC kam, nicht von extern
Auch schon gemacht, brachte keine Besserung
Moin,
Gruß,
Dani
Hast du da noch ne Idee?
ist es möglich, dass die (alten) Zugangsdaten in einer Anwendung gespeichert sind, die nicht auf die Windows Funktionen (Tresor) zurückgreift? Unabhängig davon, habt ihr mehrere oder nur einen Writeable Domain Controllers im Einsatz?Gruß,
Dani
Moin dani,
Wir haben den DC1 und den DC2 die sich gegenseitig replizieren.
ich habe mich heute wieder intensiv mit dem Thema beschäftigt und konnte es nun mittels dem Lockedout User Tool von Microsoft drauf schließen das es wohl aus Outlook kommt.
Er fragt manchmal 4mal in der selben Sekunde bei Exchange mit der Begründung
„Anmeldeversuch mit expliziten anmeldetdaten“ wobei das nur bei einem vom vielen Usern ist. Angegebener Prozess ist immer svchost.exe in System32...
Im Tresor ist nichts mehr... habe das Gefühl aber das die Daten in ihrendeinem Cache sind den ich nicht finde...
Gruß
Marco
Wir haben den DC1 und den DC2 die sich gegenseitig replizieren.
ich habe mich heute wieder intensiv mit dem Thema beschäftigt und konnte es nun mittels dem Lockedout User Tool von Microsoft drauf schließen das es wohl aus Outlook kommt.
Er fragt manchmal 4mal in der selben Sekunde bei Exchange mit der Begründung
„Anmeldeversuch mit expliziten anmeldetdaten“ wobei das nur bei einem vom vielen Usern ist. Angegebener Prozess ist immer svchost.exe in System32...
Im Tresor ist nichts mehr... habe das Gefühl aber das die Daten in ihrendeinem Cache sind den ich nicht finde...
Gruß
Marco
wir hatten mal sowas... wir haben 2 Domänen ohne Vertrauensstellung (der Admin hat von Federation noch nie was gehört bzw hören wollen), in der einen Domäne Password geändert... zweite Domäne vergessen, im Loginscript stand 12x sowas wie net use x: \\sharexy /user:domäne2\%username%
Wenn man das so explizit ohne Paßwort hinschreibt dann nimmt Windows das aktuelle Benutzerkennwort.
Jede Zeile wurde dann als fehlerhafter Anmeldeversuch interpretiert, der User war 30 Minuten in Domäne 2 gesperrt.
Wenn man das so explizit ohne Paßwort hinschreibt dann nimmt Windows das aktuelle Benutzerkennwort.
Jede Zeile wurde dann als fehlerhafter Anmeldeversuch interpretiert, der User war 30 Minuten in Domäne 2 gesperrt.
