Univention Bugzilla – Bug 18836
Vereinheitlichen von POSIX / Linux / UNIX Bezeichnung
Last modified: 2015-04-01 13:48:16 CEST
Das sollte in der Doku angepasst werden. +++ This bug was initially created as a clone of Bug #18835 +++ Derzeit heisst die Option Posix, der Reiter Linux/UNIX und die Reiterbeschreibung UNIX. Wir sollen auf den Wert POSIX wechseln, als Option POSIX-Konto, als Reiterüberschrift POSIX (Linux/UNIX) und als Reiterbezeichnung POSIX (Linux/UNIX) Kontoeinstellungen. +++ 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.
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.
Die Bezeichnungen wurden angepasst. (Deutsch und Englisch)
Ist noch nicht vollständig angepasst: * doku/desktop-systeme/desktop-systeme.tex * doku/desktop-systeme/desktop-systeme_en.tex * doku/univention-directory-manager/modules/policies_en.tex * doku/univention-directory-manager/modules/hosts.tex * doku/univention-directory-manager/modules/policies.tex Hier wird noch nur von Linux/UNIX gesprochen.
Ergänzungen für Deutsch und Englisch vorgenommen.
> 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) Das kann über die UCR-Variablen "auth/admin/methods" und "auth/user/methods" angepasst werden; Standard ist da "krb5 ldap unix".
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.
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.
OK.