Univention Bugzilla – Bug 18825
disabled / locked Verhalten vereinheitlichen
Last modified: 2017-04-26 11:24:02 CEST
Derzeit ist es nicht wirklich ersichtlich, wo der Unterschied zwischen deaktiviert und gesperrt ist. Gesperrt wurde derzeit nur unter Samba ausgewertet. Das ! im Benutzerpasswort wurde im UDM als deaktiviert gezählt. Aus den Checkboxen deaktiviert und gesperrt sollten zwei Drop-Downs im UDM erstellt werden: * Deaktiviert: + Benutzer ist nicht deaktiviert + Benutzer ist vollständig deaktiviert + Benutzer ist nur unter Windows deaktiviert + Benutzer ist nur unter Linux deaktiviert * Gesperrt + Benutzer ist nicht gesperrt + Benutzer ist vollständig gesperrt + Benutzer ist nur unter Windows gesperrt + Benutzer ist nur unter Linux gesperrt Dadurch sind leider nicht alle Fälle abgebildet, bspw. nur Kerberos / Windows deaktiviert, aber ich halte das für sehr selten. Wenn die Kombinationen auch mit aufgenommen werden, dann würde das unübersichtlich werden +++ This bug was initially created as a clone of Bug #18750 +++ Pro UCS-System sollte konfiguriert werden können, nach wie viel erfolglosen Anmeldeversuchen der Benutzer gesperrt wird.
Das Drop-Down für disabled sollte zunächst als Checkbox bestehen bleiben. Problem ist, dass ein disabled auf POSIX-Ebene nur über das Kontoablaufdatum konfiguriert wird. Wir haben die unterschiedlichen Werte für das deaktivieren: - sambaKickoffTime - D in sambaAccountFlag - krb5ValidEnd - shadowExpire Die Checkbox sollte nur anzeigen, ob der Account deaktiviert ist. Wenn die Checkbox aktiviert wird, dann sollte ein Datum in der Vergangenheit gesetzt sein oder gesetzt werden, damit der Account wirklich überall deaktiviert ist. Wenn die Checkbox wieder deaktiviert wird, dann sollten die Datumswerte, sofern sie in der Vergangenheit liegen wieder entfernt werden, ebenso das D in den Samba Account Flags.
(In reply to comment #1) > Das Drop-Down für disabled sollte zunächst als Checkbox bestehen bleiben. > Problem ist, dass ein disabled auf POSIX-Ebene nur über das Kontoablaufdatum > konfiguriert wird. > > Wir haben die unterschiedlichen Werte für das deaktivieren: > - sambaKickoffTime > - D in sambaAccountFlag > - krb5ValidEnd > - shadowExpire - krb5KDCFlags auf 256 > Die Checkbox sollte nur anzeigen, ob der Account deaktiviert ist. Wenn die > Checkbox aktiviert wird, dann sollte ein Datum in der Vergangenheit gesetzt > sein oder gesetzt werden, damit der Account wirklich überall deaktiviert ist. > Wenn die Checkbox wieder deaktiviert wird, dann sollten die Datumswerte, sofern > sie in der Vergangenheit liegen wieder entfernt werden, ebenso das D in den > Samba Account Flags.
Es ist jetzt so umgesetzt, dass es zwei Drop-Downs gibt. Das Gesperrt-Flag kann für die folgenden Kombinationen gesetzt werden: - all - none - windows - posix Bei posix wird das ! im userPassword gesetzt, bei windows wird das L in den AccountFlags gesetzt. Das Deaktivieren ist etwas umfangreicher, hier gibt es die folgenden möglichen Werte: - all - none - windows - posix - kerberos - windows_kerberos - windows_posix - posix_kerberos Das ist insgesamt etwas aufwendiger, allerdings hat der Administrator so die Auswahl. Unter all und none ist in der Auswahlliste ein Strich, damit sollten die wichtigen Funktionen direkt ansprechbar sein. Das Deaktivieren über Posix wird über das LDAP-Attribut shadowExpire=1 abgebildet. Die Bezeichnungen finde ich nicht ganz glücklich, wenn es besser Vorschläge gibt, dann den Bug bitte wieder öffnen.
Implementierung wurde auf i386(2.3->2.4), i386(2.4) und amd64(2.3->2.4) überprüft. Zusätzlich wurden die Auswirkungen auf ein Windows-XP getestet: Implementierung tut soweit. Unschön sind die durch unsere PAM-Konfiguration vorhandenen Abhängigkeiten zwischen den Methoden: 1. Da "required [acct_expired=bad] pam_unix.so" in "/etc/pam.d/common-account" steht, führt ein Deaktivieren von POSIX auch zum deaktivieren von Samba, weshalb dann das $HOME- und $NETLOGON-Share nicht mehr zur Verfügung stehen. 2. Heimdal-Kerberos überprüft selbst auch die "sambaAcctFlags" <lib/hdb/hdb-ldap.c>, weshalb ein Deaktivieren von Windows auch Kerberos deaktiviert. Das muß auf jeden Fall dokumentiert werden, siehe dazu Bug #18836 Comment 1. ChangeLog-Eintrag ist vorhanden: \item Im Benutzermodul wurden die Checkboxen für \ucsName{Deaktiviert} und \ucsName{Gesperrt} in Auswahllisten umgewandelt. Hier besteht nun eine umfangreichere Auswahl der einzelnen Zustände (\ucsBug{18825}).
Ich habe noch eine Änderung in diesem Bereich vorgenommen. univention-passwd (das wird von Samba beim Ändern des Passworts unter Windows aufgerufen) löscht jetzt nicht mehr den disabled-Status beim Setzen des Passworts.
Derzeit sind folgende UCR-Variablen standardmäßig gesetzt: auth/admin/methods: krb5 ldap unix auth/user/methods: krb5 ldap unix Da führt dazu, daß selbst bei gesperrtem "Nur POSIX/LDAP gesperrt"-Anmeldeverfahren die Anmeldung trotzdem noch möglich ist. Erst wenn man "krb5" entfernt, wird die Anmeldung unter UCS verhindert. Auch hier fehlt es noch an Dokumentation; siehe Bug #18836. (In reply to comment #5) > Ich habe noch eine Änderung in diesem Bereich vorgenommen. univention-passwd > (das wird von Samba beim Ändern des Passworts unter Windows aufgerufen) löscht > jetzt nicht mehr den disabled-Status beim Setzen des Passworts. Ich kann nicht ganz überblicken, in wie weit das ggf. negative Auswirkungen auf bisheriges erwartetes Verhalten hat. Deshalb sollte das IMHO im ChangeLog noch erwähnt werden: "Änderungen des Passworts durch Samba führen nicht länger dazu, daß das Benutzerkonto aktiviert wird; dies muß gesondert durch ... erfolgen."
(In reply to comment #6) > Derzeit sind folgende UCR-Variablen standardmäßig gesetzt: > auth/admin/methods: krb5 ldap unix > auth/user/methods: krb5 ldap unix > Da führt dazu, daß selbst bei gesperrtem "Nur POSIX/LDAP > gesperrt"-Anmeldeverfahren die Anmeldung trotzdem noch möglich ist. Erst wenn > man "krb5" entfernt, wird die Anmeldung unter UCS verhindert. > Ja, allerdings ist alles besser als vorher, wo es nur zwei Zustände gab, die fast nie richtig sein konnten. > Auch hier fehlt es noch an Dokumentation; siehe Bug #18836. > > (In reply to comment #5) > > Ich habe noch eine Änderung in diesem Bereich vorgenommen. univention-passwd > > (das wird von Samba beim Ändern des Passworts unter Windows aufgerufen) löscht > > jetzt nicht mehr den disabled-Status beim Setzen des Passworts. > > Ich kann nicht ganz überblicken, in wie weit das ggf. negative Auswirkungen auf > bisheriges erwartetes Verhalten hat. Deshalb sollte das IMHO im ChangeLog noch > erwähnt werden: > "Änderungen des Passworts durch Samba führen nicht länger dazu, daß das > Benutzerkonto aktiviert wird; dies muß gesondert durch ... erfolgen." Der Changelog Eintrag ist nochmal angepasst: \item Im Benutzermodul wurden die Checkboxen für \ucsName{Deaktiviert} und \ucsName{Gesperrt} in Auswahllisten umgewandelt. Hier besteht nun eine umfangreichere Auswahl der einzelnen Zustände. Zu beachten ist, dass eine gegenseitige Verbindung der einzelnen Zustände besteht, wenn beispielsweise das Konto für LDAP/POSIX deaktiviert wird, so ist eine Windows Anmeldung nicht möglich, da hierfür ein gültiger LDAP/POSIX"=Account benötigt wird (\ucsBug{18825}).
Okay.
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".