20
Windows Domäne - Kennwort Reset funktioniert nicht mehr
Werte Admingemeinde,
seit letzter Woche funktioniert in unserer Domäne der Kennwortreset der Benutzeraccounts nicht mehr.
Ist ein Kennwort abgelaufen oder der Flag "Benutzer muss das Kennwort vor nächster Änderung ändern" gesetzt kommt der Benutzer über diesen Schritt nicht mehr hinaus.
Das zeigt sich folgender maßen:
In unserem Fall erscheint aber einfach die oben stehende Meldung erneut. Man befindet sich in einem Loop
Weder am Domaincontroller (Server 2003 R2) oder an der Maschine an welcher der Benutzer versucht sich anzumelden wird etwas geloggt.
Kann uns jemand verraten welcher Dienst da fehlerhaft sein könnte? Wir haben keinen Anhaltspunkt.
Vielen Dank
verschneite Grüße
seit letzter Woche funktioniert in unserer Domäne der Kennwortreset der Benutzeraccounts nicht mehr.
Ist ein Kennwort abgelaufen oder der Flag "Benutzer muss das Kennwort vor nächster Änderung ändern" gesetzt kommt der Benutzer über diesen Schritt nicht mehr hinaus.
Das zeigt sich folgender maßen:
- Der Benutzer versucht sich an der Domäne mit seinem bisherigen Passwort anzumelden
- Es kann sich hier um das OWA, einen der Terminalserver oder auch ein Windows Client handeln
- Es wird aufgefordert das Passwort zu ändern
- Gibt man nun das alte gefolgt vom neuen Passwort ein und bestätigt dies, sollte man erwartungsgemäß die Meldung bekommen, dass
- Das Passwort geändert wurde oder
- Das Passwort aufgrund von Kennwortrichtlinien nicht übernommen werden konnte
In unserem Fall erscheint aber einfach die oben stehende Meldung erneut. Man befindet sich in einem Loop
Weder am Domaincontroller (Server 2003 R2) oder an der Maschine an welcher der Benutzer versucht sich anzumelden wird etwas geloggt.
Kann uns jemand verraten welcher Dienst da fehlerhaft sein könnte? Wir haben keinen Anhaltspunkt.
Vielen Dank
verschneite Grüße
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: 302797
Url: https://administrator.de/contentid/302797
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
20 Kommentare
Neuester Kommentar
Moin,
bekommen die Clients die korrekte Zeit vom DC, als stimmen die Uhrzeiten der Clients alle mit dem DC überein?
Was wurde letzte Woche alles geändert/vorgenommen?
Schau auf dem Server ob alle Dienste gestartet sind die auf automatisch stehen.
Gruß jodel32
bekommen die Clients die korrekte Zeit vom DC, als stimmen die Uhrzeiten der Clients alle mit dem DC überein?
Was wurde letzte Woche alles geändert/vorgenommen?
Schau auf dem Server ob alle Dienste gestartet sind die auf automatisch stehen.
Gruß jodel32
Hallo,
ist der 2003 der eintige DC oder gibt es auch 2012R2 DC in der Domäne? (evtl anderer Standort).
Wenn Das Passwort ab Server selber über die AD Konsole gesetzt wird, gehts aber oder?
Gruß
Chonta
ist der 2003 der eintige DC oder gibt es auch 2012R2 DC in der Domäne? (evtl anderer Standort).
Wenn Das Passwort ab Server selber über die AD Konsole gesetzt wird, gehts aber oder?
Gruß
Chonta
Hi.
Ist den Usern das Recht, Ihre Kennwörter zu ändern, evtl. genommen worden?
Ist den Usern das Recht, Ihre Kennwörter zu ändern, evtl. genommen worden?
Hallo Chonta,
gibt es da Probleme in dieser Mischumgebung? Oder geht es da um das Problem mit Kerberos von 2014?
Viele Grüße,
Ribiku
gibt es da Probleme in dieser Mischumgebung? Oder geht es da um das Problem mit Kerberos von 2014?
Viele Grüße,
Ribiku
Danke für eure Hilfe.
Folgende Umgebung:
Server 2003 R2 - Domaincontroller
Server 2008 R2 - Exchange 2010 R3
2x Server 2008 R2 - Terminalserver
Es gibt noch einen Server 2012 R2, welcher die AD Rolle installiert hat, aber noch nicht zum Controller heraufgestuft wurde. Dieses Setup läuft aber schon so seit ein paar Monaten. Das beschriebene Problem ist das erste Mal vor 2 Wochen aufgetreten.
Das Zurücksetzen der Passwörter über die AD Console funktioniert, solange man den Haken "Benutzer muss beim nächsten Login das Kennwort ändern" nicht setzt.
Uhrzeiten stimmen, auf dem DC laufen alle Dienste die auf automatisch stehen.
Das Recht wurde den Usern nicht entzogen, Konfigurationsänderungen wurden meines Wissens nicht durchgeführt.
Folgende Umgebung:
Server 2003 R2 - Domaincontroller
Server 2008 R2 - Exchange 2010 R3
2x Server 2008 R2 - Terminalserver
Es gibt noch einen Server 2012 R2, welcher die AD Rolle installiert hat, aber noch nicht zum Controller heraufgestuft wurde. Dieses Setup läuft aber schon so seit ein paar Monaten. Das beschriebene Problem ist das erste Mal vor 2 Wochen aufgetreten.
Das Zurücksetzen der Passwörter über die AD Console funktioniert, solange man den Haken "Benutzer muss beim nächsten Login das Kennwort ändern" nicht setzt.
Uhrzeiten stimmen, auf dem DC laufen alle Dienste die auf automatisch stehen.
Das Recht wurde den Usern nicht entzogen, Konfigurationsänderungen wurden meines Wissens nicht durchgeführt.
@ribiku.sith
Ich hatte das Problem als ich noch den 2003er hatte, das Windows 8 Clinets und glaube auch Windows 7 (bin mir da aber nicht sicher) nicht das Passwort neu setzen konnten.
Ist schon etwas her.
Der 2003er war auch ein SBS gewesen also hatte alle FMSO.
Wenn ich über die AD Konsole direkt auf dem 2012R2 das Passwort setzen lassen habe ging alles gut.
Was ich 100% weiß ist das es Probleme mit einer Gemischten Umgebung von 2003 und 2012R2 DCs gibt in Bezug auf die Passwortspeicherung von Computerkonten.
Bei Cleints fällt da snicht weiter groß auf aber bei Servern war das so dass bei einer Passwortänderung der 2012R2 Server der 2003 DC gesagt hat mag ich nicht und dann durfte der Server bis zum Neustart nicht mitspielen (keinerlei login möglich), dan gings wieder...
Könnte für die Benutzer ähnlich sein, Passwort wird von neuem Windows in einem anderen Format übermittelt/gespeichert und der 2003er sagt kann damit nix anfangen.
@Shardas
Passiert es auch wenn man einfach so das Passwort ändert?
iSt der 2003er ein SBS oder hat der FMSO?
Wie kann man die AD Rolle installiert haben ohne DC zu sein?
Wenn der 2003 kein SBS ist mal die PDC FMSO auf den neuesten DC schieben, evtl ist es damit schon erledigt.
Gruß
Chonta
Ich hatte das Problem als ich noch den 2003er hatte, das Windows 8 Clinets und glaube auch Windows 7 (bin mir da aber nicht sicher) nicht das Passwort neu setzen konnten.
Ist schon etwas her.
Der 2003er war auch ein SBS gewesen also hatte alle FMSO.
Wenn ich über die AD Konsole direkt auf dem 2012R2 das Passwort setzen lassen habe ging alles gut.
Was ich 100% weiß ist das es Probleme mit einer Gemischten Umgebung von 2003 und 2012R2 DCs gibt in Bezug auf die Passwortspeicherung von Computerkonten.
Bei Cleints fällt da snicht weiter groß auf aber bei Servern war das so dass bei einer Passwortänderung der 2012R2 Server der 2003 DC gesagt hat mag ich nicht und dann durfte der Server bis zum Neustart nicht mitspielen (keinerlei login möglich), dan gings wieder...
Könnte für die Benutzer ähnlich sein, Passwort wird von neuem Windows in einem anderen Format übermittelt/gespeichert und der 2003er sagt kann damit nix anfangen.
@Shardas
Dieses Setup läuft aber schon so seit ein paar Monaten. Das beschriebene Problem ist das erste Mal vor 2 Wochen aufgetreten.
Dan sind erst jetzt die ersten Passwörter abgelaufen.Passiert es auch wenn man einfach so das Passwort ändert?
iSt der 2003er ein SBS oder hat der FMSO?
Wie kann man die AD Rolle installiert haben ohne DC zu sein?
Wenn der 2003 kein SBS ist mal die PDC FMSO auf den neuesten DC schieben, evtl ist es damit schon erledigt.
Gruß
Chonta
Wie kann man die AD Rolle installiert haben ohne DC zu sein?
So lange man DCPROMO auf so einem Server nicht laufen lässt hat er zwar die nötige Rolle installiert ist aber dann noch kein DC, quasi ein "vorbereiter" aber noch nicht aktivierter DC. Sollte hier also keine Rolle spielen.Gruß jodel32
@114757
Danke für die Info, auf so eine idee bin ich bisher nie gekommen
Habe bisher immer durchgemacht, wieder was gelernt
Gruß
Chonta
Danke für die Info, auf so eine idee bin ich bisher nie gekommen
Habe bisher immer durchgemacht, wieder was gelernt
Gruß
Chonta
Hallo Chonta,
danke Dir mal wieder für die reichlichen Infos.
Viele Grüße,
Ribiku
danke Dir mal wieder für die reichlichen Infos.
Viele Grüße,
Ribiku
Hier nochmal die Fakten:
- Der Domänencontroller ist der 2003 R2 (kein SBS)
- Die Active Directory Console ist auf drei Servern installiert. Über jede installierte AD Console (2003, 2012 und 2008) können die Passwörter seitens der Admins zurück gesetzt werden.
- Nur Können es die Benutzer nicht mehr eigenständig machen wenn das Passwort
- abgelaufen ist oder
- Der Haken bei "Benutzer muss das Passwort beim nächsten Login ändern" gesetzt ist
- Vor ein paar Wochen wurde der letzte Mitarbeiter angelegt, dieser Konnte beim ersten Login wie gewohnt sein Passwort selber setzen
- Der Fehler ist Serverunabhängig. Alle Terminalserver, OWA und normale Windows Clients lassen alle das abgelaufene Passwort nicht ändern
- Der Loop:
- Benutzer versucht sich anzumelden
- das aktuelle Passwort wird eingegeben, es wird aufgefordert das Passwort zu ändern (screenshot)
- nachdem das aktuelle Passwort und das neue Passwort eingegeben wurde erscheint die Meldung aus dem Screenshot erneut
Führe mal folgenden Befehl in einer elevated Shell mit Domain-Admin Rechten aus und poste hier das Ergebnis:
Namen des DC und DN der Domain bitte anpassen
repadmin /showobjmeta <dc> "CN=krbtgt,CN=Users,DC=contoso,DC=com"
Hier das Ergebnis:
repadmin /showobjmeta server2003DC "CN=krbtgt,CN=Users,DC=domain,DC=local"
35 Einträge.
Lok.USN Ursprüngl. DSA Ur. USN Ur.Zeit/Datum Ver Attribut
======= =============== ========= ============= === =========
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 objectClass
11697 Standort\Server2003DC 11697 2009-08-16 14:02:35 1 cn
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12325 2005-02-05 21:06:09 2 description
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 instanceType
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 whenCreated
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 displayName
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 showInAdvancedViewOnly
2268918 Standort\Server2003DC 2268918 2012-08-27 20:11:41 4 nTSecurityDescriptor
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 name
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12322 2005-02-05 21:06:09 3 userAccountControl
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 codePage
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 countryCode
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 homeDirectory
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 homeDrive
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12323 2005-02-05 21:06:09 2 dBCSPwd
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 scriptPath
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 logonHours
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 userWorkstations
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12323 2005-02-05 21:06:09 2 unicodePwd
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12323 2005-02-05 21:06:09 2 ntPwdHistory
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12323 2005-02-05 21:06:09 2 pwdLastSet
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 primaryGroupID
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12324 2005-02-05 21:06:09 1 supplementalCredentials
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 userParameters
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 profilePath
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 objectSid
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 13944 2005-02-05 21:21:20 1 adminCount
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 comment
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12321 2005-02-05 21:06:09 1 accountExpires
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12323 2005-02-05 21:06:09 2 lmPwdHistory
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 sAMAccountName
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 sAMAccountType
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12446 2005-02-05 21:06:55 1 servicePrincipalName
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 objectCategory
11697 9640610b-9c3d-4182-9f4d-44dc355ae1bf 12320 2005-02-05 21:06:09 1 isCriticalSystemObject
0 Einträge.
Typ Attribut Zul. geändert Ursprügl. DSA Lok.USN Ur.USN Ver
======= ============ ============= ================= ======= ======= ===
Definierter Name
=============================
OK, dann hat sich meine Vermutung nicht bestätigt, hier liegt der Fehler also auch nicht.
Hallo,
ist eine Anmeldung nach Passwortänderum im OWA möglich? (mit dem neuen)
Schonmal probiert einen der DC kurz vom Netz zu nehmen und dann den Passwortänderungsvorgang durchzuführen?
Ist egal welcher DC nicht erreichbar ist das Problem immer noch da?
Wenn der 2003 noch FMSO hat, alle auf den 2008ter übertragen.
Gruß
Chonta
ist eine Anmeldung nach Passwortänderum im OWA möglich? (mit dem neuen)
Schonmal probiert einen der DC kurz vom Netz zu nehmen und dann den Passwortänderungsvorgang durchzuführen?
Ist egal welcher DC nicht erreichbar ist das Problem immer noch da?
Wenn der 2003 noch FMSO hat, alle auf den 2008ter übertragen.
Gruß
Chonta
Geht ja nicht, wie er oben schreibt.
Laut seiner Aussage haben die nur die AD-Rolle installiert sind aber nicht zu DCs hochgestuft worden, warum auch immer?? ..., denn nur für die Verwaltung braucht es die AD-Rolle ja gar nicht, sondern nur die Verwaltungstools.
Schonmal probiert einen der DC kurz vom Netz zu nehmen und dann den Passwortänderungsvorgang durchzuführen?
So wie er das geschrieben hat, hat er nur eine DC und das ist der 2003erWenn der 2003 noch FMSO hat, alle auf den 2008ter übertragen.
Dann müsste er diese erst mal zu DCs machen Laut seiner Aussage haben die nur die AD-Rolle installiert sind aber nicht zu DCs hochgestuft worden, warum auch immer?? ..., denn nur für die Verwaltung braucht es die AD-Rolle ja gar nicht, sondern nur die Verwaltungstools.
Hallo,
Bedeutet das man darüber nix ändern kann.
Aber ich wollte wissen ob man am Client das Passwort ändert und der Loop kommt isch von nem anderen Rechner über OWA einloggen kann. (mit dem neuen Passwort oder dem alten)
Jeh nachdem würde man sehen ob das neue Passwort überhaupt irgendwie an den DC gesendet wurde.
Was das andere betrifft, soll er den 2003er endlich einmotten, wenn er noch andere Server rumstehen hat die das machen können.
Sind noch XP Clients im Einsatz und ist das bei denen auch so?
Ich gehe mal davon aus das die Clients die das Problem haben mindestens Vsita und höher sind.
Wurden bevor es nicht m mehr ging wie normal irgendwelche Updates eingespielt?
Gruß
Chonta
Der Fehler ist Serverunabhängig. Alle Terminalserver, OWA und normale Windows Clients lassen alle das abgelaufene Passwort nicht ändern
Bedeutet das man darüber nix ändern kann.
Aber ich wollte wissen ob man am Client das Passwort ändert und der Loop kommt isch von nem anderen Rechner über OWA einloggen kann. (mit dem neuen Passwort oder dem alten)
Jeh nachdem würde man sehen ob das neue Passwort überhaupt irgendwie an den DC gesendet wurde.
Was das andere betrifft, soll er den 2003er endlich einmotten, wenn er noch andere Server rumstehen hat die das machen können.
Sind noch XP Clients im Einsatz und ist das bei denen auch so?
Ich gehe mal davon aus das die Clients die das Problem haben mindestens Vsita und höher sind.
Wurden bevor es nicht m mehr ging wie normal irgendwelche Updates eingespielt?
Gruß
Chonta
Hallo Chonta,
ja der 2003er soll auch baldigst vom 2012er abgelöst werden, daher wurde dort schon die AD Rolle installiert. Für die Heraufstufung fehlt mir allerdings noch etwas Hintergrundwissen, daher wurde das noch aufgeschoben.
Über einen anderen Rechner kann man sich nicht über das OWA anmelden. Allerdings ist mir bei dem versuch etwas aufgefallen:
Ich habe das mehrere Male geprüft, die Eingaben sind natürlich korrekt.
Sehr mysteriös
ja der 2003er soll auch baldigst vom 2012er abgelöst werden, daher wurde dort schon die AD Rolle installiert. Für die Heraufstufung fehlt mir allerdings noch etwas Hintergrundwissen, daher wurde das noch aufgeschoben.
Über einen anderen Rechner kann man sich nicht über das OWA anmelden. Allerdings ist mir bei dem versuch etwas aufgefallen:
- Benutzername und Passwort wird eingegeben
- Es wird aufgefordert das Passwort zu ändern, da abgelaufen
- Benutzername, Passwort und neues Passwort wird eingegeben
- Laut OWA sind Benutzername und (altes?) Passwort falsch?
Ich habe das mehrere Male geprüft, die Eingaben sind natürlich korrekt.
Sehr mysteriös
Welche Anmeldename-Variante wird benutzt DOMAIN\Username oder der UPN user@domain.de ? Beide Varianten schon probiert?
Keine davon. Da wir nur über eine Domain verfügen wurde die Standarddomain im Exchange konfiguriert. Dadurch wird nur der benutzername benötigt.
Wir haben es aber auch schon mit domain\user versucht
Wir haben es aber auch schon mit domain\user versucht
Ok,
dann mach Dir Doch mal den Spaß nach einer Passwortänderung die Daten abzufragen.
Ist das Passwort abgelaufen, wann geändert und so weiter.
Ich hatte es das Problem das meine nueen Windows8 Benutzer das Passwort nicht bei sich setzen konnten musste immer bei mir am Server gemacht werden.
XP hatte kein Problem.
Nachdem der 2003 endlich weg war, war das Problem weg.
Und was genau fehlt Dir da an Wissen?
Solange Exchange auf dem aktuelsten CU läuft macht der keine Probleme.
Bei den Terminalservern musst Du schauen ob die einen Server 2012R2 DC erlauben.
Forest und Domainleel auf 2003 anheben den 2012R2 zum DC machen und die FMS auf den bringen.
Dann kann der 2003er raus (vorrausgesetzt der 2012R2 ist auch DNS und auf dem 2003 läuft sonst kein wichtiger Dienst aber selbt dann kann der als DC demotet werden)
Das DNS gradebiegen und fertig.
Das einzige was passieren wird, wenn die Server ihr Passwprt ändern wollen wird das einen Neustart mitsich brignen, und die sind dann ggf kurzzeitig nicht arbeitsfähig.
Man kann das auch manuel anstoßen das die sich ein neues Passwort geben, dann bist Du live dabei.
(2012R2 DC speichern die AD Passwörter anders und das gibt bei einer Migration von 2003 Probleme)
dann mach Dir Doch mal den Spaß nach einer Passwortänderung die Daten abzufragen.
Ist das Passwort abgelaufen, wann geändert und so weiter.
Ich hatte es das Problem das meine nueen Windows8 Benutzer das Passwort nicht bei sich setzen konnten musste immer bei mir am Server gemacht werden.
XP hatte kein Problem.
Nachdem der 2003 endlich weg war, war das Problem weg.
ja der 2003er soll auch baldigst vom 2012er abgelöst werden, daher wurde dort schon die AD Rolle installiert. Für die Heraufstufung fehlt mir allerdings noch etwas Hintergrundwissen, daher wurde das noch aufgeschoben.
Und was genau fehlt Dir da an Wissen?
Solange Exchange auf dem aktuelsten CU läuft macht der keine Probleme.
Bei den Terminalservern musst Du schauen ob die einen Server 2012R2 DC erlauben.
Forest und Domainleel auf 2003 anheben den 2012R2 zum DC machen und die FMS auf den bringen.
Dann kann der 2003er raus (vorrausgesetzt der 2012R2 ist auch DNS und auf dem 2003 läuft sonst kein wichtiger Dienst aber selbt dann kann der als DC demotet werden)
Das DNS gradebiegen und fertig.
Das einzige was passieren wird, wenn die Server ihr Passwprt ändern wollen wird das einen Neustart mitsich brignen, und die sind dann ggf kurzzeitig nicht arbeitsfähig.
Man kann das auch manuel anstoßen das die sich ein neues Passwort geben, dann bist Du live dabei.
(2012R2 DC speichern die AD Passwörter anders und das gibt bei einer Migration von 2003 Probleme)
