Univention Bugzilla – Bug 18685
Standard-Gruppe für Helpdesk-Aufgabe "Passwort zurücksetzen"
Last modified: 2022-11-10 14:29:56 CET
Es sollte eine Standard-Gruppe in UCS geben die die Berechtigung erhält Benutzerpasswörter zurückzusetzen (keine Benutzer anlegen, keine Gruppenmigliedschaften ändern, keine Rechnerkonten ändern). Dazu gehören dann auch Passwort-Attribute von Benutzerobjekten wie Abblaufdaten etc.. siehe Ticket 2010051010000631 Implementierungs-Idee: - Paket univention-xxx erstellen - ACLs definieren - Postinst: Variable für Gruppenname setzen, die Passwortänderungen durchführen darf - Join-Script: UDM-Ansicht konfigurieren - Join-Script: Gruppe anlegen, die Passwortänderungen durchführen darf
Implementierungsidee weitgehend aufgegeriffen: - Joinskript legt Benutzergruppe "User Password Admins" in cn=groups,$ldap_base an. - Joinskript legt UDM-Ansicht cn=default-user-password-admins in cn=admin-settings,cn=users,cn=policies,$ldap_base an. Die Ansicht schaltet den Benutzerwizard frei, so dass der jeweilige Benutzer alle anderen Benutzer und deren Attribute "sehen" kann. Modifiziert werden können aber nur die per ACL freigebenen Attribute. - Die Attribute, die geschrieben werden können, sind in der UCR-Variable ldap/acl/user/attributes/list definiert. Fehlt die UCR-Variable, fällt das Template auf den Default zurück. Die angegebenen Attribute beziehen sich ausschließlich auf Benutzerattribute. - Gruppen, die die angegebenen Benutzerattributen modifizieren dürfen, sind in den UCR-Variablen ldap/acl/user/attributes/accesslist/groups/$KEY angegeben. Als default wird bei der Installation: ldap/acl/user/attributes/accesslist/groups/1="cn=User Password Admins, cn=groups,$ldap_base" gesetzt. Ist keine Gruppe definiert, wird der ACLs-Satz aus der slapd.conf automatisch entfernt. - Um bestimmte Benutzer (z.B. Administrator) davor zu schützen, durch die Benutzer der Gruppe "User Password Admins" ein neues Passwort zu erhalten, können in der UCR-Variable ldap/acl/user/attributes/protected/uid kommasepariert UIDs angegeben werden, auf die die Gruppe kein Schreibzugriff im LDAP erhält. Default: ldap/acl/user/attributes/protected/uid=Administrator
Die UCR-Variablen wurden umbenannt. Funktion bleibt erhalten. Bei der Installation werden jetzt folgende UCR-Variablen gesetzt: ldap/acl/user/passwordreset/accesslist/groups/dn?\ "cn=User Password Admins,cn=groups,$ldap_base" ldap/acl/user/passwordreset/attributes?\ "krb5Key,userPassword,sambaPwdCanChange,sambaPwdMustChange,sambaLMPassword,sambaNTPassword,sambaPwdLastSet,pwhistory,sambaPasswordHistory,krb5KDCFlags,krb5KeyVersionNumber,krb5PasswordEnd,shadowMax,shadowLastChange" ldap/acl/user/passwordreset/protected/uid?"Administrator" ucs-test-Skript scripts-10_ldap/63univention-admingrp-user-passwordreset wurde hinzugefügt. Das Skript legt zwei Gruppen mit jeweils einem Benutzer an sowie zwei weitere Benutzer (einer wird später als protected eingetragen) und testet folgende Punkte: Es wird die erste Gruppe als Helpdesk-Gruppe in ldap/acl/user/passwordreset/accesslist/groups/dn eingetragen; protected User: Administrator, zweiter Zusatzbenutzer (kurz Protected-User). 1) kann Administrator weiterhin das Passwort von Helpdesk-User, Protected-User und Unprotected-User setzen? 2) kann der Helpdesk-User das PW des Unprotected-User resetten? 3) kann der Helpdesk-User nicht das PW des Protected-User und von Administrator resetten? Es wird zusätzlich die zweite Gruppe als Helpdesk-Gruppe eingetragen. 4) funktionieren die Tests 2) und 3) noch? 5) funktionieren die Tests 2) und 3) auch mit der zweiten Helpdesk-Gruppe und dem zugehörigen Benutzer? 6) kann der Helpdesk-Benutzer NICHT die Beschreibung des Unprotected-Users ändern? Es wird zusätzlich das Attribut "description" über die UCR-Variable ldap/acl/user/passwordreset/attributes für Änderungen freigegeben. 7) kann der Helpdesk-Benutzer jetzt die Beschreibung des Unprotected-Users ändern? 8) kann Unprotected-User die Beschreibung oder ein Passwort der Helpdesk-User oder vom Admin ändern?
Changelog-Eintrag ist vorhanden. Paket univention-admingrp-user-passwordreset wurde importiert und gebaut.
Das ucs-test-Skript sollte auch mit PW-Ablaufrichtlinien testen.
Das ucs-test-Skript testet jetzt auch mit einem abgelaufenen Passwort sowie einer PW-Ablauf-Richtlinie.
Ergänzung: die UDM-Admin-Ansicht-Richtlinie wird nicht automatisch mit Benutzern oder einem Container verknüpft. Dies muss manuell erfolgen.
Reopen: Gruppen-in-Gruppen-Berechtigungen funktionieren nicht. Das ucs-test-Skript entfernt die UCR-Variable ldap/acl/user/passwordreset/accesslist/groups/dn
Ergänzung: Bei der Installation des Pakets wird die UCR-Variable ldap/acl/user/passwordreset/accesslist/groups/dn auf die DN der Helpdesk-Gruppe gesetzt. Diese UCR-Variable ist auch dokumentiert. Das Template wertet aber alle UCR-Variablen mit dem Prefix "ldap/acl/user/passwordreset/accesslist/groups/" aus und schreibt diese in die LDAP-ACLs. Bei mehreren Gruppen muss dann pro Gruppe ein eindeutiger UCR-Key verwendet werden, z.B. ldap/acl/user/passwordreset/accesslist/groups/1=..., ldap/acl/user/passwordreset/accesslist/groups/2=... Die Art des UCR-Keys (1,2,dn,foo,test,...) ist egal. Diese Variablen werden unsortiert in die LDAP-ACLs aufgenommen, was auf die Funktion keine negativen Auswirkungen hat. Aufgrund der Komplexität für den Admin wurde die Dokumentation auf die Angabe einer Gruppe beschränkt. ucs-test prüft mit bis zu zwei Gruppen.
(In reply to comment #7) > Reopen: Gruppen-in-Gruppen-Berechtigungen funktionieren nicht. Fixed. Gruppen in Gruppen sollten jetzt funktionieren, wenn ldap/acl/nestedgroups=yes gesetzt ist. > Das ucs-test-Skript entfernt die UCR-Variable > ldap/acl/user/passwordreset/accesslist/groups/dn Fixed. Zusätzliche ucs-test-Skripte wurden eingecheckt.
(In reply to comment #9) > (In reply to comment #7) > > Reopen: Gruppen-in-Gruppen-Berechtigungen funktionieren nicht. > > Fixed. Gruppen in Gruppen sollten jetzt funktionieren, wenn > ldap/acl/nestedgroups=yes gesetzt ist. Funktioniert > > Das ucs-test-Skript entfernt die UCR-Variable > > ldap/acl/user/passwordreset/accesslist/groups/dn > > Fixed. Stimmt > Zusätzliche ucs-test-Skripte wurden eingecheckt. Sehen gut aus - laufen durch Verified
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".