Sie haben keine Berechtigung ihr Kennwort zu ändern

[wean 10]

huhu :(

 

pünktlich zur Weihnachtszeit fängt der Stress an. Die Benutzer können "auf einmal" ihre Kennwörter nicht mehr ändern. Sie werden aufgefordert, ihr Kennwort zu ändern.

 

Nach Eingabe des alten und des neuen Kennworts erscheint anschliessend die Meldung:

 

Sie haben keine Berechtigung ihr Kennwort zu ändern

[/Quote]

 

 

Das ist aber überhaupt nicht wahr! Auf dem DC finde ich keinerlei Einträge (es wird alles überwacht) mit der Ereigniskennung 627.

 

Bei manchen Benutzern funktioniert es an manchen Tagen und anschliessend auch nicht mehr. Ändert ein Benutzer erfolgreich sein Kennwort - oder verhaut sich "erfolgreich" bei der Eingabe, erhalte ich auch eine entsprechende Meldung auf dem DC (Eventid 627).

 

Ich verspreche aber, dass der DC jederzeit voll und ganz erreichbar ist. Denn ich hatte zwei Mitarbeiter, welche gleichzeitig zu mir kamen und berichteten, dass sie am Vortag ihr Kennwort nicht ändern konnten, dieses aber "heute" abläuft.

 

Ich ging zu beiden Arbeitsplätzen hin - Beim ersten ging es plötzlich, beim zweiten nicht. Diesem Benutzer habe ich das Kennwort entsprechend manuell zurückgesetzt.

 

 

Macht mir ein Geschenk und hilft :d

[grizzly999 11]

Frage: kann es sein, dass die betroffenen Benutzer das an einer XP Workstation versuchen?

 

grizzly999

[nitro2000de 10]

In der Sicherheitsrichtlinien hat nicht zufällig einer rumgespielt?

[wean 10]

STIMMT! Alle bei denen dieses Problem auftritt haben Windows XP Professional - Ist mir noch gar nicht aufgefallen *boah*

 

Bei M$ hab' ich gelesen, dass es auch mit der Überwachung zusammenhängen kann. Dies allerdings nur für Server 2003 welschn' ich ned hab.

 

Wie kamst Du auf den Verdacht Grizzly?

[grizzly999 11]

Ich hatte das auch mal, ganz am Anfang, als ich meine zwei Clients von Windows 2000 Professional auf XP Professional umgestellt habe. Da kam diese ****e Meldung, aber wenn man sich angemeldet hatte, konnte man das Kennwort ändern.

Der Server war Windows 2000. Auf dem einen Rechner konnte ich es über die Gruppenrichtlinien richten, auf dem zweiten versagte dieselbe Methode. Erst nachdem ich einige Monate später die ganze Domäne neu aufsetzte war das Problem hinfällig.

Ich muss aber wegen der "Lösungsmöglichkeit erst recherchieren, ich kann es adhoc nicht mehr sagen. Ich melde mich wieder ;)

 

Gruß

 

grizzly999

[grizzly999 11]

Hallo wean,

 

habe ihn wieder gefunden, den Schalter und nochmals getestet, sollte also funktionieren:

Du brauchst eine Richtlinie für die OU DomainControllers mit folgender Einstellung:

Computerkonfiguration/Windows Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen. Suche dort den Wert "Weitere Einschränkungen für anonyme Verbindungen" und setze ihn auf "Keine - Standardberechtigung..."

 

Sag auch bescheid, ob' geklappt hat.

 

grizzly999

[blub 115]

wean, hast du nur einen DC mit allen FSMO-Rollen? Für mich hörts sich das nach nem Erreichbarkeitsprob mit dem PDC-Emulator an.

 

cu

blub

[grizzly999 11]

Wieso sollte das ein Erreichbarkeitsproblem mit dem PDC-Emulator sein? Bei Windows 2000 habe ich die Möglichkeit, auf jedem DC mein Kennwort zu ändern. Dass der PDC-Emulator als erstes das geänderte Kennwort empfängt, ändert daran nichts. Es ist vielmehr ein Berechtigungsproblem. Wenn ich das Kennwort ändern will, bevor ich authentifiziert bin, muss irgend ein Prozess an meiner Statt den DC connecten und dort mein Kennwort ändern. Das hängt aber von der oben genannten Sicherheitseinstellung ab, ob das der Prozeß darf oder nicht ;)

 

grizzly999

[wean 10]

Ey grizzly,

 

werde das nächste Woche ausprobieren und euch dann bescheid geben. Hoffentlich war es das. Geht einem ganz schön auf die Nerven.

 

Beeinflusst dieses denn zufälliger Weise den Registry-Schlüssel "HKLM-System-CurrentControlSet-Control-LSA-Restrictanonymous?" ?

 

Werde es nach Feierabend ausprobieren. Die Frage wäre aber, warum verhält sich XP hier anders als 2k?

 

 

Naja "wotevr" :p Sollte es geklappt haben, hast Du mir ne Menge Rumärgerei erspart :)

 

Danke dafür, wean

[blub 115]

war vielleicht ein bischen voreilig zu konkret.

 

Trotzdem, wenn Passwortänderungen an manchen Tagen funktionieren und mal wieder nicht, können es durchaus Erreichbarkeits/ Replikationsprobleme von GC/PDC restliche DCs sein.

Daher war ja die Frage, ob es nur einen DC gibt.

 

Berechtigungsprobleme erklären so einen "mal gehts/ mal nicht"- Effekt ja auch nicht wirklich schlüssig.

 

cu

blub

[grizzly999 11]

Da muss ich dir wieder Recht geben. Diese Aussage hatte ich nicht mehr bedacht. Es ist ein wirklich seltsames Phänomen und ich gebe zu, ich kann es nicht erklären, zumal, als ich es hatte, ging es immer nicht :rolleyes: (FSMOs waren aber immer da)

Aber da die Ablehnung der Kennwortänderung kommt, noch bevor man angemeldet ist, muss es von der Logik her ein Problem am DC sein, der eine Änderung nicht akzeptiert?!

 

Schaun wir mal, was wean rausfindet ...

 

 

grizzly999

[wean 10]

Ich werde es euch berichten :p

 

Es handelt sich ohnehin nur um einen Server mit allen FSMO's.

 

Aber die Tatsache, dass es "mal" geht und "mal" nicht bereitet mir auch Kopfzerbrechen, da ich ja nicht dynamische Berechtigungen habe.

 

Zudem handelt es sich um Domänencomputer, welche für solche Zwecke ohnehin authorisiert sein sollten.

 

Ausserdem erhalte ich, obwohl ALLES auf dem DC überwacht wird, keine einzigste Meldung, über den Versuch einer Kennwortänderung. (In dem Fall dass die besagte Meldung auftaucht) Nix - Rein gar nichts.

 

Sollte wenigstens das Symptom (Diese Meldung) für das ProblemX verschwinden, und die Kennwortänderung klappen, bin ich ja schon zufrieden.

 

Obwohl es bestimmt irgendwo eine Erklärung für dieses Verhalten gibt - da bin ich mir sicher.

[wean 10]

DAS WARS!!

 

Es ist tatsächlich dieser "Schalter". Was dieser letztendlich bewirkt ist der oben genannte Eintrag in der Registry:

 

HKLM-System-CurrentControlSet-Control-LSA-Restrictanonymous

[/Quote]

 

Ich werde, was dies betrifft noch weiter forschen und meine Ergebnisse hier brav eintragen :p

 

Vielen Dank derweilen!!

 

Gruss Andy

[PowerProf 10]

Hey Leute, da ich mich seitdem ich vor 2 Wochen einen 2. DC in unsere Firmendomain integriert habe und genau vor dem selben prob stande und immer wnen ich gegoogelt hab dieser thread ziemlich weit oben stand, dachte ich mir das ich mal die lösung dazu gebe:

 

Also um mein prob genauer zu definieren , passierte folgendes. Der 2. DC wurde ohne weitere probs zum PDC. Schon gefreut das diesmal alles so reibungslos lief. Als ich dann einen Testuser angelegt hab und ihm den haken gesetzt hab er soll sein Kennwort beim nächsten anmelden ändern, ich den User dann zum testen anmeldete erschien folgende Meldung: Sie haben keine Berechtigung ihr Kennwort zu ändern. Das witzige war wenn ich den user im AD die Option gegeben hab das er kein PW ändern brauch und ihn dann anmelden konnte, konnte er ohne probs mit strg+alt+entf sein PW ändern.

 

Da ich in einem sehr grossen Unternehmen tätig bin wollte ich aber das alle ihr kennwort bei der ersten anmeldung gleich ändern. Allerdings bereitete mir oben beschriebene Fehlermeldung schlaflose nächte.

 

Lange Rede kurzer Sinn. Was mir klar war ist das der "Neue" USer sein gpo wohl erst bezieht wenn er sich einmal angemeldet hat und dann pws ändern kann/darf, aber warum nicht vorher?

 

Lösung: Ist die Option <Kennwort bei nächster Anmeldung ändern> aktiviert. Verhindert die Keberos-Authentifizierung die Änderung des Kennworts durch den Benutzer. Ferner wird im Ereignisprotokoll der Anmelderechner nicht angezeigt.

 

Also: in der Sicherheitsrichtlinie von Domainencontrollern/ Windows Einstellungen/ Sicherheitseinstellungen/ Lokale Richtlinien/ Zuweisen von Benutzerrechten/ Auf diesen Computer vom Netzwerk aus zugreifen Domänen Computer und Domänen Benutzer hinzufügen. :D

[XP-Fan 215]

Hallo und herzlich Willkommen,

 

vielen Dank für die ausführliche Beschreibung der Lösung deines Problems.

 

Der ursprüngliche Beitrag ist schon "etwas" älter und dürfte gelöst worden sein. :D