Nach Passwortänderung Eventid 1083 und 1955 + Kontosperrung

[mcdaniels 29]

Guten Morgen,

 

leider stehe ich vor einem Problem, bei dem ich anstehe. Ein User hat heute sein Passwort geändert. Seitdem kann er sich nicht mehr einloggen. Im AD bekomme ich EVENT ID 1083 und 1955.

 

Event 1083:

Die Active Directory-Domänendienste konnte das folgende Objekt nicht mit Änderungen vom Verzeichnisdienst an der folgenden Netzwerkadresse aktualisieren, weil die Active Directory-Domänendienste mit der Verarbeitung von Informationen ausgelastet war.

 

Betroffen hiervon ist exakt das Userkonto bei dem die Passwortänderung durchgeführt wurde.

 

Das Konto wird auch sofort gesperrt (Wir haben eine Richtlinie per GPO -> 3x Passwort falsch = Kontosperrung).

 

Event 1955:

Eine entsperrung hilft nichts, da es sofort wieder gesperrt wird. Es gibt keine Geräte, die sich ggf. mit dem User (mit falschem Passwort) anmelden. Eine Sperrung durch die Eingabe des falschen Passwortes kann ich somit ausschließen.

 

Die Active Directory-Domänendienste sind beim Übernehmen replizierter Änderungen auf das folgende Objekt auf einen Schreibkonflikt gestoßen.
 
Objekt:
CN=User,OU=OU_Standardusers,DC=domaene,DC=local
Zeit in Sekunden:
0  
 
Ereignisprotokolleinträge vor diesem Eintrag zeigen an, ob die Aktualisierung akzeptiert wurde oder nicht.
 
Ein Schreibkonflikt kann durch simultane Änderungen an demselben Objekt oder durch simultane Änderungen an anderen Objekten, die auf das Objekt verweisende Attribute haben, verursacht werden. Dies tritt in der Regel auf, wenn das Objekt eine große Gruppe mit vielen Mitgliedern darstellt und die Funktionsebene der Gesamtstruktur auf Windows 2000 festgelegt ist. Durch diesen Konflikt werden zusätzliche Aktualisierungsversuche ausgelöst. Wenn das System langsam wirkt, könnte dies daran liegen, dass diese Änderungen repliziert werden.
 
Benutzeraktion
Verwenden Sie kleinere Gruppen für diesen Vorgang, oder erhöhen Sie die Gesamtstrukturfunktionsebene auf Windows Server 2003.

 

• Repadmin meldet durchwegs erfolgreiche Replikationen.  Eine Useranlage funktioniert, die zugehörige Replikation zwischen den 2 DCs auch.
• Dcdiag meldet auf beiden DCs KEINE Fehler.
• Eine Passwortänderung bei einem neu angelegten Testuser, zeigt dieses Verhalten nicht. Die Passwortänderung funktioniert, das Konto wird nicht gesperrt.

 

Wo könnte man hier ansetzen?

 

Danke!

LG

 

 

 

 

 

bearbeitet 25. April 2019 von mcdaniels

[mcdaniels 29]

Nachdem ich auf den DCs keinerlei Probleme finden konnte, habe ich mir jetzt nochmal alle Eventlogs durchgeschaut.  Hierbei ist mir aufgefallen dass die fehlerhafte Auth. immer wieder vom Mailclient (mit dem Userkonto)  ausgeht, der per SSO arbeitet (über AD).

 

Das hat mich wieder so einiges gelehrt. Den Benutzer zu fragen: "Bist du noch auf einem anderen PC angemeldet, der eingeschaltet ist und hast etwas offen (Mail zb.)" ist sinnlos!". Denn da kommt dann ein: "Nein". Und bei Konfrontation mit dem aktellen Stand ein: "Oh, daran hab ich nicht gedacht...".

 

Konkret war der User wohl schon länger auf einem PC angemeldet/gesperrt (Mailprogramm offen etc), hat dann auf einem anderen Arbeitsplatz weitergearbeitet und dort das Passwort geändert. Dies dürfte in letzter Instanz die Sperrorgie ausgelöst haben.

 

Allerdings kann ich mir die Medung des DC noch nicht ganz erklären:

Die Active Directory-Domänendienste sind beim Übernehmen replizierter Änderungen auf das folgende Objekt auf einen Schreibkonflikt gestoßen.

 

Betreffend Sperrung sag ich jetzt einfach mal nix...

 

 

bearbeitet 25. April 2019 von mcdaniels

[zahni 554]

Gesperrte Konten werden im AD sofort an die beteiligten DC synchronisiert. Das gibt teilweise merkwürdige Meldungen, besonders wenn den DC auf Deutsch laufen lässt.

Da musst Du Dir keine Sorgen machen.

[daabm 1.354]

Andere Frage: Auf welchem Domain Level läuft das ganze? Wenn noch 2000, dann befolge den Tipp oben im Eventtext und geh auf das maximal mögliche. Ab 2003 gab es Attributreplikation, davor nur komplette Objekte... Das führt dann gern zu dem von Dir beschriebenen Replikationsproblem.

Oder hast Du noch Domain Controller mit OS-Versionen vor 2008R2 am Laufen???

[mcdaniels 29]

@daabm: Die Domäne läuft auf dem höchstmöglichen Domainlevel des Server 2012, wurde damals komplett neu hochgezogen.

 

D.h. Domainlevel/Funktionsebene Server 2012.

 

@zahni: Danke für die Info.

[Squire 261]

such auf den DCs nach Events mit der ID4740 - dort wird der Account genannt und die Workstation von der aus dieser gesperrt wird,

 

Erfahrungsgemäß sind auf der dort genannten Workstation zu 99% im Anmeldetressor (Credentialstore) in der alten klassischen Systemsteuerung die Anmeldedaten des Users mit dem vorherigen Passwort gespeichert. In den restlichen 1% läuft auf der genannten Büchse irgendein Skript, Task oder Dienst mit den Credentials des users und dem alten Passwort ...

 

Wetten?

[zahni 554]

Prüfe bitte auch die Gesamtstrukturfunktionsebene.

[mcdaniels 29]

@zahni: Hab ich ist auf 2012 (siehe weiter oben)

@squire: Es war ein zweiter PC, auf dem der User angemeldet war im Mailprogramm. Der PC war gesperrt (schon länger). Der User hat dann auf einem anderen PC das Passwort geändert. (siehe oben).

[daabm 1.354]

Was soll man dazu noch sagen... OW