Univention Bugzilla – Bug 18839
disabled / locked Verhalten vereinheitlichen
Last modified: 2015-04-01 13:47:44 CEST
Das sollte in der Dokumentation angepasst werden. Gehört zu Ticket #2010042110000648. +++ This bug was initially created as a clone of Bug #18825 +++ 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.
Siehe auch Bug #19567, es wäre gut, wenn in der Dokumentation steht, dass man sowohl disabled als auch locked setzen sollte, wenn man einen Benutzer für alles sperren/deaktivieren will. Beispielweise ignoriert ein LDAP-Bind das Flag deaktiviert, nicht aber das Gesperrt-Flag.
Die Dokumentation der neuen Zustände wurde in das UDM-Kapitel im Benutzer-Konto-Reiter eingepflegt. Die Hinweise aus https://forge.univention.org/bugzilla/show_bug.cgi?id=18836#c7 wurden in den Abschnitt "PAM/Autentifizierung" im Basisdienste-Kapitel eingearbeitet. Die Übersetzung fehlt noch.
Die Übersetzung wurde eingepflegt.
Hinweise im Ausdruck
Änderungen wurden eingepflegt.
Diese Kommentare sind an den falschen Bug geschrieben worden (Bug #18836): (In reply to comment #1) > Anmerkungen für die Dokumentation: > > 1. Da unsere PAM-Konfiguration für die Authentifizierung (pam_unix ODER pam_krb > ODER pam_ldap) zulässt, wird der Linux-Login nur deaktiviert, falls "ALLE" > Anmeldeverfahren deaktiviert werden; POSIX/LDAP reicht dazu nicht aus (Siehe > Bug #18750 Comment 7) > > 2. Andererseits setzt unser Samba ein nicht-abgelaufenes UNIX-Konto voraus > (pam_unix[valid] UND (pam_unix ODER pam_ldap ODER pam_krb)). D.h. durch > deaktivieren des POSIX-Accounts wird auch Samba deaktiviert. > > 3. Da Heimdal selber auch auch die "sambaAcctFlags" auswertet, führt ein > deaktivieren des Windows-Accounts auch zum deaktivieren des Kerberos-Accounts. > > 4. Globales Sperren funktioniert nur auf einem Master oder Backup, da aller > anderen Rechner sich nur per "machine.secret" authentifizieren und dadurch > nicht die benötigten Rechte haben, bei dem Benutzer das 'locked'-Attribut auf > 'all' zu setzen. Davon unabhängig wird der Benutzer aber lokal gesperrt bzw. > durch das Listener-Modul auch wieder entsperrt. (In reply to comment #6) > Ich habe den Changelog Eintrag 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}). > > @Moritz, ich habe noch nicht gesehen, wie der Status der Dokumentation ist. > Wenn noch nicht geschehen, dann sollte kurz auf die Wechselwirkung eingegangen > werden. (In reply to comment #7) > Versuch einer Erklärung zum Thema Authentifizierung und Kontoverwaltung: > > In der PAM-Konfiguration von UCS können verschiedene Verfahren für die > Authentifizierung von Benutzerkonten verwendet werden: "unix" überprüft das > verschleierte Passwort anhand der Datei /etc/shadow, "ldap" führt einen > BIND-Versuch beim LDAP-Server durch und "krb5" überprüft das das Passwort > anhand eines gemeinsamen Geheimnisses, daß ebenfalls im LDAP gespeichert wird. > Daneben gibt es noch weitere Verfahren, z.B. verwendet die Secure Shell (ssh) > ein Schlüsselpaar zur Überprüfung, ob der Benutzer tatsächlich der Benutzer > ist, den er vorgibt zu ein. > In UCS reicht es normalerweise aus, wenn die Identität anhand eines dieser > Verfahren überprüft werden kann. Welche Verfahren verwendet werden sollen, kann > über die UCR-Variable "auth/admin/methods" für den Administrator und über > "auth/user/methods" für alle anderen Benutzer konfiguriert werden. > Standardeinstellung ist "krb5 ldap unix", was alle drei Verfahren erlaubt. > > Neben dieser Überprüfung benötigen einige Dienste zusätzlich ein gültiges > Benutzerkonto: Dieses ordnet einem Benutzer sein $HOME-Verzeichnis, seine > numerische Benutzerkennung sowie die Gruppen zu, zu denen er Zugang erhalten > soll. Diese Informationen werden u.A. bei der Anmeldung auf der grafischen > Benutzungsoberfläche, auf der Textkonsole oder per ssh benötigt. Aber auch > Samba benötigt diese Informationen, um vom Benutzer abgelegte Informationen auf > dem UNIX-Dateisystem speichern zu können oder um zu überprüfen, ob der Zugriff > auf Dateien und Verzeichnisse erlaubt ist. > Daneben enthalten die Kontodaten aber auch noch Zusatzinformationen, z.B. zum > Alter des Passworts, ob das Konto deaktiviert ist oder ob das Konto nur auf > bestimmten Rechnern gültig sein soll. > Auch hier werden über PAM verschiedene Verfahren genutzt, die sich teilweise > ergänzen und einschränken: > "unix" verwendet die Informationen aus /etc/passwd, /etc/group, /etc/shadow > sowie /etc/nsswitch.conf, über die weitere Informationsquellen eingebunden > werden können. Über letzteres werden in UCS auch alle Benutzer aus dem LDAP > eingebunden. Dies ist insbesondere immer notwendig, damit alle UNIX-Programme > per "getent" alle existierenden Benutzer und Gruppen abfragen können. > Nachteilig ist, daß die Datenstrukturen für das "shadow"-Verfahren sehr > beschränkt sind und keine Möglichkeit zur Erweiterung bieten. Das verhindert > u.a. die Nutzung von weiteren Informationen, wie sie z.B. im LDAP hinterlegt > sein können. Deswegen wird "ldap" noch ein weiteres mal eingebunden, um anhand > weiterer Kriterien entscheiden zu können, ob ein Benutzerkonto auf einem > Rechner gültig ist oder nicht. > Als drittes wird auch hier "krb5" verwendet, was ähnlich zu "ldap" die > Möglichkeit bietet, weitere Kriterien bei der Überprüfung zu berücksichtigen. > Ein wichtiger Unterschied ist allerdings, daß der Kerberos-Dienst keine > Zuordnung von Benutzername zu den benötigten POSIX-Informationen wie UID, GID, > GECOS, HOME, SHELL, etc. hat! Dienste, die diese Informationen benötigen, > müssel also zwingend zusätzlich "ldap" bzw. "unix" verwenden. > > Jedes dieser drei Verfahren zur Kontoverifizierung nutzt in UCS Informationen > aus dem LDAP: "unix" wertet die shadow-Informationen aus, "ldap" verwendet ggf. > zusätzlich das "host"-Attribut oder beliebige Filter, und "krb5" werdet die > Samba-Attribute ("sambaAcctFlags") aus. Von daher sind die Verfahren nicht > vollständig unabhängig voneinander und beeinflussen sich ggf. gegenseitig.
Die Änderungen sind drinne. Der Satz "In der Regel sollten alle Anmeldeverfahren gesperrt werden." könnte noch etwas besser erläutert werden.
Änderungen übernommen.
Eine fehlende, schließende Klammer im engl. Text wurde noch eingefügt. Verified.