Einfaches Single-Sign-On Teil 1 - (Open)LDAP

Getrennte User- und Passwortdatenbanken für jeden einzelnen Netzwerkdienst nerven sowohl User als auch Admins, besonders, wenn die User gerne ihre Passwörter vergessen. LDAP als zentrales Usermanagement einzusetzen, ist dabei einfacher als man denkt, und lohnt sich auch in typischen SOHO-Umgebungen (SOHO = Small Office/Home Office).

LDAP als Backend für die User- und Gruppendaten wird seit langer Zeit von allen Unix-Varianten unterstützt. Die Dokumentation ist allerdings oft zu knapp, unverständlich, falsch oder veraltet. Auch wird meist nur ein Aspekt und nicht das System als Ganzes betrachtet.

Dies ist der erste Beitrag in einer Folge mit einer Schritt-Für-Schritt-Anleitung für einen Server mit SSHD, Mail (Postfix), IMAP (Dovecot) und File Sharing (Samba) basierend auf OpenLDAP und dem System Security Services Daemon sssd auf einem aktuellen Linux-System. Für das Beispielsetup habe ich Gentoo Linux benutzt. Alles lässt sich aber auch auf jedem anderen Linux nachvollziehen.

In der Artikelserie geht es auch nicht um eine Erklärung, wie die einzelnen Dienste aufgesetzt werden. Es wird davon ausgegangen, dass alle Services bereits laufen, aber eben ohne LDAP. Bei allen Beispielen wird die Firma "Example Ltd." mit der Domain "example.com" verwendet.

Was ist Single Sign-On

Single Sign-On bedeutet eigentlich, dass Benutzer --- nachdem sie sich einmal eingeloggt haben --- automatisch für alle lokalen Dienste authentifiziert sind, ohne erneut Usernamen und Passwörter einzugeben. Das hier beschriebene Setup ist etwas anders, eher eine zentralisierte Verwaltung für User- und Gruppendaten, insbesondere Passwörter. Der Titel des Artikels ist also, hm, ..., eine kleine Marketinglüge.

Andererseits verliert echtes Single Sign-On auch mehr und mehr an Bedeutung, weil Benutzer heute Dienste nicht mehr nur von einem Gerät sonderen von vielen aus benutzen. Single Sign-On erspart einem zwar das getrennte Einloiggen in Mail, Dateiserver, Web-Applikationen und so weiter. Aber auch mit Kerberos muss man sich noch immer separat vom Computer, vom Tablet, vom Telefon, von seinen Wearables ... anmelden.

Weshalb LDAP?

LDAP genießt den zweifelhaften Ruf, aufgebläht, kompliziert und unverständlich dokumentiert zu sein; meines Erachtens zu Recht! Ganz ehrlich, eine relationale Datenbank wäre für die Verwaltung von Usern und Gruppen mindestens genauso gut geeignet.

Ein Nachteil von LDAP ist beispielsweise das Fehlen von Prüfung auf referenzielle Integrität der Daten im Auslieferungszustand. Bei OpenLDAP lässt sich dies relativ mühsam dazu konfigurieren (siehe die Manual-Page slapo-refint(5) für weitere Informationen), während Foreign-Key-Constraints relationaler Datenbanken relativ einfach zu verstehen und einzusetzen sind.

Trotzdem hat sich LDAP als Backend zur Speicherung von User- und Gruppendaten durchgesetzt, weil es lediglich ein von der konkreten Implementierung unabhängiges Protokol darstellt, so dass für den Einsatz als Backend nur noch geeignete Schemas entwickelt werden mussten, die sich --- zumindest theoretisch --- leicht für die eigene Organisation erweitern und anpassen lassen.

Theoretisch lassen sich natürlich auch verschiedene LDAP-Server-Implementierungen verwenden. Ich beschränke mich hier aber auf OpenLDAP.

OpenLDAP aufsetzen

Zunächst einmal muss OpenLDAP mit emerge, yum, apt-get, etc. installiert werden. Je nach Distribution heißt das entsprechende Paket "openldap", "openldap-servers", "slapd" oder ähnlich.

Die Konfigurationsdatei ist normalerweise /etc/openldap/slapd.conf. Meine sieht so aus:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/misc.schema

pidfile         /run/openldap/slapd.pid
argsfile        /run/openldap/slapd.args

database        hdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          "{SSHA}Vd6dXmLTKLn3ibXSTxfmVfY4t6mW5FZw"
checkpoint      32      30 

directory       /var/lib/openldap-data

index   objectClass     eq

Gehen wir diese Minimalkonfiguration einmal von vorne bis hinten durch.

In den Zeilen 1-5 werden die notwendigen Schemadefinitionen, die für eine User- und Gruppendatenbank benötigt werden, eingebunden.

Die Zeilen 7 und 8 werden häufig angepasst werden müssen. Für CentOS ist hier beispielsweise /var/run/openldap statt /run/openldap zu verwenden. Normalerweise sollte man den richtigen Pfad in der Defaultkonfiguration für das entsprechende System finden. Falls das nicht geht, kann man find / -type d -name openldap probieren.

In Zeile 10 wird als Datenbankbackend "hdb" ausgewählt. Das sollte für kleine Umgebungen immer reichen.

Die Zeilen 11 und 12 müssen immer an den eigenen Domainnamen angepasst werden. Der "Manager" in Zeile 12 ist eigentlich frei wählbar, "Manager" scheint aber die gängige Bezeichung zu sein.

Der Passwort-Hash in Zeile 13 kann mit dem Tool "slappasswd" erzeugt werden:

# slappasswd
New password: 
Re-enter new password: 
{SSHA}Vd6dXmLTKLn3ibXSTxfmVfY4t6mW5FZw

In der Konfigurationsdatei muss das Passwort in doppelte Anführungszeichen eingeschlossen werden. Es kann aber auch ein Klartextpasswort in der Konfigurationsdatei verwendet werden:

rootpw    "secret"

Natürlich sollte man dann darauf achten, dass der Lesezugriff auf die Konfigurationsdatei vernünftig abgesichert ist.

Der Pfad zum LDAP-Datenverzeichnis in Zeile 16 muss ebenfalls eventuell angepasst werden. Andere gängige Pfade sind /var/lib/ldap oder /var/openldap-data. Das Verzeichnis sollte den Modus 0700 haben, und dem User, unter dem der LDAP-Server läuft, gehören. Meistens wird das der User "ldap" sein.

Die Direktive "checkpoint" konfiguriert das Checkpointing der Datenbank. "32 30" bedeutet dabei, dass ein Checkpoint nach dem Schreiben von 32 kB Daten, spätestens aber nach 30 Minuten erzeugt wird. Siehe http://www.zytrax.com/books/ldap/ch6/bdb.html#checkpoint für eine bessere Erklärung.

Zeit, den LDAP-Server zu starten. Normalerweise ist die Bezeichnung des Service' "slapd" (nicht "openldap" oder "ldap"):

# /etc/init.d/slapd start
 * /var/lib/openldap-data/DB_CONFIG does not exist, slapd performance may be sub-optimal
 config file testing succeeded
  * Starting ldap-server ...                                               [ ok ]

Alles hat geklappt, bis auf die hässliche Warnung über die fehlende Datenkbank-Konfiguraiton. OpenLDAP liefert normalerweise eine DB_CONFIG.example als Beispiel mit. Meine Version sieht so aus:

# cat /var/lib/openldap-data/DB_CONFIG
# $OpenLDAP$
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#   <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#   <http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Data Directory
#set_data_dir db

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs

# Note: special DB_CONFIG flags are no longer needed for "quick"
# slapadd(8) or slapindex(8) access (see their -q option).

Wenn diese Datei als DB_CONFIG ins Datenverzeichnis kopiert wird, sollte die Warnung verschwinden.

Starten von OpenLDAP via systemd

Mit systemd muss der Server so gestartet werden:

systemctl start slapd

TLS/SSL aktivieren

Die Kommunikation mit dem LDAP-Server läuft im Moment komplett unverschlüsselt ab, und das wird im Rahmen dieses Tutorials aus Gründen der Einfachheit auch so bleiben.

Für einen Heim-Server mag das noch angehen, aber in aller Regel sollte die Kommunikation immer über TLS/SSL laufen. Die Minimalkonfiguration in /etc/openldap/slapd.conf sieht dafür so aus:

TLSCipherSuite normal
TLSCACertificateFile  /etc/openldap/certs/ldap.example.com.crt
TLSCertificateFile    /etc/openldap/certs/ldap.example.com.pem
TLSCertificateKeyFile /etc/openldap/certs/ldap.example.com.key
TLSVerifyClient never

Diese Dateien müssen natürlich auch erzeugt werden. Eine Websuche nach "openssl tutorial" liefert tonnenweise Dokumentation dafür. Sobald der OpenLDAP-Servder abgesichert wurde, muss überall Port 389 mit Port 636, und das Schema "ldap://" mit "ldaps://" ersetzt werden.

Dynamische slapd-Konfiguration

In vielen Tutorials wird beschrieben, wie sich die Konfigurationsdatei in eine sogenannte "dynamische Konfiguration" umwandeln lässt. Im Wesentlichen handelt es sich dabei um ldif-Dateien, die mit den Kommandos "ldapadd" und "ldapmodify" der Konfiguration eines laufenden Servers zugefügt werden können. Ganz ehrlich schießt man sicher besser in den Kopf statt sich die Hände mit diesem Zeug schmutzig zu machen. Solange man keinen wirklich guten Grund zum Wechseln hat, sollte man bei der Variante mit der Human-Readable Konfigurationsdatei bleiben.

Replikation, Zugriffsrechte, ...

Ebenfalls viel geschrieben wird über Replikation mit weiteren Servern oder eine granularere Konfiguration der Zugriffsrechte. Im Allgemeinen wird man das nicht benötigen.

Daten in LDAP einpflegen

Erzeugung des Wurzeleintrags ("base entry")

Die Datenbank --- in der LDAP-Welt "Directory/Verzeichnis" genannt --- ist noch leer. Meistens wird empfohlen sie ldif-Dateien über die Kommandos "ldapadd/ldapmodify" zu befüllen. Hier wird stattdessen beschrieben, wie die Datenpflege mit einem GUI-Tool durchgeführt werden kann. Lediglich für den Wurzeleintrag ist das nicht möglich. Hierfür muss zunächst mit einem beliebigen Editor eine Datei base.ldif erzeugt werden:

dn: dc=example,dc=com
objectclass: organization
objectClass: dcObject
o: Example Ltd.

Die erste und letzte Zeile müssen natürlich an die eigene Umgebung angepasst werden. Die Datei kann jetzt auf der Kommandozeile mit "ldapadd" ins Verzeichnis eingetragen werden:

$ ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f base.ldif
Enter LDAP Password: secret
adding new entry "dc=example,dc=com"

Auch hier muss "example" wieder durch den eigenen Domainnamen ersetzt werden. Das Passwort ist das Root-Passwort aus slapd.conf.

JXplorer

Normalerweise ziehe ich Kommandozeilentools GUI-Programmen for. Tatsächlich sind "ldapadd" und "ldapmodify" erste Wahl bei der Pflege der Daten, wenn alles automatisiert abläuft. Wer aber Daten nur gelegentlich einpflegt oder ändert ist mit graphischen LDAP-Frontends besser bedient. Man spart eine Menge Tipperei und fehlerhafte Eingaben.

Es gibt etliche LDAP-Frontends (LDAP-"Browser"). Ich habe mich für JXplorer entschieden. JXplorer ist hässlich und langsam, weil es in Java geschrieben ist, aber tut, was es soll, es ist kostenlos und plattformunabhängig.

Hinweise zur Installation gibt es auf der Website von JXplorer.

Nachdem JXplorer gestartet wurde, kann man via File -> Connect oder über das Icon ganz links in der Toolbar die Verbindung zum LDAP-Server herstellen:

Der LDAP-Servers kann entweder als IP-Adresse oder Hostname angegeben werden. Base-DN und User-DN sind die, die in slapd.conf konfiguriert werden, und das Manager-Passwort ist das Passwort, das weiter oben mit slappasswd erzeugt wurde.

Augenblick! Noch nicht "OK" klicken! Damit man nicht jedesmal alles eintippen muss, sollte man die Konfiguration erst mit "Save" unter einem aussagekräftigen Namen abspeichern. Beim nächsten Mal kann diese Konfiguration dann über die Select-Box neben dem "Save"-Button wieder geladen werden.

Nach einer erfolgreichen Verbindung ist der aktuelle Inhalt des Verzeichnes sichtbar. Zur Zeit enthält es lediglich den Wurzeleintrag:

Im linken Bereich ist der aktuelle Baum zu sehen. Der rechte Bereich enthält ein Formular mit den Daten, das zur Zeit lediglich den Namen der Organisation enthält. Weil "HTML View" ausgewählt ist, sieht man hier eine HTML-Ansicht des Eintrages. Durch einen Klick auf "Table Editor" wird die Tabellenansicht aktiviert:

Erzeugung von Gruppen

Linux erlaubt die gleichzeitige Verwendung von Dateisystem und LDAP als Datenquelle für User und Gruppen. Gruppen müssen daher nicht zwangsläufig aus LDAP stammen. Ich empfehle, die System-User (root, daemon, postfix, ...) und System-Gruppen (root, wheel, audio, video, ...) weiterhin im Dateisystem zu pflegen, und LDAP für menschliche User zu verwenden.

Bevor die eigentlichen Gruppen erzeugt werden, brauchen wir erst einmal einen Container für sie. Dies geht mit einem Rechts-Klick auf "example" (bzw. den eigenen Domainnamen) im linken Bereich. Im Kontextmenü klicken wir jetzt auf "New":

Unter RDN (relative distinguished name) wird exakt "ou=Group" eingetragen. Dann werden die drei Klassen "organizationalUnit", "domainRelatedObject" und "top" unter "Available classes" ausgewählt und mit "Add" zugefügt. Die Klasse "top" kann auch weggelassen werden, weil sie implizit und automatisch zugefügt wird. Schließlich klicken wir "OK", um den Eintrag anzulegen.

Wir sind allerdings noch nicht fertig. Im rechten Bereich ist das Pflichtfeld "associatedDomain" noch leer. Die Namen von Pflichtfeldern sind fett. Hier muss jetzt der Domainname eingetragen werden:

Durch Klick auf "Submit" wird der Eintrag ins Verzeichnis eingetragen. Neben dem Wurzeleintrag wird jetzt ein Dreieck im linken Bereich angezeigt. Durch einen Klick auf dieses Dreieck wird der Eintrag expandiert und der neue Eintrag "Group" sichtbar.

Spätestens jetzt sollte man sich Gedanken über eine sinnvolle Nummerierung der Gruppen und User. Linux kann mit einem Mix aus Usern und Gruppen aus Dateisystem und LDAP umgehen. Ich würde es allerdings einfach halten und im LDAP numerische IDs verwenden, die möglichst nicht mit denen kollidieren, die von herkömmlichen, dateisystembasierten Tools erzeugt werden,

Ich verwende im LDAP daher IDs ab 10000 so dass die niedrigeren von den konventionellen Tools verwendet werden können.

Beginnen wir mit einer Gruppe "staff" (oder "family"). Erzeugt wird sie mit einem Rechts-Klick auf "Group" im linken Bereich von JXplorer und Auswahl von "New" wie neu im Kontextmenü:

Als RDN muss "cn=staff" eingetragen werden. Die einzige Klasse, die ausgewählt werden muss, ist "posixGroup". Vor Abschicken der Daten mit "Submit" muss noch bei gidNumber die Gruppen-ID 10000 im rechten Bereich eingetragen werden. Vergisst man diesen Schritt, wird das mit einer Fehlermeldung "Unable to perform Modify operation" quittiert.

Auf die gleiche Art erzeugen wir noch eine Gruppe "management" mit der GID 10001 für User mit Lese- und Schreibzugriff auf interne Dokumente. Weiternin erzeugen wir eine Gruppe "management-readers" (GID 10002), die nur Lesezugriff auf diese Dokumente hat, und schließlich eine Gruppe "external" (GID 10003) für Externe mit eingeschränkten Rechten.

Dummerweise werden die Gruppen nach dem Namen (Attribut cn wie Common Name) und nicht nach der numerischen Gruppen-ID, die für LDAP nur ein zufälliges Attribut ist, sortiert. Erschwerend kommt hinzu, dass man soviele Gruppen wie man will mit der gleichen Gruppen-ID erzeugen kann. Das ist keineswegs ein Bug oder Mangel des Systems, sondern ein normales Feature von Unix, dass man auch mit /etc/passwd und /etc/group nutzen kann.

Es ist keine große Sache bei Gruppen, aber kann einem bei den Usern schnell Kopfschmerzen machen, weil man normalerweise erheblich mehr User als Gruppen hat. Es bleibt einem nichts anderes übrig, also die IDs zu zählen oder zumindest Buch über die zuletzt verwendete ID zu führen.

Eine andere Lösung besteht darin, den LDAP-Server nach den bereis verwendeten IDs zu befragen:

$ ldapsearch -h localhost -b dc=example,dc=com -S gidNumber objectClass=posixGroup | grep ^gidNumber
gidNumber: 10000
gidNumber: 10001
gidNumber: 10002
gidNumber: 10003

Die Optionen "-h localhost" für den Hostnamen und "-b dc=example,dc=com" für Base-DN müssen natürlich an die lokalen Gegebenheiten angepasst werden.

Erzeugung der User

Genau wie bei den Gruppen ist auch für die User ein Container erforderlich. Dieser Container wird in der Regel "People" genannt. Auch dieser wird mit Rechts-Klick auf den Wurzeleintrag ("example" in unserem Beispeil) und Auswahl von "New" erzeugt:

Der Eintrag wird mit "OK" erzeugt, dann muss noch "example.com" (bzw. die eigene Domain) als Wert für das Pflichtfeld associatedDomain eingetragen werden, und der neue Eintrag schließlich mit "Submit" auf dem Server gespeichert werden.

Auch für die User sollte man sich Gedanken um eine Nummerierungskonvention machen. Ich verwendet UIDs im LDAP, die mit 10000 beginnen, damit man klar zwischen System-Usern und menschlichen Usern unterscheiden kann.

Für alles außer einem Home- bzw. Familien-Server muss man sich auch ein Namensschema für User ausdenken. Eine beliebte Variante ist "vorname.nachname". Ich werde für dieses Beispiel "vnachname" verwenden. Wir beginnen mit einem Eintrag für die erste Userin Juliet Boss, der mit einem Rechts-Klick auf "People" und Auswahl von "New" wie neu angelegt wird:

Gemäß dem von uns gewählten Namensschema "vnachname" ist als RDN hier "uid=jboss" einzutragen.

An Klassen muss "organizationalPerson", "inetLocalMailRecipient", "posixAccount" und "shadowAccount" ausgewählt werden. Die Klassen "person" und "top" werden implizit automatisch zugefügt.

Nach Anlegen der Userin mit Klick auf "OK" sieht man, dass die (fettgedruckten) Pflichtfelder "cn", "gidNumber", "homeDirectory", "sn" und "uidNumber" noch nicht ausgefüllt sind. Das holen wir jetzt nach:

Das Attribut "cn" ist für den "common name", den "Gemeinnamen", normalerweise also den vollen, menschenlesbaren Namen der Person vorgesehen.

Das Attribut "gidNumber" enthält die numerische ID der primären Gruppe. Wir tragen 10000, die Gruppen-ID der Gruppe "staff" ein.

Der Name des Heimatverzeichnisses ist normalerweise der Login-Name ("jboss") unterhalb des Verzeichnisses "/home".

Als "uidNumber| wählen wir 10000. Das Attribut "sn" steht für surname, den Nachnamen, in unserem Fall also "Boss".

Auch die optionalen Attribute "givenName" für den Vornamen, "mail" für die Mail-Adresse etc. sollten ausgefüllt werden. Das Feld "gecos" enthält normalerweise den gleichen Wert wie "cn". Ob "cn" oder "gecos" Vorrang bei Abfrage der Userdaten mit getpwent(3), getpwnam(3), getpwuid(3) oder getpwuuid(3)hat, kann man in eigener Forschungsarbeit herausfinden.

Das optionale Attribute "userPassword" wird man ebenfalls fast immer befüllen. In JXplorer geschieht dies über einen Pop-Up-Dialog, in den man das Passwort als Klartext eintragen kann.

Für das Verschlüsselungsschema ("encryption scheme") hat man die Wahl zwischen "verify", "plain", "MD5", "SMD5", "SHA" und "SSHA". Bleibt man bei der Vorgabe "SHA" wird das Passwort nicht im Klartext sondern als "{SHA}DIGEST" in LDAP abgelegt, wobei "DIGEST" für den SHA-Digest des eingegebenen Passworts steht. Benutzt man die Kommandozeilentools "ldapadd/ldapmodify" muss der Digest wie oben für das Root-Passwort gezeigt mit "slappasswd" generiert werden. Die grafische Benutzeroberfläche von JXplorer ist hier komfortabler.

Auch das Attribut "loginShell" sollte ausgefüllt werden, beispielsweise mit /bin/sh oder /bin/bash (siehe /etc/shells für eine vollständige Liste der Optionen).

Wenn alle notwendigen und nicht so notwendigen Daten eingegeben sind, werden sie mit "Submit" auf dem Server gespeichert.

Auf die gleiche Art erzeugen wir noch drei weitere User:

• Tim Rainee mit der numerischen UID 10001
• Susan Ecretary mit der numerischen UID 10002
• Ferdinand Reelancer mit der numerischen UID 10003

Alle haben die primäre Gruppe 10000, also die Gruppe "staff".

Augenblick! Ferdinand Reelancer ist ein Externer, nicht von der Firma angestellt. Wir wählen daher seinen Eintrag im linken Bereich aus und ändern das Attribut gidNumber auf 10003, die numerische GID der Gruppe "external".

Nicht vergessen, die Änderungen mit "Submit" zu speichern!

Wir haben auch hier das Problem, dass nicht offensichtlich ist, welche numerischen UIDs schon benutzt sind. Ein Überblick lässt sich mit diesem Kommando erlangen:

$ ldapsearch -h localhost -b dc=example,dc=com -S gidNumber objectClass=posixAccount | grep ^uidNumber
uidNumber: 10000
uidNumber: 10001
uidNumber: 10002
uidNumber: 10003

JXplorer zum Suchen benutzen

Man kann auch mit JXplorer nach bereits verwendenten UIDs suchen. Dazu muss zunächst eine Liste mit Rückgabe-Attributen ("return attribute list") über den Menü-Eintrag Seach -> Return Attributes erzdeugt werden:

Die Liste wird als uidNumber oder Ähnliches abgespeichert. Sie wird jetzt für die Erzeugung des Filters über den Menü-Eintrag Search -> Search Dialog benötigt:

Im Feld "Start searching from" tragen wir den Knoten "ou=People,dc=example,dc=com" ein, ab dem gesucht werden soll. Unter "Information to retrieve" wählen wir die eben erzeugte Liste aus. In der Filterdefinition darunter wählen wir "uidNumber" als Attribut und "Present" als Bedingung.

Nein! Noch nicht "Search" anklicken! Zuerst speichern wir den Filter als Verwendete UIDS.

Die gelieferten Suchergebnisse sehen dann so aus:

Die Ergebnisse lassen sich leider nicht soritieren, sondern werden in der Reihenfolge angezeigt, in der sie erzeugt wurden, was normalerweise passt, wenn man fortlaufende Nummern verwendet. Bitte beachten, dass die links ausgewählte Ansicht jetzt von "Explore" zu "Results", also den Suchergebnissen umgeschaltet wurde. Um zur gewohnten Ansicht zurückzukehren, muss in der entsprechenden Combo-Box "Explore" ausgewählt werden.

Mehrwertige Felder

Ferdinand Reelancer benutzt neben unsere E-Mail-Adresse "freelancer@example.com" auch noch "ferdinand@reelancer.net". In der tabellarischen Ansicht für sein seinen Eintrag rechtsklicken wir deshalb auf das Attribut "mail" und wählen "Add another value" um einen weiteren Wert einzutragen:

Zusätzliche Gruppen setzen

Bis jetzt hat jeder als primäre Gruppe "staff" (10000) oder "external" (10003). Wir werden jetzt einige User in weitere Gruppen aufnehmen.

Selektieren wir den Eintrag für Susan Ecretary. Mit Rechtsklick auf das Attribut gidNumber kann man zwar einen weiteren Wert 10002 für die Gruppe "management-readers" setzen. Das Speichern scheitert allerdings mit der Fehlermeldung "Unable to perform Modify operation". Ein Klick auf "Details" zeigt den eigentlichen Fehler "attribute 'gidNumber' cannot have multiple values". Das Attribut gidNumber darf also nur einen Wert haben.

Stattdessen muss die Gruppe "management-readers" ausgewählt werden, und für das Attribut memberUid der Wert "secretary" eingetragen werden. Ja, "secretary" und nicht 10002! Wenn man an numerische UIDs gewöhnt ist, vertut man sich hier gerne, und LDAP hilft einem nicht mit Konsistenz-Checks.

Auch Juliet Boss soll natürlich Lesezugriff auf die Management-Dokumente haben. Für sie muss also ein weiterer Wert für memberUid angegeben werden:

Als nächstes wählen wir die Gruppe "management" aus, und fügen die memberUid "jboss" ein, um Juliet Boss zusätzlich Schreibzugriff auf die Management-Dokumente zu gewähren.

Es lassen sich auch User explizit den primären Gruppen "staff" bzw. "external" zuweisen. Notwendig ist es allerdings nicht, wie wir später bei der Konfiguration von PAM sehen werden. Um Redundanz zu vermeiden, empfehle ich daher, die primäre Gruppe nur beim User zu setzen.

Nochmal LDAP-Zugriffsrechte

Um die verwendeten UIDs und GIDs über die Kommandozeile zu ermitteln, musste kein Passwort angegeben werden. Ohne weitere Konfiguration ist das Verzeichis also --- genau wie /etc/passwd und /etc/group --- für Jedermann lesbar, wobei die LDAP-Daten sogar über das Netzwerk ausgelesen werden können.

Das bedeutet zunächst einmal selbstverständlich, dass der LDAP-Dienst nicht über das Internet erreichbar sein sollte.

Je nach Organisation kann das auch interne, rechtliche Probleme wegen Verletzung der Datenschutzrichtlinien mit sich bringen. Dies lässt sich entweder so lösen, dass man lediglich dem administrativen (LDAP-)User "Manager" Zugriff auf die Verzeichisdaten gibt, oder doch die Rechte mit feinerer Granularität setzt. Die Manual-Page slapd.conf(5) gibt weitere Informationen hierzu.

Wie geht es weiter?

Der nächste Teil wird sich damit beschäftigen, wie PAM zu konfigurieren ist, damit es User und Gruppen zusätzlich aus LDAP liest.

LDAP kann auch als Daten-Backend für DNS, für Zerrtifikatsverwaltung und eine Reihe weiterer Anwendungen eingesetzt werden. Für kleine Organisationen lohnt der Aufwand in aller Regel aber nicht, und deshalb wird auf diese Anwendungen in diesem Dokument auch nicht näher eingegangen.

Für Anregungen und Verbesserungen kann gerne die Kommentarfunktion verwendet werden.