In der ersten Auflage dieses Buches haben wir die Installation noch für zwei Distributionen beschrieben, da bei den verschiedenen Distributionen ein paar Unterschiede bestanden. Dieses Mal greifen wir auf die Pakete der Firma Symas zurück, daher sind jetzt, bei allen unterstützten Distributionen, die Pfade und Dateinamen identisch, sodass wir hier die Installation distributionsunabhängig beschreiben können.
Hinweis: Bei den Paketen ist der Pfad, in dem die Dateien der Pakete abgelegt werden, immer /opt/symas/. Der Grund dafür ist: So kollidieren die Dateien aus den Symas-Paketen nicht mit den Dateien aus den Paketen der Distribution, falls Sie die Pakete noch installiert haben.
An dieser Stelle gehen wir auch noch einmal auf die Unterschiede zwischen der statischen und dynamischen Konfiguration ein. Im Rest des Buches werden wir dann ausschließlich die dynamische Konfiguration nutzen.
Der Grund ist der, dass die statische Konfiguration auf der Website https://www.openldap.org als deprecated angegeben wird. Das bedeutet, dass die Möglichkeit der Konfiguration über eine einfache ASCII-Textdatei leider auf Dauer nicht mehr möglich sein wird. In komplexen Installationen mit mehreren Providern ist die Konfiguration über die statische Konfiguration auch nicht mehr zeitgemäß.
Bei der dynamischen Konfiguration werden sowohl die Grundkonfiguration als auch alle weiteren Änderungen über LDIF-Dateien in einer speziellen Datenbank im LDAP gespeichert, und der LDAP-Server verwaltet sich quasi selbst.
| 3.0.1 | Die statische Konfiguration |
Bei der statischen Konfiguration handelt es sich um die klassische Variante der Konfiguration. Alle Konfigurationsparameter werden in einer Konfigurationsdatei abgelegt. Immer, wenn Sie eine Änderung durchgeführt haben, ist es notwendig, dass Sie den LDAP-Server neu starten, damit die Änderung wirksam wird. Wenn Sie mehrere LDAP-Server einsetzen, müssen Sie die Konfiguration immer auf allen LDAP-Servern anpassen.
Nicht nur die grundlegende Konfiguration wird in der statischen Konfiguration in der Konfigurationsdatei abgelegt, sondern später auch alle ACLs und die Konfiguration der eventuell verwendeten Overlays (bei Overlays handelt es sich um eine Art Plug-in, das die Funktion des LDAP-Servers erweitert; mehr zum Thema Overlays finden Sie in Kapitel 10, «Einsatz von Overlays»).
Sie können die Konfiguration Ihres LDAP-Servers auch erst statisch beginnen und später auf die dynamische Konfiguration umstellen.
Da die Datei slapd.conf bei allen Distributionen denselben Inhalt hat, möchten wir Ihnen an dieser Stelle die einzelnen Zeilen der Konfiguration erklären. So können Sie in diesem Kapitel den Inhalt der statischen Konfiguration noch sehr gut mit der dynamischen Konfiguration vergleichen. In Listing 3.1 sehen Sie den Inhalt der Datei:
Listing 3.1 Die slapd.conf
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /opt/symas/etc/openldap/schema/core.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/nis.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args # Read slapd.conf(5) for possible values loglevel 256 # Load dynamic backend modules: modulepath /opt/symas/lib/openldap moduleload back_mdb.la moduleload argon2.la # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu’s that is used # for indexing. tool-threads 1 password-hash {ARGON2} ############################################# # Specific Directives for database #1, of type hdb: # Database specific directives apply to this databasse until another # ’database’ directive occurs database mdb maxsize 1073741824 # The base of your directory in database #1 suffix "dc=example,dc=net" # rootdn directive for specifying a superuser on the database. rootdn "cn=admin,dc=example,dc=net" #rootpw "geheim" rootpw "{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$c2Fs..." # Where the database file are physically stored for database #1 directory "/var/symas/openldap-data" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by anonymous auth by self write by * none access to * by * read access to dn.base="" by * read
Die Konfigurationsdatei besteht aus zwei Teilen: Der erste Teil oberhalb der Linie aus Hashes ist der globale Teil, der für alle Datenbanken, die der OpenLDAP bereitstellt, relevant ist. Der Teil unterhalb betrifft immer eine bestimmte Datenbank. Der Parameter database mdb markiert dabei den Beginn einer neuen Datenbank.
Als Erstes werden die Schematadateien eingebunden, die Reihenfolge ist dabei sehr wichtig. Beim Start des LDAP-Servers werden die Dateien eine nach der anderen abgearbeitet. Da durch die Möglichkeit der Vererbung von Attributen eine Abhängigkeit zwischen den einzelnen Schemata besteht, müssen Sie immer wissen, welche Objektklasse eventuell Attribute einer anderen Objektklasse nutzt. Die Standardobjektklassen, die hier eingebunden sind, befinden sich schon in der richtigen Reihenfolge. Wenn Sie ein eigenes Schema mit eigenen Objektklassen erstellen, ist es wichtig, dass Sie am Anfang Ihres Schemas etwaige Abhängigkeiten kommentieren.
In den Zeilen pidfile /var/symas/run/slapd.pid und argsfile /var/symas/run/slapd.args werden die Prozess-ID und die Argumente, die beim Start des OpenLDAP-Servers verwendet werden, abgelegt.
Das loglevel legt fest, welche Ereignisse geloggt werden. Dabei werden die Zahlen nicht einfach hochgezählt, sondern die einzelnen Werte werden binär übergeben. Am Anfang ist ein loglevel 256 (stats) eine gute Einstellung, denn da werden alle Zugriffe geloggt. Welche Loglevel Sie verwenden können, finden Sie in der Manpage zur slapd.conf. Im späteren produktiven Betrieb stellt jede Art von Logging immer einen Flaschenhals da. Es ist daher sinnvoll, nachdem der OpenLDAP eingerichtet wurde, das Loglevel auf den Wert none zu setzen, dann werden nur noch systemkritische Fehler ins Log geschrieben. Setzen Sie das Loglevel auf 0, werden auch diese Meldungen nicht mehr ins Log geschrieben.
Die Parameter modulepath und moduleload werden immer dann benötigt, wenn Sie zusätzliche Module für zusätzliche Funktionen nutzen wollen. Bei den Symas-Paketen werden alle Overlays über Module bereitgestellt und müssen einzeln geladen werden.
Der Parameter sizelimit 500 legt fest, wie viele Antworten bei einer Suche zurückgegeben werden. Gerade wenn Sie einen großen LDAP-Baum mit mehreren Tausend Objekten pflegen, kann die Antwort den Server stark belasten. Deshalb diese Grenze. Über Filter können Sie die Suche einschränken. Die Übersteuerung der Einschränkung der zurückgegebenen Objekte bei der Suche muss immer direkt in der Datenbank definiert werden, für die sie zutreffen soll.
Wenn Sie sehr viele Indexdatenbanken einsetzen, um die Suche nach Attributen oder Objekten zu beschleunigen, kann es sinnvoll sein, mehr als nur eine CPU für das Indizieren zu verwenden. Testen Sie, ob eine weitere CPU für Sie Vorteile bringt.
Wir werden hier im Buch nur noch ARGON2 als Passworthash nutzen. Über den Parameter password-hash legen Sie den neuen Passworthash fest. Mehr zum Thema ARGON2 finden Sie unter https://de.wikipedia.org/wiki/Argon2.
Mit database mdb beginnt nicht nur der Datenbankteil, sondern Sie legen auch den Datenbanktyp fest. Seit einiger Zeit wird nur noch der Datenbanktyp mdb empfohlen, alle anderen alten Datenbanktypen werden in Zukunft nicht mehr unterstützt.
Der suffix legt die oberste Ebene Ihres LDAP-Baums fest.
Beim rootDN handelt es sich um den Hauptadministrator, der immer alle Rechte hat und nie auf irgendeine Art und Weise beschränkt werden kann. Der Benutzer wird nicht in der Datenbank angelegt.
Das rootpw ist das Passwort für den rootDN. Halten Sie dieses Passwort immer unter Verschluss. Mit diesem Passwort können sämtliche Änderungen am LDAP-Baum vorgenommen werden. In der Beispieldatei sehen Sie, dass hier schon ARGON2 als Passorthash genutzt wird. Anders als bei der Verwendung anderer Passwordhashes nutzen Sie hier das Kommando echo -n "mein-geheimes-pw" | argon2 "saltsaltsaltsalt" -e, um den Passworthash zu erzeugen.
Mit dem Parameter directory legen Sie fest, in welchem Verzeichnis die Datenbankdateien abgelegt werden. Für jede Datenbank, die Sie mit dem LDAP-Server verwalten wollen, benötigen Sie ein eigenes Verzeichnis.
Über den Parameter index werden die Indexdatenbanken für diese LDAP-Datenbank festgelegt. Später werden wir noch näher auf die Indexeinträge eingehen.
Lastmod on speichert die Zeit der letzten Änderung für jedes Objekt in der Datenbank.
Am Schluss folgen die ACLs für die Zugriffe. Auf die ACLs gehen wir in Kapitel 9, «Berechtigungen mit ACLs», näher ein.
Tipp: Haben Sie bis jetzt Ihren LDAP-Server über die statische Konfiguration verwaltet, können Sie diese mit dem Kommando slaptest -F /opt/symas/etc/openldap/slapd.d -f /etc/ldap/slapd.conf in die dynamische Konfiguration umwandeln.
| 3.0.2 | Die dynamische Konfiguration |
Bei der dynamischen Konfiguration werden alle Einstellungen des LDAP-Servers in einer eigenen Datenbank im LDAP abgelegt: Sowohl die Grundkonfiguration, die Erweiterung des Funktionsumfang durch Overlays als auch die ACLs werden mittels LDIF-Dateien in die Datenbank eingespielt. Kommentare können Sie in dieser Datenbank nicht ablegen, sodass Sie sämtliche Änderungen und Einstellungen extern dokumentieren müssen.
Der große Vorteil der dynamischen Konfiguration ist, dass Sie hier den LDAP-Server nach einer Änderung nicht neu starten müssen; die Änderung ist sofort wirksam, nachdem Sie die LDIF-Datei eingespielt haben. Auch Ihre ACLs passen Sie dann immer über LDIF-Dateien an; auch sie sind nach dem Einspielen sofort wirksam. Wenn Sie mit grafischen Werkzeugen arbeiten wollen, dann achten Sie darauf, ob das Werkzeug die dynamische Konfiguration bearbeiten kann. Wir werden in Kapitel 7, «Grafische Werkzeuge», noch darauf zu sprechen kommen.
Wenn Sie mehrere LDAP-Server einsetzen und diese vielleicht auch noch an unterschiedlichen Standorten stehen und Sie häufig Änderungen an der Konfiguration oder den ACLs vornehmen, dann ist die dynamische Konfiguration auf jeden Fall der bessere Weg. Mit der neuen Version 2.5 und 2.6 funktioniert jetzt auch die Replikation der dynamischen Konfiguration fehlerfrei. So können Sie Änderungen an der Konfiguration auf einem Server einspielen, und die Änderung wird auf alle anderen OpenLDAP-Servern repliziert. Durch den geänderten Replikationsprozess in den neuen Versionen können Sie so einen Multiprovider-Cluster aufbauen und die Konfiguration für den gesamten Cluster mit einer LDIF-Datei anpassen.
| 3.1 | Installation der Symas-Pakete |
Eine Besonderheit der Symas-Pakete sei hier gleich am Anfang erwähnt: Der Dienst startet in der Standardeinstellung, nach der Installation, grundsätzlich mit der Benutzerkennung root. Das ist aber keine gute Idee und soll hier auch sofort geändert werden.
Aber als Erstes werden jetzt die Pakete installiert. Dafür benötigen Sie die Daten, um das Repository auf Ihrem System einzutragen. Damit Sie nach dem Installieren der Pakete auch gleich die Zugriffsrechte für die verwendeten Verzeichnisse anpassen, sehen Sie in Listing 3.2 ein Skript, mit dem Sie nicht nur die Pakete installieren können, sondern auch gleich einen Benutzer für den Dienst anlegen und die Berechtigungen im Dateisystem setzen:
Listing 3.2 Skript zur Installation der Symas-Pakete
#!/bin/bash DEBIAN_FRONTEND=noninteractive apt install -yq gnupg2 argon2 python3-ldap wget -O- https://repo.symas.com/repo/gpg/RPM-GPG-KEY-symas-com-signing-key\ | gpg --dearmor | tee /etc/apt/trusted.gpg.d/symas-com-gpg.gpg \ > /dev/null echo "deb [arch=amd64] https://repo.symas.com/repo/deb/main/release26 \ bullseye main" | tee -a /etc/apt/sources.list.d/symas26.list apt update -y groupadd -r openldap useradd -r -g openldap -d /opt/symas/ openldap DEBIAN_FRONTEND=noninteractive apt install -yq symas-openldap-clients \ symas-openldap-server chown openldap:openldap /var/symas/openldap-data/ chmod 770 /var/symas/openldap-data/ chown openldap:openldap /var/symas/run chmod 770 /var/symas/run mkdir -m 770 /opt/symas/etc/openldap/slapd.d chown openldap:openldap /opt/symas/etc/openldap/slapd.d
Nachdem die Pakete installiert sind, benötigen Sie jetzt noch ein neues Skript für den systemd, um auch den slapd mit dem gerade angelegten Benutzer und der Gruppe zu starten. Das Skript aus Listing 3.3 können Sie so übernehmen:
Listing 3.3 Serviceskript zum Starten des slapd
[Unit] Description=Symas OpenLDAP Server Daemon After=network-online.target Documentation=man:slapd Documentation=man:slapd-config Documentation=man:slapd-mdb [Service] Type=notify EnvironmentFile=/etc/default/symas-openldap ExecStart=/opt/symas/lib/slapd -d 0 -h ${SLAPD_URLS} \ -u ${SLAPD_USER} -g ${SLAPD_GROUP} \ ${STAT_DYN} ${SLAPD_CONF} [Install] WantedBy=multi-user.target \end{
Auf einem Debian-System kopieren Sie das Service-Skript in das Verzeichnis /lib/systemd/-system/, auf einem Redhat-System in das Verzeichnis /usr/lib/systemd/system/.
Die hier verwendeten Variablen werden in dem Skript /etc/default/symas-openldap definiert. Wenn Sie eine andere Distribution als Debian nutzen, legen Sie das Verzeichnis /etc/-default an oder ändern Sie den Pfad passend zu Ihrer Distribution ab.
Fehlt nur noch die Datei symas-openldap mit den vordefinierten Variablen. Den Inhalt der Datei sehen Sie in Listing 3.4:
Listing 3.4 Konfiguration der Variablen für den Start
SLAPD_URLS="ldap:/// ldapi:/// ldaps:///" SLAPD_OPTIONS="" SLAPD_USER="openldap" SLAPD_GROUP="openldap" # Select static "-f" or dynamic "-F" STAT_DYN="-F" # To use static configuration #SLAPD_CONF="/opt/symas/etc/openldap/slapd.conf" # To use dynamic configuration SLAPD_CONF="/opt/symas/etc/openldap/slapd.d"
Hier wird gleich die dynamische Konfiguration eingestellt, und es werden alle drei möglichen Protokolle für den Zugriff auf den LDAP-Server aktiviert. Auch sehen Sie hier, dass der Benutzer und die Gruppe für den Start des Dienstes festgelegt wird.
Die dynamische Konfiguration
Nachdem Sie im vorigen Abschnitt gesehen haben, wie die Konfiguration über die Datei slapd.conf durchgeführt wird, zeigen wir Ihnen in diesem Abschnitt die dynamische Konfiguration.
Die dynamische Konfiguration wird in Form von LDIF-Dateien im Verzeichnis /opt/symas/etc/openldap/slapd.d abgelegt. In dem Verzeichnis finden Sie, nachdem Sie die Konfiguration eingespielt haben, weitere Unterverzeichnisse und LDIF-Dateien, denn die Konfiguration wird nicht in einem großen LDIF-File abgelegt, sondern setzt sich aus mehreren LDIF-Dateien zusammen. Die LDIF-Dateien sind dort nach Datenbanken und Inhalten in unterschiedlichen Verzeichnissen abgelegt. Beim Neustart des LDAP-Servers wird die Konfiguration aus den LDIF-Dateien geladen.
Jetzt stehen wir aber erst einmal vor dem Henne-Ei-Problem. Der slapd startet nicht ohne Konfiguration, und die Konfiguration wird über die ldap-Kommandos in den LDAP geschrieben. Aber der Dienst läuft nicht, weil keine Konfiguration da ist.
Aber zum Glück lässt sich das Problem recht einfach lösen. Mithilfe des Kommandos slapadd können Sie Daten in bestehende Datenbanken schreiben oder neue Datenbanken erstellen, ohne dass der slapd läuft. Sie benötigen lediglich eine LDIF-Datei, in der die Grundkonfiguration definiert ist, und können diese dann mit slapadd einspielen.
Warum klappt das? Die slap-Kommandos greifen direkt auf die Datenbankdateien zu und gehen nicht den Weg über das LDAP-Frontend slapd. Aus diesem Grund ist es auch wichtig, dass bei der Verwendung von slapadd der Dienst nicht läuft, da Sie sonst direkt in geöffnete Datenbankdateien schreiben würden. Daher können wir auch auf diesem Weg die Konfiguration in den OpenLDAP einspielen. Doch bevor wir die Konfiguration einspielen, werfen wir erst einmal einen Blick auf eine Konfigurationsdatei für die Grundkonfiguration und schauen uns einmal an, wo wir, parallel zur statischen Konfiguration, die Informationen finden. Listing 3.5 zeigt die Konfigurationsdatei im LDIF-Format:
Listing 3.5 LDIF-Datei mit den Grundeinstellungen
dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: argon2.la include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cX.... olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cM.... olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbMaxSize: 85899345920 olcAccess: {0} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {1} to attrs=shadowLastChange by anonymous auth by self write by * none olcAccess: {2} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read
Wenn Sie diese Einträge mit der statischen Konfiguration vergleichen, finden Sie hier alle Einstellungen wieder, nur werden jetzt die Informationen aus einer eigenen Datenbank gelesen. Jeder Teilbereich der Konfiguration wird in einem eigenen DN beschrieben, die einzelnen Bereiche werden für die folgenden Einstellungen benutzt:
dn: cn=config
Die Grundkonfiguration der globalen Konfiguration, auch in der statischen Konfiguration finden Sie diese Einträge im globalen Bereich wieder.
dn: cn=schema,cn=config
Auch die von Ihnen konfigurierten Schemata werden in der Konfigurationsdatenbank abgelegt und erhalten hierfür einen eigenen Bereich in Form eines DN.
dn: cn=module{0},cn=config
Hier handelt es sich um den Teil der Konfiguration, in dem alle benötigten Module eingetragen werden. Sie sehen hier, dass dort auch gleich das Modul für den Passwordhash ARGON2 eingetragen wird, damit der Hash auch schon für die Passwörter der rootdn verwendet werden kann. Im Verlauf des Buchs werden wir die Liste kontinuierlich erweitern.
dn: olcDatabase={-1}frontend,cn=config
Das ist der zweite Teil der globalen Konfiguration; hier können Sie schon ACLs festlegen, wer diesen Bereich verwalten darf. Auch werden hier ACLs eingetragen, die für alle Datenbanken auf dem LDAP-Server gelten sollen. Der Zugriff auf die oberste Ebene und auf die Schemata muss immer gewährleistet sein. Durch den Eintrag an dieser Stelle muss der Zugriff nicht immer für jede Datenbank einzeln vergeben werden.
dn: olcDatabase={1}monitor,cn=config
Hier sehen Sie die erste Datenbank, die nicht an eine feste Reihenfolge gebunden ist. Alle vorherigen DNs haben grundsätzlich immer dieselbe Nummer. Ab jetzt hängt die Nummerierung der Datenbanken immer davon ab, in welcher Reihenfolge Sie die Datenbank definieren. Deshalb ist es ganz wichtig, dass Sie ab jetzt bei jeder Änderung der Konfiguration genau auf die Nummerierung der Datenbanken achten.
Bei der Datenbank, die hier definiert wird, handelt es sich um die Datenbank, in der alle Aktionen, die ein Client auf dem LDAP-Server ausführt, protokolliert werden. Diese Daten können Sie in Ihrem Monitoring auswerten, und so haben Sie immer einen guten Überblick über den Zustand Ihres LDAP-Servers.
dn: olcDatabase={2}mdb,cn=config
Bei diesem DN handelt es sich jetzt um die Konfiguration der Objektdatenbank. Auch hier finden Sie alle Parameter aus der statischen Konfiguration wieder.
Eine Sache fällt sofort ins Auge: Die Parameter haben hier andere Namen und beginnen immer mit olc. Die Abkürzung steht für Open LDAP Configuration. Die Schreibweise der Parameter ist etwas anders; wenn Sie einen bestimmten Parameter suchen, finden Sie die Schreibweise immer in den LDIF-Dateien im Verzeichnis /opt/symas/etc/openldap/schema. Später können Sie auch in der dynamischen Konfiguration nach den Namen suchen, dazu muss der LDAP-Server aber erst laufen.
Hinweis: Wenn Sie bereits Erfahrung mit der dynamischen Konfiguration im Open-LDAP 2.4 gesammelt haben und dort auch schon andere Passworthashes nutzen, gibt es ab der Version 2.5 eine Änderung. Der Parameter olcPasswordHash befindet sich jetzt im DN dn: olcDatabase={-1}frontend,cn=config und nicht mehr im DN dn: cn=config.
Einen ganz wichtigen Punkt haben wir bis jetzt noch nicht angesprochen. In fast jedem Bereich der Konfiguration finden Sie die folgende ACL by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage. Was hat es damit auf sich? Diese ACL kann Ihnen das Leben, gerade am Anfang, etwas vereinfachen. Schauen wir uns die einzelnen Teile der ACL mal etwas genauer an:
dn.exact
Der folgende DN muss exakt mit dem hier angegebenen Wert übereinstimmen.
gidNumber=0+uidNumber=0
Die ACL trifft also auf den Benutzer mit der UID und GID 0 zu, also auf den root.
cn=peercred,cn=external,cn=auth
Hier wird eine im OpenLDAP vorkonfigurierte SASL-Authentifizierung verwendet. Diese Art der Authentifizierung ist nur lokal auf dem Server über den lokalen Socket ldapi möglich.
manage
Der Benutzer erhält den vollen Zugriff auf alle Objekte und Einträge.
Das heißt also, der Benutzer root hat direkt auf dem LDAP-Server vollen Zugriff auf alle Einträge, ohne sich zusätzlich mit einem Passwort authentifizieren zu müssen.
Hinweis: Diese Grundkonfiguration können Sie für alle folgenden LDAP-Server als Grundlage nehmen, denn hier sind noch keine rollenspezifischen Einstellungen enthalten.
Nachdem die Grundkonfiguration des OpenLDAP-Servers eingespielt ist, werden wir diese Art der Authentifizierung anhand des Kommandos ldapsearch erklären.
Einspielen der dynamischen Konfiguration
Kommen wir jetzt zur Lösung des Henne-Ei-Problems: das Einspielen der Konfiguration in die Datenbank. Wie vorher schon erwähnt, wird dafür das Kommando slapadd verwendet. Mithilfe des Kommandos slapadd können Sie Daten in verschiedenen Datenbanken des OpenLDAP einlesen. Daher benötigt das Kommando immer eine Zieldatenbank und eine Quelldatei, aus der die Informationen gelesen werden sollen. Neben diesen beiden Parametern wird ein weiterer Parameter benötigt, nämlich die Nummer der Datenbank, in die geschrieben werden soll. Da wir hier die Konfiguration schreiben wollen, ist das immer die Nummer 0. In Listing 3.6 sehen Sie das Kommando und die Ausgabe nach erfolgreicher Einspielung der Konfiguration:
Listing 3.6 Einspielung der initialen Konfiguration
root@provider01:~# slapadd -n0 -F /opt/symas/etc/openldap/slapd.d/ -l config.ldif Closing DB...
-n0
Hierbei handelt es sich um die Nummer der Datenbank innerhalb der Konfiguration.
-F /opt/symas/etc/openldap/slapd.d/
Das Zielverzeichnis für die Konfiguration.
-l config.ldif
Der Name (eventuell mit Pfad) der LDIF-Datei, in der sich die Konfiguration befindet.
Sollten Sie beim Einspielen der Konfiguration einen Fehler angezeigt bekommen, löschen Sie erst den Inhalt des Verzeichnisses /opt/symas/etc/openldap/slapd.d, bevor Sie einen erneuten Versuch starten.
Wichtig: Sie spielen die Konfiguration als Benutzer root ein, also gehören auch alle dabei entstandenen Dateien immer dem Benutzer root. Mit dem Kommando chown -R openldap: /opt/symas/etc/openldap/slapd.d/ ändern Sie den Besitzer und die besitzende Gruppe auf openldap. Erst dann können Sie den OpenLDAP mit dem Kommando systemctl start symas-openldap-server.service starten.
Erster Zugriff auf die dynamische Konfiguration
Nachdem Sie die Konfiguration eingespielt haben und der slapd mit der neuen Konfiguration läuft, können Sie jetzt auf den LDAP zugreifen. Schauen Sie sich aber als Erstes einmal in dem Verzeichnis /opt/symas/etc/openldap/slapd.d um. Dort finden Sie die gesamte Konfiguration, unterteilt in einzelne Verzeichnisse und LDIF-Dateien. Als Beispiel soll hier einmal ein Blick in die Datei cn=config/olcDatabase={2}mdb.ldif geworfen werden. Listing 3.7 zeigt den Inhalt der Datei:
Listing 3.7 Inhalt einer Konfigurationsdatei
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 1bf6383c dn: olcDatabase={2}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/symas/openldap-data olcSuffix: dc=example,dc=net olcAccess: {0} to attrs=userPassword by anonymous auth by self write \ by * none olcAccess: {1} to attrs=shadowLastChange by anonymous auth by self write \ by * none olcAccess: {2} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,\ cn=extern al,cn=auth manage by * read olcRootDN: cn=admin,dc=example,dc=net olcRootPW:: e0FSR09OMn0kYXJnb24yaSR2PTE5JG09NDA5Nix0PTMscD0xJGNYZGxjbkowZW5WNm RXbHZNVEl6JEcvbDBseW5mN3lnZHowdEcrRTdTMWZCaWJzRnMvTDgwQVVTaXNpR2wvdjQ= olcDbCheckpoint: 512 30 olcDbIndex: default eq olcDbIndex: objectClass olcDbMaxSize: 85899345920 structuralObjectClass: olcMdbConfig entryUUID: 238e0ba8-301e-103d-9d88-8b16491810fd creatorsName: cn=admin,cn=config createTimestamp: 20230124103225Z entryCSN: 20230124103225.801378Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20230124103225Z
Am Anfang der Datei steht der Hinweis, dass Sie die Datei nicht mit einem Editor bearbeiten sollen. Das ist auch richtig so, denn in der zweiten Zeile wird eine CRC32-Prüfsumme angezeigt. Wenn Sie die Datei mit einem Editor bearbeiten, ändert sich auch die Prüfsumme. Beim Starten des LDAP-Servers werden diese Prüfsummen aber kontrolliert. Wenn eine Prüfsumme einer Datei nicht stimmt, dann startet der LDAP-Server nicht mehr und zeigt auch im Log eine entsprechende Meldung an. Im Anschluss daran finden Sie alle Einstellungen der entsprechenden Datenbank, gefolgt von den internen Attributen, die der OpenLDAP für die Verwaltung dieser Datenbank benötigt.
Wenn Sie sich jetzt den Inhalt der Konfiguration ansehen wollen, benötigen Sie dafür das Kommando ldapsearch. In Listing 3.8 sehen Sie das Kommando mit einer gekürzten Ausgabe des Ergebnisses. Für die Authentifizierung verwenden wir hier den SASL-Mechanismus EXTERNAL unter Verwendung der lokalen Schnittstelle ldapi. Die Zugriffsrechte erhalten Sie hier über die vorher schon angesprochene ACL, nur als root:
Listing 3.8 Suche nach der Konfiguration
root@provider01:~# ldapsearch -Y EXTERNAL -H ldapi:/// \ -b cn=config -LLL | less dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/symas/run/slapd.args olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcToolThreads: 1 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor olcModuleLoad: {2}argon2.la ... dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/symas/openldap-data olcSuffix: dc=example,dc=net olcAccess: {0} to attrs=userPassword by anonymous auth by self write \ by * none olcAccess: {1} to attrs=shadowLastChange by anonymous auth by self write \ by * none olcAccess: {2} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,\ cn=extern al,cn=auth manage by * read olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXd.... ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcDbCheckpoint: 512 30 olcDbIndex: default eq olcDbIndex: objectClass olcDbMaxSize: 85899345920
-Y EXTERNAL
Immer, wenn der SASL-Mechanismus EXTERNAL Verwendung findet, wird für den angemeldeten Benutzer, der das Kommando ausführt, ein DN vom Wert gidNumber=<GID>+uidNumber=<UID>,cn=peercred,cn=external,cn=auth generiert. Die Art der Authentifizierung kann nur über den lokalen Socket ldapi:///verwendet werden. Es wird immer die GID und UID des Benutzers verwendet, der das Kommando ausführt, in diesem Fall der root. Wenn die Authentifizierung jetzt Rechte am LDAP über ACLs besitzt, kann der Benutzer die entsprechenden Aktionen ausführen.
-H ldapi:///
Eine Verbindung zum LDAP-Server über einen lokalen Socket.
-b "cn=config"
Das Backend, auf das zugegriffen werden soll.
Selbstverständlich können Sie auch über Netzwerk auf den LDAP zugreifen, dabei benötigen Sie aber immer einen ldap-Benutzer mit einem Passwort. Im Moment gibt es nur den rootdn. Mit dem Kommando aus Listing 3.9 können Sie auch über das Netzwerk auf den LDAP-Server zugreifen. Sie benötigen auf dem Client lediglich die entsprechenden ldaputils:
Listing 3.9 Zugriff mittels ldapsearch
root@provider01:~# ldapsearch -x -D cn=admin,cn=config -W \ -H ldap://provider01 -b cn=config Enter LDAP Password: ...
Bei der Abfrage werden Sie jetzt nach dem entsprechenden Passwort gefragt. Die einzelnen Parameter des Kommandos haben die folgenden Bedeutungen:
-x
Solange Sie noch keinen Kerberos-Server eingerichtet haben, um die Passwörter zu verwalten, werden Sie immer eine simple bind durchführen. Den Parameter -x geben Sie bitte immer mit an, wenn Sie eines der ldap-Kommandos nutzen und noch keinen Kerberos nutzen.
-D cn=admin,cn=config
Der Parameter -D, direkt gefolgt von einem DN eines Benutzers, gibt den Benutzer an, mit dem Sie den Zugriff auf den LDAP durchführen.
-W
Jeder Benutzer, der auf den LDAP zugreift, muss sich auch immer authentifizieren, dazu gehört auch ein Passwort. Mit -W werden Sie nach dem Abschicken des Kommandos nach dem Passwort gefragt. Hier wäre es auch möglich, das kleine -w geheim, gefolgt vom Passwort, anzugeben, dann wird das Kommando direkt ausgeführt. Denken Sie aber immer daran, dass das Kommando, inklusive des Passworts auch in der History steht und somit von jedem, der Zugriff auf den Rechner unter Ihrer Kennung hat, das Passwort ausgelesen werden kann.
-H ldap://provider01
Hier geben Sie den Namen des Servers an, auf den Sie zugreifen wollen. Im Moment geht das nur unverschlüsselt über das Protokoll ldap://, da TLS noch nicht eingerichtet ist.
-b cn=config
Über den Parameter können Sie den Kontext angeben, auf den Sie zugreifen wollen.
| 3.1.1 | Die Datei ldap.conf |
Alle ldap-Kommandos wie das Kommando ldapsearch benötigen immer die Information, auf welchen Server sie über welches Protokoll und auf welchen Kontext zugreifen sollen. Wollen Sie immer auf denselben Server und denselben Kontext zugreifen, können Sie diese Werte in der Datei/opt/symas/etc/openldap/ldap.conf festlegen. Später werden in der Datei auch noch die Bedingungen für die Verwendung von TLS eingetragen. Listing 3.10 zeigt den minimalen Inhalt, um die Zugriffe mit den ldap-Kommandos zu vereinfachen:
Listing 3.10 Minimale ldap.conf
BASE dc=example,dc=net URI ldap://provider01.example.net
Jetzt können Sie die ldap-Kommandos ohne die Angaben zu dem Server und dem Kontext nutzen. Wollen Sie einen anderen Server oder einen anderen Kontext ansprechen, können Sie die Einträge der ldap.conf mit der Verwendung der Parameter auf der Kommandozeile übersteuern.
Tipp: Wenn Sie mehrere LDAP-Server im Einsatz haben, können Sie bei dem URI auch mehrere, durch Leerzeichen getrennte Server angeben. Wenn dann der erste Server nicht erreicht werden kann, wird automatisch der nächste aus der Liste verwendet.
| 3.1.2 | Erste Änderungen an der Konfiguration |
Da sich die Konfiguration jetzt im LDAP befindet, können Sie Änderungen an der Konfiguration nur noch über LDIF-Dateien zusammen mit dem Kommando ldapmodify durchführen. In Listing 3.11 sehen Sie eine LDIF-Datei, mit der Sie die Passwörter der beiden rootdn-Einträge der Konfiguration ändern können:
Listing 3.11 LDIF-Datei zur Änderung der Passwörter
dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZHN2c.... dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZGJm....
Die Passwörter wurden mit dem Kommando argon2 erzeugt. Die Kommandos dazu sehen Sie in Listing 3.12:
Listing 3.12 Erzeugen eines ARGON2-Passworts
root@provider01:~# echo -n "geheim" | argon2 "dsvrevveebeeewceccq" -e $argon2i$v=19$m=4096,t=3,p=1$ZHN2.... root@provider01:~# echo -n "geheim" | argon2 "dbfgiknjbdvsgsavdsg" -e $argon2i$v=19$m=4096,t=3,p=1$ZGJm....
Bei der Zeichenkette im Kommando echo handelt es sich um das zu verschlüsselnde Passwort. Der Wert im Kommando argon2 ist der salt-Wert, der für die Bildung des Hashwerts genutzt wird. Je länger der salt-Wert ist, umso länger wird der Hash und um so sicherer ist das Passwort verschlüsselt.
Achten Sie beim Eintragen des Hashwerts in die LDIF-Datei darauf, dass Sie den Typ des Hashes in geschweiften Klammern vor den eigentlichen Hashwert schreiben müssen.
Mithilfe der LDIF-Datei wird sowohl das Passwort für den rootdn der Konfiguration als auch für den rootdn der Objektdatenbank gesetzt.
Jetzt können Sie die Änderung mit ldapmodify einspielen, so wie Sie es in Listing 3.13 sehen:
Listing 3.13 Einspielen der Passwortänderung
root@ldapserver:~# ldapmodify -Q -Y EXTERNAL -H ldapi:/// \ -f new-rootdn-pw.ldif modifying entry "olcDatabase={0}config,cn=config" modifying entry "olcDatabase={2}mdb,cn=config"
Im Anschluss können Sie das neue Passwort mit ldapsearch testen. In Listing 3.14 sehen die Kommandos zur Suche in der Konfiguration und in der Objektdatenbank:
Listing 3.14 Zugriff mit ldapsearch
root@provider01:~# ldapsearch -x -D cn=admin,cn=config -W -b cn=config Enter LDAP Password: .... root@provider01:~# ldapsearch -x -D cn=admin,dc=example,dc=net -W Enter LDAP Password: .... result: 32 No such object ....
Beim Zugriff auf die Objektdatenbank erhalten Sie noch den Fehler 32 No such object. Das Ergebnis war zu erwarten, da bis zu diesem Zeitpunkt noch keine Objekte im LDAP vorhanden sind.
Jede Änderung, die Sie in Zukunft an der Konfiguration vornehmen, werden Sie immer durch eine LDIF-Datei realisieren. Überlegen Sie genau, ob die Änderung in der globalen Konfiguration oder in einer der Datenbanken durchgeführt werden soll.
Modifizierungsarten in LDIF-Dateien
In Listing 3.11 haben wir Ihnen gezeigt, wie Sie den Wert eines Attributs ändern können. Mithilfe der LDIF-Dateien werden die Werte nicht nur geändert, sondern auch hinzufügt oder gelöscht. Bei der Verwendung von changetype: modify haben Sie folgende Möglichkeiten:
add
Mit add können Sie ein neues Attribut zu einem Objekt hinzufügen. Wenn es sich bei dem Attribut um ein single-value-Attribut handelt und das Attribut bereits vorhanden ist, erhalten Sie eine Fehlermeldung, und der Vorgang wird abgebrochen. Handelt es sich um ein multi-value-Attribut, wird dem Attribut ein zusätzlicher Wert hinzugefügt.
replace
Immer wenn Sie replace verwenden, wird ein bestehendes Attribut ersetzt. Handelt es sich um ein multi-value-Attribut, besteht die Änderung eines der Werte aus zwei Schritten. Mit dem ersten Schritt entfernen Sie den entsprechenden Wert, und mit dem zweiten Schritt können Sie dann den neuen Wert mit add oder replace hinzufügen.
delete
Mit delete können Sie ein Attribut eines Objekts komplett entfernen.
| 3.2 | Einspielen der ersten Objekte |
Da der LDAP-Server jetzt konfiguriert ist, können im nächsten Schritt die ersten Objekte eingespielt werden. Wenn Sie bereits Erfahrung in der Verwaltung von LDAP-Servern haben, kommt für Sie jetzt Inhaltlich nichts Neues, denn auch wenn die Konfiguration jetzt dynamisch ist, bleiben der Aufbau und die Verwaltung der Objektdatenbank identisch. Ist das Thema LDAP für Sie Neuland, dann erhalten Sie hier die ersten Einblicke in die Verwaltung der Objekte in einem LDAP-Baum. Die Grundlagen über den Aufbau eines LDAP-Baums haben wir ja bereits in den Grundlagen erklärt. Die Objekte in LDAP verwalten Sie über die ldap-Kommandos:
ldapadd
Mit ldapadd fügen Sie neue Objekte aus einer LDIF-Datei in den Baum ein.
ldapmodify
Mit ldapmodify können Sie bestehende Attribute eines Objekts ändern, löschen oder hinzufügen.
ldapdelete
Mit dem Kommando ldapdelete löschen Sie ganze Objekte im LDAP-Baum.
ldapmodrdn
Das Kommando ldapmodrdn kann dazu verwendet werden, den Relative Distinguished Name (RDN) zu ändern.
So kann der Name des Objekts dn: uid=pmueller,ou=users,dc=example,dc=net in zum Beispiel dn: uid=petermueller,ou=users,dc=example,dc=net geändert werden.
Alle diese Kommandos habe umfangreiche Manpages, in denen Sie viele zusätzliche Optionen und auch Beispiele finden.
Um nun die ersten Objekte einspielen zu können, benötigen Sie eine LDIF-Datei mit Objekten. Wir stellen Ihnen im Download zum Buch zwei verschiedene Dateien zur Verfügung. In der ersten Datei befinden sich nur die grundlegenden drei Einträge, um mit der Verwaltung von Objekten beginnen zu können. Sie sehen den Inhalt der Datei in Listing 3.15:
Listing 3.15 Inhalt der ersten LDIF-Datei
dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example dn: ou=users,dc=example,dc=net ou: users objectClass: top objectClass: organizationalUnit dn: ou=groups,dc=example,dc=net ou: groups objectClass: top objectClass: organizationalUnit
Hier wird lediglich der Container für den Suffix des LDAP-Baums und zwei Organizational Unit (OU)-Objekte für die Verwaltung von Benutzern und Gruppen angelegt.
In der zweiten LDIF-Datei befinden sich erheblich mehr Objekte, mit denen wir schon eine etwas tiefere Struktur aufbauen. Wir werden im Verlauf des Buches immer auf diese Struktur zurückgreifen. Wenn Sie also alle Beispiele 1:1 nachbilden wollen, können Sie diese LDIF-Datei einspielen. In Listing 3.16 sehen Sie auch hier den Inhalt der Datei:
Listing 3.16 LDIF-Datei für den ganzen Baum
dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example dn: ou=users,dc=example,dc=net ou: users objectClass: organizationalUnit dn: ou=groups,dc=example,dc=net ou: groups objectClass: organizationalUnit dn: ou=firma,dc=example,dc=net ou: firma objectClass: organizationalUnit dn: cn=benutzer,ou=groups,dc=example,dc=net objectClass: posixGroup gidNumber: 10000 cn: benutzer dn: ou=Verwaltung,ou=firma,dc=example,dc=net ou: Verwaltung objectClass: organizationalUnit objectClass: top dn: ou=Produktion,ou=firma,dc=example,dc=net ou: Produktion objectClass: organizationalUnit objectClass: top dn: ou=users,ou=Produktion,ou=firma,dc=example,dc=net ou: users objectClass: organizationalUnit objectClass: top dn: ou=Adressen,ou=Produktion,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=groups,ou=Produktion,ou=firma,dc=example,dc=net ou: groups objectClass: organizationalUnit objectClass: top dn: ou=Adressen,ou=Verwaltung,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=groups,ou=Verwaltung,ou=firma,dc=example,dc=net ou: groups objectClass: organizationalUnit objectClass: top dn: ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net ou: users objectClass: organizationalUnit objectClass: top dn: ou=Adressen,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: cn=u1 Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u1-prod uid: u1-prod cn: u1 Prod userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZG.... uidNumber: 10001 gidNumber: 10000 sn: Prod givenName: u1 dn: cn=u2 Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u2-prod uid: u2-prod cn: u2 Prod userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZG.... uidNumber: 10002 gidNumber: 10000 sn: Prod givenName: u2 dn: cn=prod al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/prod-al uid: prod-al cn: prod al userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZGJm.... uidNumber: 10003 gidNumber: 10000 sn: al givenName: prod employeeType: Abteilungsleiter dn: cn=u1 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u1-verw uid: u1-verw cn: u1 Verw userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZG.... uidNumber: 10004 gidNumber: 10000 sn: Verw givenName: u1 dn: cn=U2 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u2-verw uid: u2-verw cn: U2 Verw userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZG.... uidNumber: 10005 gidNumber: 10000 sn: Verw givenName: U2 dn: cn=Verw al,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/verw-al uid: verw-al cn: Verw al userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZG.... uidNumber: 10006 gidNumber: 10000 sn: al givenName: Verw employeeType: Abteilungsleiter dn: cn=verwaltung,ou=groups,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixGroup gidNumber: 10002 cn: verwaltung memberUid: u1-verw memberUid: u2-verw memberUid: verw-al dn: cn=produktion,ou=groups,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixGroup gidNumber: 10003 cn: produktion memberUid: prod-al memberUid: u1-prod memberUid: u2-prod dn: ou=Adressen,cn=u1 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=U2 Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=Verw al,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=prod al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=u1 Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=u2 Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top
Hinweis: Alle in der LDIF-Datei vorhandenen Passwörter lauten geheim. Sie können die Passwörter für die Tests übernehmen oder vorher mit dem Kommando echo -n "ganzgeheim" | argon2 "salt123salt" -n neue Passwörter erstellen und das Ergebnis an den entsprechenden Stellen eintragen.
In Listing 3.17 sehen Sie das Hinzufügen der Objekte:
Listing 3.17 Einspielen der Objekte
root@provider01:~# ldapadd -Y EXTERNAL -H ldapi:/// -f ldap-buch-komplett.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "dc=example,dc=net" adding new entry "ou=users,dc=example,dc=net" adding new entry "ou=groups,dc=example,dc=net" adding new entry "cn=benutzer,ou=groups,dc=example,dc=net" ...
Tipp: Sollten Sie sich beim Anlegen der LDIF-Datei vertippt haben, kommt es an der Stelle beim Anlegen des entsprechenden Objekts zu einer Fehlermeldung, und der Prozess wird abgebrochen. Nachdem Sie den Fehler behoben haben und das Kommando wieder genauso wie beim ersten Mal verwenden, wird das ldapadd feststellen, dass die ersten Objekte bereits existent sind, und bricht den Vorgang ab. Sie brauchen dann nicht alle bereits angelegten Objekte aus der LDIF-Datei entfernen oder auskommentieren, sondern Sie können einfach den zusätzlichen Parameter -c an das Kommando anhängen. Der Parameter sorgt dafür, dass bereits existente Objekte übersprungen werden.
Um die gerade erstellten Objekte sehen zu können, verwenden Sie das Kommando ldapsearch. In Listing 3.18 sehen Sie die Abfrage:
Listing 3.18 Auflisten aller Objekte
[root@ldapserver ~]# ldapsearch -x # extended LDIF # # LDAPv3 # base <dc=example,dc=net> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.net dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example # users, example.net dn: ou=users,dc=example,dc=net ou: users objectClass: top objectClass: organizationalUnit # groups, example.net dn: ou=groups,dc=example,dc=net ou: groups objectClass: top objectClass: organizationalUnit ...
Die Anzeige wird hier im erweiterten LDIF-Format angezeigt. Wie Sie sehen, werden neben den Informationen zu den Objekten auch noch weitere Informationen und Kommentare angezeigt. Sie können diese Ausgabe mit bis zu dreimaliger Verwendung des Parameters-L anpassen. Ein -L sorgt für eine Ausgabe der Objekte im LDIv1-Format. Ein zweites -LL unterbindet zusätzlich alle Kommentare, und ein drittes -LLL unterbindet auch noch die Ausgabe des LDIF-Formats. In Listing 3.19 sehen Sie die verkürzte Ausgabe:
Listing 3.19 Verkürzte Ausgabe
root@provider01:~# ldapsearch -x -LLL dn dn: dc=example,dc=net dn: ou=users,dc=example,dc=net dn: ou=groups,dc=example,dc=net dn: cn=benutzer,ou=groups,dc=example,dc=net dn: ou=Verwaltung,ou=firma,dc=example,dc=net dn: ou=Produktion,ou=firma,dc=example,dc=net
Bei der Syntax zum Kommando ldapsearch fällt auf, dass kein Benutzername und kein Passwort übergeben wird. Die Abfrage findet anonym statt. Das ist im Moment noch möglich, sollte aber in einer Produktivumgebung niemals möglich sein. Auch wir werden später, mithilfe von ACLs, die Zugriffsrechte einschränken und keine anonymen Zugriffe mehr zulassen.
Wiederholen Sie das Kommando, nur dieses Mal ohne den Filter dn, dann sehen Sie alle Objekte mit fast allen Attributen. Was auffällt: Die Passwörter werden nicht angezeigt. Die sind auch in der Grundkonfiguration schon durch eine ACL geschützt.
Führen Sie die Suche erneut durch, verwenden aber jetzt den rootdn ldapsearch -x -D cn=admin,dc=example,dc=net -W-LLL der Objektdatenbank für den Zugriff, dann werden Ihnen die Passwörter wieder angezeigt. Dabei fällt auf, dass die Passwörter nicht so angezeigt werden, wie Sie sie in die LDIF-Datei eingetragen haben. Das liegt daran, dass Werte mit Sonderzeichen im LDAP immer BASE64-kodiert abgelegt werden. Sie können sich den Wert aber mit dem Kommando echo "base64-wert" | base64 -d im Original anzeigen lassen.
Hinweis: Wenn Sie LDIF-Dateien erstellen, achten Sie immer darauf, dass sich am Ende der Zeile kein Leerzeichen befindet. Ein Leerzeichen am Ende der Zeile ist auch ein Sonderzeichen. Dann wird der Wert auch BASE64-kodiert im LDAP abgelegt. Wenn Sie mit dem vi arbeiten, können Sie sich mit dem Kommando : set list alle Sonderzeichen anzeigen lassen. Dann sehen Sie auch eventuelle Leerzeichen am Ende der Zeile und können sie entfernen.
Jetzt haben Sie den ersten LDAP-Server erfolgreich eingerichtet und mit den ersten Objekten ausgestattet.