Bug 18825 - disabled / locked Verhalten vereinheitlichen
disabled / locked Verhalten vereinheitlichen
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 2.3
Other Linux
: P5 enhancement (vote)
: UCS 2.4
Assigned To: Stefan Gohmann
Philipp Hahn
:
Depends on: 18750 18838 18840
Blocks: 18776 18835 18836 18837 19100 19888
  Show dependency treegraph
 
Reported: 2010-06-29 14:21 CEST by Stefan Gohmann
Modified: 2017-04-26 11:24 CEST (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2010-06-29 14:21:51 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.
Comment 1 Stefan Gohmann univentionstaff 2010-06-29 15:30:36 CEST
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.
Comment 2 Stefan Gohmann univentionstaff 2010-06-29 15:36:52 CEST
(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.
Comment 3 Stefan Gohmann univentionstaff 2010-06-30 09:05:24 CEST
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.
Comment 4 Philipp Hahn univentionstaff 2010-07-05 19:12:35 CEST
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}).
Comment 5 Stefan Gohmann univentionstaff 2010-07-28 08:04:15 CEST
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.
Comment 6 Philipp Hahn univentionstaff 2010-08-19 11:21:22 CEST
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."
Comment 7 Stefan Gohmann univentionstaff 2010-08-19 12:11:10 CEST
(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}).
Comment 8 Philipp Hahn univentionstaff 2010-08-19 12:22:33 CEST
Okay.
Comment 9 Stefan Gohmann univentionstaff 2010-08-31 13:22:06 CEST
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".