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 nummerische 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 nummerischen 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 nummerische 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 Attributsnsteht für surname, den Nachnamen, in unserem Fall alsoBoss".

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 nummerischen UID 10001
• Susan Ecretary mit der nummerischen 10002
• Ferdinand Reelancer mit der nummerischen 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 nummerische GID der Gruppe external.

Nicht vergessen, die Änderungen mit Submit zu speichern!

Wir haben auch hier das Problem, dass nicht offensichtlich ist, welche nummerischen 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 nummerische 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.