Bei einem meiner Kunden besteht das Problem, dass eine Reihe (scheinbar) zufälliger Benutzer ihr Passwort aufgrund von "Komplexität bla bla" nicht ändern können. Dies ist jedoch nicht der Fall, wenn:
a) Ein Administrator setzt sein Passwort auf ein neues zurück oder
b) der Benutzer hatte das Flag „Passwort muss bei der Anmeldung zurückgesetzt werden“
Was ich bisher versucht habe:
GPOs: Es gibt nur die Standarddomänenrichtlinie mit Kennworteinstellungen. Die Einstellungen sind:
- Länge von 10
- Komplexität aktiviert
- Verlauf ist auf 5 eingestellt, aber in diesem Fall irrelevant (habe verschiedene Passwörter ausprobiert)
- Alles andere ist undefiniert oder 0
Passwortanbieter auf PDC: Ich habe gelesen, dass Sie über die Registrierung benutzerdefinierte Passwortanbieter verwenden können. Ich habe es mit einer Domäne überprüft, bei der alles funktioniert. Es scheint Standard zu sein. Das Einzige, was ich gesehen habe, war die Einstellung
EveryoneIncludesAnonymous = 0.Der Benutzer konnte sein Passwort immer noch nicht ändern, nachdem ich ein PSO für ihn erstellt hatte, mit einer Konfiguration, die funktionieren sollte. Es schien, als wären sie nicht angewendet worden.
PDC ist verfügbar
Set-ADAccountPasswordauf einem Domänencontroller hat auch nicht funktioniert.Die Sicherheitsbeschreibung des Benutzerkontos sieht ganz ok aus. Jeder hat das Recht, das Passwort zu ändern.
In ADUC sind die Benutzereigenschaften ok. Benutzer kann Passwort = $false usw. nicht ändern.
Ausgabe vonnet user /domain Myuser
User name cardm004
Full Name Cardman, Michael
Comment Test User
User's comment
Country/region code 000 (System Default)
Account active Yes
Account expires Never
Password last set 16.01.2017 13:14:58
Password expires Never
Password changeable 15.02.2017 13:14:58
Password required Yes
User may change password Yes
Workstations allowed All
Logon script login.cmd
User profile
Home directory
Last logon 18.01.2017 08:14:01
Logon hours allowed All
Local Group Memberships
Global Group memberships *Domain Users
The command completed successfully.
Ausgabe vonnet accounts
Force user logoff how long after time expires?: Never
Minimum password age (days): 0
Maximum password age (days): 37201
Minimum password length: 10
Length of password history maintained: 5
Lockout threshold: Never
Lockout duration (minutes): 30
Lockout observation window (minutes): 30
Computer role: Workstation
Jetzt habe ich keine Ideen mehr. Was könnte ich versuchen, um herauszufinden, warum die Benutzer ihre Passwörter nicht ändern können?
Aktualisieren
Ich habe festgestellt, dass die Gruppenrichtlinienmodellierung für verschiedene Benutzer unterschiedliche Konfigurationen anzeigt. Die Teile „Kennworteinstellungen“ und „Kontosperrungsrichtlinie“ werden für Benutzer, die ihre Kennwörter nicht ändern können, nicht angezeigt. Daher gehe ich davon aus, dass möglicherweise ein Replikationsproblem auf den Domänencontrollern vorliegt. Ich habe den Replikationsstatus überprüft repadmin /showreplund die Ergebnisse waren in Ordnung. Ich habe den Dateiinhalt in Sysvol auf allen drei Domänencontrollern überprüft und er war identisch. Die DCs sind also irgendwie auf dem neuesten Stand, aber die Computer erhalten die Konfiguration nicht.
GPUpdate /forceund GPResult /r, oder GPResult /h file.htmlsehen gut aus und zeigen keine Fehler an. Neustart nach GPUpdate /forcehat den Fehler nicht geändert.
GPResult /rzeigt die richtige Site an und zeigt eine schnelle Verbindung an, Default Domain Policy(wo die Einstellungen vorgenommen werden) wird als angewendet angezeigt.
Aktualisierung 2
Ich habe ein zusätzliches GPO erstellt, um die Kennworteinstellungen festzulegen. Dazu habe ich eine OU erstellt, in die ich den Computer und das Benutzerkonto verschoben habe, und dieses GPO mit enforced = $truedieser OU verknüpft. GPResult /hzeigt die korrekte angewendete Konfiguration, Net user /domain testusertut es aber nicht. Die lokalen Richtlinieneinstellungen sind identisch mit dem GPO.
Das Problem besteht weiterhin.
Aktualisierung 3
Der Kunde hat ein Ticket bei Microsoft eröffnet. Sie haben noch keine Lösung, haben aber herausgefunden, dass es ein Problem mit GP zu geben scheint: Der Benutzer und sein Gerät wurden zum Testen in eine separate OU verschoben, wobei die Vererbung deaktiviert war. Sie haben eine neue GPO mit mehreren Kennworteinstellungen darauf angewendet. GPResultzeigte die aktualisierten Einstellungen, aber der Benutzer konnte sein Kennwort immer noch nicht ändern.
Anschließend wurde die GP-Verknüpfung entfernt und die Vererbung wieder aktiviert, die Einstellungen der Test-GPO blieben auf dem System. Die Einstellungen vonStandarddomänenrichtliniewurden nicht angewendet (sie waren niedriger als in der Test-GPO) und der Benutzer konnte sein Kennwort trotzdem nicht ändern.
Ich halte Sie auf dem Laufenden. Vielleicht stößt einer von Ihnen eines Tages auf dieses Problem oder findet eine Lösung, bevor Microsoft dies tut.
Antwort1
Wenn ich mich richtig erinnere, handelt es sich bei diesem Fehler um einen allgemeinen Fehler bei allen Problemen mit Kennwortänderungen.
Basierend auf Ihrem Kommentar:
Dies trifft jedoch nicht zu, wenn:
a) Ein Administrator setzt sein Passwort auf ein neues zurück oder
b) der Benutzer hatte das Flag "muss Passwort bei Anmeldung zurücksetzen"
Ich würde sagen, das Problem liegt darin, dass Ihre Kennwortrichtlinie eine Einstellung für entweder Minimum Password Ageoder Enforce Password Historyoder beides hat. Wahrscheinlich ist hier die erste der Übeltäter.
BEARBEITEN:
Basierend auf Ihrem letzten Update können Sie Folgendes sehen:
Password changeable 15.02.2017 13:14:58
Darin ist angegeben, dass das Passwort 30 Tage lang nicht geändert werden kann.
Sie haben angegeben, dass Ihr Mindestalter für Passwörter auf 0 eingestellt ist.
Das führt mich zu zwei möglichen Schlussfolgerungen:
Entweder die Konten oder die Organisationseinheiten blockieren die Übernahme der Richtlinie. Obwohl die richtige Richtlinie mit „Nettokonten“ angezeigt wird, scheint sie auf den jeweiligen Benutzer nicht angewendet zu werden.
Es gibt einige DCs, die die Vererbung blockieren und nicht die richtigen Einstellungen erhalten. Siehe hier:https://community.spiceworks.com/topic/1838052-minimum-password-age-password-changeable
Überprüfen Sie, dass in GPMC keine GPO-Blockierung erfolgt. Überprüfen Sie dann, ob der DC, bei dem sich der Benutzer authentifiziert, zusammen mit seinem Computer und seinem Benutzerkonto ... alle drei über „Vererbbare Berechtigungen vom übergeordneten Objekt dieses Objekts einschließen“ verfügen.
Antwort2
Ihre Ausgabe des net user /domain MyuserBefehls spiegelt derzeit ein Mindestalter für Passwörter von 31 Tagen wider. Es sieht so aus, als müssten SieÄndern Sie Ihr PSO für diesen Benutzer und setzen Sie das Mindestalter für Passwörter in diesem Objekt auf 0.
Haben Sie außerdem bestätigt, dass das PSO erfolgreich auf den Benutzer oder die Gruppe angewendet wurde? Wenn dies der Fall ist, sollte msDS-ResultantPSOim AD-Konto des Benutzers ein Attribut angezeigt werden. Sie können dies ganz einfach mit ADUC auf der Registerkarte „Attribute“ oder durch Ausführen der folgenden PowerShell-Befehle überprüfen:
Import-Module ActiveDirectory
Get-ADUser cardm004 -Properties msDS-ResultantPSO | FL
Nebenbei bemerkt, das Ausführen net accountswird die Einstellungen fürLokale Computerkonten. Lokale Kontoeinstellungen werden getrennt von den Domänenkontoeinstellungen konfiguriert.
Antwort3
Blöder Vorschlag, aber haben Sie überprüft, ob das Passwort des Benutzers die Anforderungen erfüllt:
- Passwörter dürfen nicht die vollständige Benutzerkennung enthalten.samAccountName(Kontoname)-Wert oder ganzerAnzeigename(Vollständiger Name)-Wert. Bei beiden Prüfungen wird nicht zwischen Groß- und Kleinschreibung unterschieden:
- DersamAccountNamewird nur in seiner Gesamtheit geprüft, um festzustellen, ob es Teil des Passwortes ist. Wenn dassamAccountNameweniger als drei Zeichen lang ist, wird diese Prüfung übersprungen.
- DerAnzeigenamewird nach Trennzeichen durchsucht: Kommas, Punkte, Bindestriche, Unterstriche, Leerzeichen, Rautenzeichen und Tabulatoren. Wenn eines dieser Trennzeichen gefunden wird,Anzeigenamewird aufgeteilt und es wird bestätigt, dass alle analysierten Abschnitte (Token) nicht im Kennwort enthalten sind. Token mit einer Länge von weniger als drei Zeichen werden ignoriert und Teilzeichenfolgen der Token werden nicht überprüft. Beispielsweise wird der Name „Erin M. Hagens“ in drei Token aufgeteilt: „Erin“, „M“ und „Hagens“. Da das zweite Token nur ein Zeichen lang ist, wird es ignoriert. Daher kann dieser Benutzer kein Kennwort haben, das an einer beliebigen Stelle im Kennwort entweder „erin“ oder „hagens“ als Teilzeichenfolge enthält.
- Passwörter müssen Zeichen aus drei der folgenden fünf Kategorien enthalten:
- Großbuchstaben europäischer Sprachen ( Abis Z, mit diakritischen Zeichen, griechische und kyrillische Zeichen)
- Kleinbuchstaben europäischer Sprachen ( abis z, scharfes-s, mit diakritischen Zeichen, griechische und kyrillische Zeichen)
- Ziffern zur Basis 10 ( 0bis 9)
- Nicht alphanumerische Zeichen:~!@#$%^&*_-+=`|\(){}[]:;"',.?/
- Jedes Unicode-Zeichen, das als alphabetisches Zeichen kategorisiert ist, aber weder Groß- noch Kleinbuchstaben sind. Dazu gehören Unicode-Zeichen aus asiatischen Sprachen.
Entsprechend:https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx
Antwort4
Ehrlich gesagt klingt das so, als würden Sie über lokale GPO-Änderungen auf eine sekundäre Produkteinstellungsrichtlinie stoßen. So etwas wie ScriptLogic (auch bekannt als Desktop Authority).
Auf älteren PCs können unter anderem folgende Symptome auftreten:
- Vorhandensein von SLStart oder wKiX32 auf dem PC in System32 oder im Stammverzeichnis von C:.
- Wenn es vorher dort vorhanden war und entfernt wurde, werden Sie feststellen, dass alle vorher auf den PCs installierten Programme nicht unter „Programme hinzufügen/entfernen“ angezeigt werden.
Es ist... ein paar Jahre her. Irgendeine Idee, was letztendlich die Lösung war?