13
AD Kontenentsperrung auf mehreren DCs
Hallo und einen schönen Tag an alle.
Vorab eine Umfeldbeschreibung.
Eine AD-Domäne, 7 Standorte mit je einem DC (Windows 2019/2022 Server), FSMO Rollen alle auf einem DC, Hybrid Umgebung zu Azure AD.
Seit einer leider nicht näher bestimmbaren Zeit haben wir folgendes Problem:
Ein User wird im AD gesperrt.
Wir entsperren den User auf einem DC, entweder GUI oder PS. Wenn der User im HO ist (VPN zur Firma) oder im Sperrbildschirm schlägt die erneute Anmeldung trotzdem Fehl mit dem Hinweis das er noch gesperrt ist.
Wir haben dann festgestellt, dass die Kontenentsperrung nur auf dem Server erfolgt, auf dem sie durchgeführt wurde und vlt einem oder zwei weiteren. Aber auf den anderen Servern kommt die Entsperrung erst nach unterschiedlicher Zeit 3, 8, 13 Minuten an. Auch die festgestellte Zeit ist nicht immer gleich.
Bisher bin ich davon ausgegangen, dass solche Infos zwischen den DC´s sofort ausgetauscht werden. Aber auch hier weiß ich gar nicht ob das stimmt und auf welchem Weg. Wenn da einer was zum Nachlesen hat, wäre ich dankbar.
Aber nun zur eigentlichen Frage: Wo nach kann ich schauen was das Problem ist oder wodurch es ausgelöst wird/wie ich es lösen kann? Selbst eine von Hand angestoßene Replikation beschleunigt nix.
Wir werden zwar im Laufe des Jahres die DC´s bis auf einen herausnehmen, aber ich hätte es gern verstanden, wo das Problem ist und wie ich es beheben kann.
Mit freundlichen Grüßen
Vorab eine Umfeldbeschreibung.
Eine AD-Domäne, 7 Standorte mit je einem DC (Windows 2019/2022 Server), FSMO Rollen alle auf einem DC, Hybrid Umgebung zu Azure AD.
Seit einer leider nicht näher bestimmbaren Zeit haben wir folgendes Problem:
Ein User wird im AD gesperrt.
Wir entsperren den User auf einem DC, entweder GUI oder PS. Wenn der User im HO ist (VPN zur Firma) oder im Sperrbildschirm schlägt die erneute Anmeldung trotzdem Fehl mit dem Hinweis das er noch gesperrt ist.
Wir haben dann festgestellt, dass die Kontenentsperrung nur auf dem Server erfolgt, auf dem sie durchgeführt wurde und vlt einem oder zwei weiteren. Aber auf den anderen Servern kommt die Entsperrung erst nach unterschiedlicher Zeit 3, 8, 13 Minuten an. Auch die festgestellte Zeit ist nicht immer gleich.
Bisher bin ich davon ausgegangen, dass solche Infos zwischen den DC´s sofort ausgetauscht werden. Aber auch hier weiß ich gar nicht ob das stimmt und auf welchem Weg. Wenn da einer was zum Nachlesen hat, wäre ich dankbar.
Aber nun zur eigentlichen Frage: Wo nach kann ich schauen was das Problem ist oder wodurch es ausgelöst wird/wie ich es lösen kann? Selbst eine von Hand angestoßene Replikation beschleunigt nix.
Wir werden zwar im Laufe des Jahres die DC´s bis auf einen herausnehmen, aber ich hätte es gern verstanden, wo das Problem ist und wie ich es beheben kann.
Mit freundlichen Grüßen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7738163199
Url: https://administrator.de/forum/ad-kontenentsperrung-auf-mehreren-dcs-7738163199.html
Ausgedruckt am: 03.04.2025 um 08:04 Uhr
13 Kommentare
Neuester Kommentar
Hi
das scheint eher ein Replikationsproblem im AD zu sein, Kontensperren, Passwortänderungen und vergleichbare Accountaktivität werden im Regelfall direkt Repliziert, egal ob in den Eigenschaften andere Zeitfenster eingetragen sind (das "Relikt" für schlechte Verbindungen aus den "Active Directory-Standorte und -Dienste" Einstellungen).
Die erst Bewertung, wie die Replikaton läuft erhälst via "repadmin /replsummary".
Prüfe zu dem, ob die Zeiten an allen DC's "in sync" sind und es dort keine Abweichungen gibt (mit Bezug auf UTC)
das scheint eher ein Replikationsproblem im AD zu sein, Kontensperren, Passwortänderungen und vergleichbare Accountaktivität werden im Regelfall direkt Repliziert, egal ob in den Eigenschaften andere Zeitfenster eingetragen sind (das "Relikt" für schlechte Verbindungen aus den "Active Directory-Standorte und -Dienste" Einstellungen).
Die erst Bewertung, wie die Replikaton läuft erhälst via "repadmin /replsummary".
Prüfe zu dem, ob die Zeiten an allen DC's "in sync" sind und es dort keine Abweichungen gibt (mit Bezug auf UTC)
Hi,
wenn Ihr da mehrere Standorte habt und diese so auch im AD eingetragen sind, dann replizieren sich die DC's standortübergreifend max. alle 15 min. Es sei denn, Ihr habt explizit die standortübergreifende Benachrichtigung aktiviert.
Also 1. Frage: Was habt ihr da genau konfiguriert?
Eine Sperrung oder Deaktivierung gilt meines Wissens als "dringe Nachricht" und wird außer der Reihe zwischen den DC "sofort" propagiert. Abholen müssen sich diese Info aber die anderen DC selbst.
Eine Entsperrung oder Aktiviereung gilt dagegen nicht als "dringe Nachricht". Meines Wissens. Also hier die normale Replikationslatenz.
Die Tatsache, dass das nicht "sofort" repliziert wird, oder die, warum das Konto überhaupt gesperrt wird?
Wenn letzteres:
Das bekommst Du nur raus, wenn Du die Eventlogs "Sicherheit" aller DC's auswertest.
E.
Bei MS gibt es ein Tool namens "Account Lockout Status".
https://www.microsoft.com/en-us/download/details.aspx?id=15201
wenn Ihr da mehrere Standorte habt und diese so auch im AD eingetragen sind, dann replizieren sich die DC's standortübergreifend max. alle 15 min. Es sei denn, Ihr habt explizit die standortübergreifende Benachrichtigung aktiviert.
Also 1. Frage: Was habt ihr da genau konfiguriert?
Eine Sperrung oder Deaktivierung gilt meines Wissens als "dringe Nachricht" und wird außer der Reihe zwischen den DC "sofort" propagiert. Abholen müssen sich diese Info aber die anderen DC selbst.
Eine Entsperrung oder Aktiviereung gilt dagegen nicht als "dringe Nachricht". Meines Wissens. Also hier die normale Replikationslatenz.
Wo nach kann ich schauen was das Problem ist oder wodurch es ausgelöst wird/wie ich es lösen kann?
Ich bin mir jetzt nicht sicher, welches Problem Du hier meinst.Die Tatsache, dass das nicht "sofort" repliziert wird, oder die, warum das Konto überhaupt gesperrt wird?
Wenn letzteres:
Das bekommst Du nur raus, wenn Du die Eventlogs "Sicherheit" aller DC's auswertest.
E.
Bei MS gibt es ein Tool namens "Account Lockout Status".
https://www.microsoft.com/en-us/download/details.aspx?id=15201
Zitat von @clSchak:
Prüfe zu dem, ob die Zeiten an allen DC's "in sync" sind und es dort keine Abweichungen gibt (mit Bezug auf UTC)
Sorry, aber das ist falsch.Prüfe zu dem, ob die Zeiten an allen DC's "in sync" sind und es dort keine Abweichungen gibt (mit Bezug auf UTC)
Interessant ist nur die Zeitdifferenz untereinander.
Wenn die Server alle in Kuba stehen, aber alle eine Zeit von Hawaii haben, dann ist das auch OK.
@emeriks : Das die Zeit innerhalb der Domäne in Sync sein muss ist klar, aber trotzdem sollte die mit der "Echtzeit" auch in Sync sein und als Referenz eigent sich am besten UTC da hier keine +/- Regelung erfolgt. Das man die Server dann auf die passende Zeitzone einstellt ist ja auch korrekt, aber Basis ist immer UTC.
Ich würde kein Netzwerk ohne dedizierte Zeitquelle einsetzen, sei es mit einem internen NTP Server (damit meine ich nicht einen Windows- oder Linuxserver) oder die Sync via Internet mit einem öffentlichen NTP Server.
Asnyc Zeiten sind richtiger Mist bei Logauswertungen, hat doch keiner Lust, erstmal die Zeitdifferenz zur "Echtzeit" jedes Mal umzurechnen
Edit / Add: spätestens wenn du MFA mit OTP Tokens verwendest, sollte das alles mit eine öffentlichen Quelle in Sync sein oder die Tokens sind nur mit der Domäne verbunden, dann funktioniert das auch ja.
Ich würde kein Netzwerk ohne dedizierte Zeitquelle einsetzen, sei es mit einem internen NTP Server (damit meine ich nicht einen Windows- oder Linuxserver) oder die Sync via Internet mit einem öffentlichen NTP Server.
Asnyc Zeiten sind richtiger Mist bei Logauswertungen, hat doch keiner Lust, erstmal die Zeitdifferenz zur "Echtzeit" jedes Mal umzurechnen
Edit / Add: spätestens wenn du MFA mit OTP Tokens verwendest, sollte das alles mit eine öffentlichen Quelle in Sync sein oder die Tokens sind nur mit der Domäne verbunden, dann funktioniert das auch ja.
Moin,
macht es doch einfach so:
Im Active Directory Benutzer und Computer ganz oben rechte Maustaste -> Domänencontroller ändern
Dann den DC des Standorts auswählen und dort den User entsperren. Dann läuft das ohne Probleme sofort.
<edit>Replikation per Hand anstoßen, ist keine gute Idee.</edit>
hth
Erik
macht es doch einfach so:
Im Active Directory Benutzer und Computer ganz oben rechte Maustaste -> Domänencontroller ändern
Dann den DC des Standorts auswählen und dort den User entsperren. Dann läuft das ohne Probleme sofort.
<edit>Replikation per Hand anstoßen, ist keine gute Idee.</edit>
hth
Erik
Hallo.
Danke an alle die bis jetzt geantwortet haben. Echt toll von euch.
Die Serverzeiten werden über den gleichen Zeitdienst aus dem Internet synchronisiert.
Die Frage wodurch der MA gesperrt wird ist kein Problem, die Suche nach Event ID 4740 verrät einiges, nicht alles, aber einiges. Allerdings sehe ich das nur auf dem "ersten DC der Domäne" in der Ereignisanzeige, genauso wie ID 4767 (ein Konto wurde entsperrt). So dass ich mir die Frage stellte, wie die andern DC von der Entsperrung erfahren.
Mein Problem ist wirklich, dass die "Entsperrmeldung" nicht sofort auf allen Servern durchgeht.
repladmin /replsummary brachte folgendes:
Quell-DSA Größtes Delta Fehler/gesamt %% Fehler
Server1 02h:40m:32s 0 / 20 0
Server2 02h:39m:09s 0 / 10 0
Server3 13m:32s 0 / 25 0
Server4 13m:32s 0 / 35 0
Server5 10m:32s 0 / 10 0
Server6 02h:39m:09s 0 / 30 0
Server7 09m:38s 0 / 15 0
Server8 09m:08s 0 / 10 0
Ziel-DSA Größtes Delta Fehler/gesamt %% Fehler
Server1 02h:39m:10s 0 / 30 0
Server2 02h:28m:33s 0 / 20 0
Server3 07m:35s 0 / 15 0
Server4 05m:27s 0 / 25 0
Server5 04m:28s 0 / 15 0
Server6 02h:40m:32s 0 / 20 0
Server7 02m:56s 0 / 20 0
Server8 09m:39s 0 / 10 0
Allerdings muss ich zu meiner Schande eingestehen, dass mir "Größtes Delta" in dem Zusammenhang gar nichts sagt. Ich sehe nur extrem abweichende Zahlen vor mir, die vlt eine ziemlich große Latenz offenbaren, aber das ist nur geraten, da ich im Netz leider auch nichts Gescheites gefunden habe, wie ich die diese Differenzen bewerten soll.
Mit freundlichen Grüßen
Danke an alle die bis jetzt geantwortet haben. Echt toll von euch.
Die Serverzeiten werden über den gleichen Zeitdienst aus dem Internet synchronisiert.
Die Frage wodurch der MA gesperrt wird ist kein Problem, die Suche nach Event ID 4740 verrät einiges, nicht alles, aber einiges. Allerdings sehe ich das nur auf dem "ersten DC der Domäne" in der Ereignisanzeige, genauso wie ID 4767 (ein Konto wurde entsperrt). So dass ich mir die Frage stellte, wie die andern DC von der Entsperrung erfahren.
Mein Problem ist wirklich, dass die "Entsperrmeldung" nicht sofort auf allen Servern durchgeht.
repladmin /replsummary brachte folgendes:
Quell-DSA Größtes Delta Fehler/gesamt %% Fehler
Server1 02h:40m:32s 0 / 20 0
Server2 02h:39m:09s 0 / 10 0
Server3 13m:32s 0 / 25 0
Server4 13m:32s 0 / 35 0
Server5 10m:32s 0 / 10 0
Server6 02h:39m:09s 0 / 30 0
Server7 09m:38s 0 / 15 0
Server8 09m:08s 0 / 10 0
Ziel-DSA Größtes Delta Fehler/gesamt %% Fehler
Server1 02h:39m:10s 0 / 30 0
Server2 02h:28m:33s 0 / 20 0
Server3 07m:35s 0 / 15 0
Server4 05m:27s 0 / 25 0
Server5 04m:28s 0 / 15 0
Server6 02h:40m:32s 0 / 20 0
Server7 02m:56s 0 / 20 0
Server8 09m:39s 0 / 10 0
Allerdings muss ich zu meiner Schande eingestehen, dass mir "Größtes Delta" in dem Zusammenhang gar nichts sagt. Ich sehe nur extrem abweichende Zahlen vor mir, die vlt eine ziemlich große Latenz offenbaren, aber das ist nur geraten, da ich im Netz leider auch nichts Gescheites gefunden habe, wie ich die diese Differenzen bewerten soll.
Mit freundlichen Grüßen
Moin,
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
hinterher.
Dann pusht dieser DC eine Replikation an alle DCs in der Domäne.
Afaik ist die Standortübergreifende Replikation bei 180 min.
Das müsste ich aber tatsächlich erst nochmal nach lesen.
Gruß
Jasper
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
1
repadmin /syncall / APeDhinterher.
Dann pusht dieser DC eine Replikation an alle DCs in der Domäne.
Afaik ist die Standortübergreifende Replikation bei 180 min.
Das müsste ich aber tatsächlich erst nochmal nach lesen.
Gruß
Jasper
Zitat von @Palomino:
Ein User wird im AD gesperrt.
Wir entsperren den User auf einem DC, entweder GUI oder PS. Wenn der User im HO ist (VPN zur Firma) oder im Sperrbildschirm schlägt die erneute Anmeldung trotzdem Fehl mit dem Hinweis das er noch gesperrt ist.
Wir haben dann festgestellt, dass die Kontenentsperrung nur auf dem Server erfolgt, auf dem sie durchgeführt wurde und vlt einem oder zwei weiteren. Aber auf den anderen Servern kommt die Entsperrung erst nach unterschiedlicher Zeit 3, 8, 13 Minuten an. Auch die festgestellte Zeit ist nicht immer gleich.
Also für mich hört sich das sehr eindeutig nach Passwort-Container (Anmeldeinformationsverwaltung), aka, z.B. für eine Netzlaufwerks-Verbindung oder Ähnliches hinterlegte Credentials mit falschem oder abgelaufenem Passwort.Ein User wird im AD gesperrt.
Wir entsperren den User auf einem DC, entweder GUI oder PS. Wenn der User im HO ist (VPN zur Firma) oder im Sperrbildschirm schlägt die erneute Anmeldung trotzdem Fehl mit dem Hinweis das er noch gesperrt ist.
Wir haben dann festgestellt, dass die Kontenentsperrung nur auf dem Server erfolgt, auf dem sie durchgeführt wurde und vlt einem oder zwei weiteren. Aber auf den anderen Servern kommt die Entsperrung erst nach unterschiedlicher Zeit 3, 8, 13 Minuten an. Auch die festgestellte Zeit ist nicht immer gleich.
Das Ding will sich automatisch verbinden und Zack! der Account ist wieder gesperrt. UNd weil die Replikation unterschiedlich lange dauern kann, hat das genau den Effekt, den du beschreibst.
Nein. Die Anmeldeinformationsverwaltung hat da keinen Einfluss drauf. Wenn ich einen Test-User über OWA sich sperren lasse, ist der nirgends angemeldet.
Es geht wirklich nur um die "verspätete Meldung oder Reaktion" der Entsperrmeldung an die anderen DC.
Es geht wirklich nur um die "verspätete Meldung oder Reaktion" der Entsperrmeldung an die anderen DC.
Zitat von @JasperBeardley:
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
hinterher.
Dann pusht dieser DC eine Replikation an alle DCs in der Domäne.
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
1
repadmin /syncall /APeDDann pusht dieser DC eine Replikation an alle DCs in der Domäne.
repadmin/syncall hatte ich schon ohne Erfolg versucht, aber jetzt mit /aped noch hinten drann, hat es sofort funktioniert.
Vielen Dank Jasper.
Das löst mein eigentliches Problem nach der Ursache, der nicht weitergegebenen Entsperrung nicht, erleichtert aber in jedem Fall jetzt die Arbeit.
Wenn natürlich noch jemand eine Idee hat, warum die Entsperrt Meldungen verzögert auf den anderen DC´s ankommen oder verzögert verarbeitet werden, teste ich das gern natürlich weiter durch, denn das Push händisch erzwingen, kann vlt nicht die Dauerlösung sein.
Ich habe gerade gelesen, dass für das Sperren und Entsperren der Konten der PDC Emulator zuständig ist. Auf jeden Fall wird er auf dem Server gehalten, von dem ich meistens die Entsperrungen durchführe. Dort werden fast alle FSMO Rollen gehalten, nur der Schemamaster wird auf einem anderen DC gehalten. Wie kann ich überprüfen, ob der PDC Emulator richtig arbeitet, kann man das testen? Führt die Trennung von Schemamaster und PDC Emulator auf zwei Servern zu dem Problem?
Bei repadmin /showreps <Servername> steht bei allen da "war erfolgreich".
Mit freundlichen Grüßen und einen wunderschönen Tag allen.
Zitat von @Palomino:
Nein. Die Anmeldeinformationsverwaltung hat da keinen Einfluss drauf. Wenn ich einen Test-User über OWA sich sperren lasse, ist der nirgends angemeldet.
Es geht wirklich nur um die "verspätete Meldung oder Reaktion" der Entsperrmeldung an die anderen DC.
Nein. Die Anmeldeinformationsverwaltung hat da keinen Einfluss drauf. Wenn ich einen Test-User über OWA sich sperren lasse, ist der nirgends angemeldet.
Es geht wirklich nur um die "verspätete Meldung oder Reaktion" der Entsperrmeldung an die anderen DC.
Nein, da verstehst du mich falsch. Ein Benutzer kann sich irgendwo automatisch anmelden (z.B. Netzlaufwerk) und dazu werden seinen Cretentials gespeichert. Dazu muss er sich anmelden damit die andere Verbindung aufgebaut wird, ja!
Für einen Scheduled Task der als System mit des Users Credentials ausgeführt wird, muss er nicht aktiv angemeldet sein. Netzlaufwerk war demnach eher ein schlechtes Bsp.
@Palomino
Replizierte Änderungen an AD-Objekten (hier die Entsperrungen) sind keine "Ereignisse" und werden deshalb auch nicht im Eventlog von DC ausgegeben, welche sich eine Änderung von einem anderen DC abgeholt haben.
auf dem "ersten DC der Domäne"
Dieser DC ist wahrscheinlich der PDC-Emulator. Und wenn alle Sperrungen - auch für die Konten von Benutzern an den Außenstandorten - nur oder vorrangig über diesen Server erfolgen, dann ist das ein ziemlich sicherer Hinweis darauf, dass die Standorte nicht im AD abgebildet sind. Das würde bedeuten, dass die DC sich alle als zu einem Standort gehörig betrachten und die Replikation dann spätestens alle 5 Minuten erfolgt. Im günstigsten Fall steht das nächste Replikationsintervall eines DC sofort nach der Entsperrung an, dann holt er sich das "sofort" ab. Im ungünstigsten Fall hat sich ein DC gerade erst repliziert. Dann wird er sich die Entsperrung erst nach 5 min abholen.Replizierte Änderungen an AD-Objekten (hier die Entsperrungen) sind keine "Ereignisse" und werden deshalb auch nicht im Eventlog von DC ausgegeben, welche sich eine Änderung von einem anderen DC abgeholt haben.
Moin,
Nochmal: Das ist keine gute Idee! Der Befehl sorgt dafür, dass nicht wie bei der normalen Replikation nur das Delta repliziert wird, sondern das ganze AD mit allen Informationen. Bei sieben Standorten, über deren Anbindung wir nichts wissen, kann das mehrere Stunden dauern und das Netz so belasten, dass es in die Knie geht. Ein kompletter Sync des AD sollte immer nur das letzte Mittel sein.
Die Lösung des Problems habe ich auch schon genannt: Man verbindet sich mit dem DC des Standorts. So macht man das.
Liebe Grüße
Erik
Zitat von @JasperBeardley:
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
schieb nach dem Entsperren einfach aus einer administrativen CMD ein
1
repadmin /syncall / APeDNochmal: Das ist keine gute Idee! Der Befehl sorgt dafür, dass nicht wie bei der normalen Replikation nur das Delta repliziert wird, sondern das ganze AD mit allen Informationen. Bei sieben Standorten, über deren Anbindung wir nichts wissen, kann das mehrere Stunden dauern und das Netz so belasten, dass es in die Knie geht. Ein kompletter Sync des AD sollte immer nur das letzte Mittel sein.
Die Lösung des Problems habe ich auch schon genannt: Man verbindet sich mit dem DC des Standorts. So macht man das.
Liebe Grüße
Erik
