Jump to content

Nach Passwortänderung Eventid 1083 und 1955 + Kontosperrung


Direkt zur Lösung Gelöst von mcdaniels,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von mcdaniels
Link zu diesem Kommentar
  • Beste Lösung

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... :rolleyes:

 

 

bearbeitet von mcdaniels
Link zu diesem Kommentar

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???

Link zu diesem Kommentar

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?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...