„Benutzer kann Passwort nicht ändern“-Option auf Abwegen

Neulich rief ein Kollege bei mir an und berichtete mir, dass einige Benutzer ihre Domänenpasswörter nicht mehr ändern konnten. Sie erhielten folgende Fehlermeldung:

Da es in den Benutzerkontenoptionen eine Checkbox namens „Benutzer kann Passwort nicht ändern“ gibt, die ein Verändern des Benutzerpasswords durch den Benutzer selbst verhindert, schloss ich darauf, dass das Problem dort liegen könnte. Doch die Checkbox war nicht aktiviert, wie mir mein Kollege versicherte.

Obwohl wir beide etwas ratlos waren, fand mein Kollege zumindest einen Workaround für das Problem: er aktivierte die Checkbox „Benutzer kann Passwort nicht ändern“, übernahm die Änderung am Benutzerkonto, löschte die Checkbox wieder und übernahm die Änderung erneut. Das half ihm sicherzustellen, dass die Benutzer ihre Passworte wieder ändern konnten.

Da das sicherlich kein Dauerzustand sein konnte und wir den wahren Grund für das Problem herausfinden wollten, haben wir uns weiterhin bemüht, die Ursache des Problems zu finden. Wir sprachen über mögliche Faktoren, die das Problem hätten hervorrufen können und nahmen uns einige Skripte zur Brust, die zur Verwaltung und Provisionierung von Benutzern verwandt wurden. In der Tat wurden wir fündig: der Kunde setzte ein Skript ein, das Benutzerkonten für Kurzzeitmitarbeiter anlegte. Hierbei wurde ein festes Passwort vergeben, das nach dem maximalen Kennwortalter, das in der Passwortrichtlinie vorgegeben ist, abläuft. Die Benutzer müssen dann zu ihrem Manager und das Passwort entweder verlängern lassen oder die Firma verlassen 😉 Zugegeben, diese Methode ist nicht gerade die Beste, zumal es ja die „Konto läuft ab:“-Option in den Konteneinstellungen gibt und extra hierfür entwickelt wurde.

Das eigentliche Problem war folgendes: das Skript machte keine gute Arbeit beim Verbieten der Kennwortänderung durch den Benutzer, denn es löschte einfach zwei Standardberechtigungen aus der Berechtigungsliste des Benutzerobjektes:

Das scheint erst mal kein Problem zu sein, denn schließlich tut das Skript das, für was es bezahlt wird. Schlecht nur, dass „Active Directory Benutzer und Computer“ diese Methode nicht kennt und dementsprechend auch die Checkbox zu „Benutzer kann Kennwort nicht ändern“ anzeigt. Was „Active Directory Benutzer und Computer“ erwartet – und was es selbst auch verändert, wenn die Checkbox aktiviert wird – ist, dass das Recht „Change Password“ für die „Jeder“ (Everyone) und „Selbst“ (Self)-Autoritäten verweigert wird. Diese beiden Einträge werden zur Berechtigungsliste hinzugefügt und – sollte die Checkbox wieder gelöscht werden, entfernt. Zusätzlich zum Entfernen der „verweigern“-Berechtigungen werden die im Bild markierten Berechtigungen „Change Password“ für „Jeder“ und „Selbst“ zur Liste hinzugefügt. Das ist auch der Grund, warum der Workaround meines Kollegen funktioniert hat.

Und die Moral von der Geschicht? Wenn du wilde Skripte schreiben möchtest, schau doch mal nach, ob’s die Funktionalität nicht schon fertig gibt. Falls es sie schon fertig gibt, schau doch auch gleich noch nach, wie die Fertiglösung „hinter den Kulissen“ funktioniert – das erspart Ärger mit der Checkbox.