====== Ziel ====== Das vorliegende Howto dient dem Zwecke, ein möglichst umfangreiches Wissen bezüglich der Installation und des Betriebes eines OpenLDAP Servers bereit zu stellen und soll Ihnen darüber hinaus die Anbindung verschiedener Dienste an den OpenLDAP Server erläutern. \\ \\ Ein wesentlicher Aspekt diese Howtos ist es das (noch) relativ neue Konfigurationsschema des OpenLDAP Servers zu verwenden, welches im DIT des Servers selbst abgelegt ist und die gute alte ''/etc/openldap/slapd.conf'' ablöst. Ein wesentlicher Vorteil dieser Art der Konfiguration ist es, dass die meisten Änderungen an der Konfiguration umgehend von OpenLDAP übernommen werden, ohne dass ein Neustart des Servers notwendig ist. \\ \\ Obgleich dieses Howto unter der Verwendung eines Gentoo-Systems erstellt wurde, sollte es Ihnen möglich sein, die nachfolgend beschriebenen Vorgehensweisen auf anderen Linux-Derivaten durch zu führen. Selbstverständlich werden hierfür an der einen oder anderen Stelle Anpassungen von nöten sein. \\ \\ Für diese Howto wurde das folgende System verwendet: ^ Software ^ Version ^ |OS | Gentoo 2007.0 | |Kernel | 2.6.23-r3 | |OpenLDAP | 2.3.39-r1 | \\ ====== Grundlegendes ====== Bitte beachten Sie bei der Verwendung dieses Howtos die folgenden Punkte: * Lesen Sie den Abschnitt, welchen Sie grade bearbeiten erste zu ende, bevor Sie die darin aufgeführten Kommandos ausführen. Es kommt vor, dass nach dem Kommando selbst nocht wichtige Informationen zu diesem angegeben werden, welche Sie bei der Ausführung des jeweiligen Kommandos berücksichtigen müssen. * Arbeiten Sie langsam und bedacht, Eile führt nicht selten zu Fehlern. * Führen Sie alle ''emerge''-Aufrufe zunächst immer mit dem ''--pretend''-Parameter aus, um überprüfen zu können, was genau installiert werden wird und mit welchen USE-Flags die jeweilige Software kompiliert wird. * Im Laufe dieses Howtos werden Sie beim Installieren von Software immer wieder diverse Packete von Portage aufgelistet bekommen, welche auf Grund von Abhängigkeiten ebenfalls installiert werden müssen und welche nicht in diesem Howto aufgeführt sind. Dies ist vollkommen in Ordnung und Sie können diese getrösst zum jeweiligen Zeitpunkt von Portage mit installieren lasse. * Sollten Sie dieses Howto zur Installation des OpenLDAP unter einem anderen Linux verwenden, so können Sie die jeweils angegebenen USE-Flags für die einzelnen Packete als Anhaltspunkt verwenden, welche binäre Packete oder welche Configure-Parameter Sie berücksichtigen sollten. \\ ====== Querverweise ====== Dieses Howto wird Themen aufgreiffen, welche in anderen, in diesem Wiki verfügbaren Howtos behandelt werden. Obgleich an den entsprechenden Stellen erwähnt, sollen diese hier aufgeführt werden. \\ ===== OpenSSL ===== Im Laufe dieses Howtos wird erklärt werden, wie der OpenLDAP Server mittels Zertifikaten abgesichert werden kann. Hierzu ist neben der Erstellung einer eigenen CA auch das Wissen um den Umgang mit dieser von nöten. Dies alles ist im [[howtos:linux:security:openssl|OpenSSL Howto]] beschrieben. \\ ====== Voraussetzungen ====== Diese Howto geht davon aus, dass die folgenden Voraussetzungen erfüllt sind. * Ihr Linux (Gentoo) ist auf einen aktuellen Stand \\ Ferner wurden die folgenden, globalen USE-Flags gesetzt. ... USE="symlink ssl sasl doc" ... \\ ====== Abhängigkeiten ====== Bevor OpenLDAP installiert werden kann, müssen zunächst die folgenden Packete installiert werden. - MIT-Kerberos - Courier-Authlib - Courier-IMAP - Cyrus-SASL - CUPS - Samba \\ ===== MIT-Kerberos ===== Dieses Packet stellt die Kerberos-Implementierung des MIT zur Verfügung. Es wird benötigt, damit Cyrus-SASL mit Kerberos (GSSAPI) - Unterstützung kompiliert werden kann. \\ Der Vollständigkeit halber sei an dieser Stelle erwähnt, dass Gentoo per default zwei Kerberos-Implementierungen zur Verfügung stellt. Diese sind neben dem MIT-Kerberos noch der Heimdal, welcher die Kerberos 5 Implementierung von KTH darstellt. Welche der beiden Implementierungen zur Anwendung kommt, spielt eigentlich keine Rolle. Wir haben uns jedoch für die Implementierung des MIT entschieden, da sie die wohl gängigste Implementierung im Open Source Umfeld darstellt. \\ \\ Die Installation erfolgt unter Verwendung des folgenden Kommandos. # emerge --verbose mit-krb5 \\ ===== Courier-Authlib ===== Dieses Packet wird von Cyrus-SASL benötigt und sollte vor dessen Installation bereits auf dem System vorhanden sein. Ist dies nicht der Fall, so wird es mit Cyrus-SASL installiert. Es soll an dieser Stelle jedoch Erwähnung finden, da dieses wiederum gegen OpenLDAP gebunden werden kann. Zunächst muss die Datei ''/etc/portage/package.use/courier-authlib'' mit den entsprechenden USE-Flags erstellt werden. # cat > /etc/portage/package.use/courier-authlib << "EOF" net-libs/courier-authlib -gdbm EOF Um Courier-Authlib mit LDAP-Unterstützung zu kompilieren ist es erforderlich, dass das ''ldap'' Schlüsselwort in der obigen Datei eingetragen wird. Dies kann allerdings erst geschehen, wenn OpenLDAP installiert ist. Des weiteren muss die Software dann neu kompiliert werden. Bevor Courier-Authlib installiert wird, sollte noch ''expect'' aufgespielt werden. Dieses Packet wird von Courier-Authlib benötigt, um System-Passwörter ändern zu können. Dies ist zwar nicht zwinged notwendig, verhindert aber eine entsprechende Warnung beim Kompilieren von Courier-Authlib. # emerge --verbose expect Installieren Sie anschliessend Courier-Authlib mit dem folgenden Kommando. # emerge --verbose courier-authlib \\ ===== Courier-IMAP ===== ??? Courier-IMAP ??? Klingt komisch, ist aber so... ;-) \\ \\ Der ''authdaemon'' implementiert einen Dienst, welcher es ermöglicht, möglichst einfach auf die gängigsten SASL-Authentifizierungs- und -Authorisierungs-Mechanismen zuzugreiffen. Da wir Cyrus-SASL die Anweisung geben werden, den ''authdaemon'' zu erstellen und zu installieren, wird dieses Packet benötigt, da es im Gentoo-spezifischen ''ebuild'' als Requirement hierfür vermerkt ist. Sollten Sie bereits wissen, dass Sie den ''authdaemon'' nicht benötigen, können Sie dieses Packet auslassen. Allerdings müssen Sie dann die USE-Flags für Cyrus-SASL im nächsten Abschnitt entsprechen anpassen (''-authdaemon'')! Zum Zeitpunkt der Erstellung dieses Howtos wurde bei der Installation von Courier-IMAP bereits darauf hingewiesen, dass der ''Authdaemond'' von Packet Courier-IMAP in das Packet Courier-Authlib verschoben wurde. Dies bedeutet, dass das Cyrus-SASL Ebuild noch nicht entsprechend aktualisiert worden ist. \\ \\ Bitte überspringen Sie zunächst die Installation von Courier-IMAP und führen Sie die von Cyrus-SASL wie im nächsten Abschnitt beschrieben aus. Ergänzen Sie den Aufruf von emerge um den ''--pretend''-Parameter und überprüfen Sie, ob diese Abhängigkeit nach wie vor besteht. Besteht sie nicht mehr, ist es nicht mehr notwendig, Courier-IMAP zu installieren. Ebenso wie für Courier-Authlib werden wir auch für Courier-IMAP die Unterstützung für ''GDBM'' deaktivieren. Hierzu müssen zunächst die entsprechenden USE-Flags gesetzt werden. # cat > /etc/portage/package.use/courier-imap << "EOF" net-mail/courier-imap -gdbm EOF Installieren Sie anschliessend Courier-IMAP mit dem folgenden Kommando. # emerge --verbose courier-imap \\ ===== Cyrus-SASL ===== Dieses Packet wird vom OpenLDAP Server benötigt, um die Authentifizierung, sowie die Authorisierung eines Clients mittels des SASL-Protokolls zu ermöglichen. Zunächst muss die Datei ''/etc/portage/package.use/cyrus-sasl'' erstellt werden, um die entsprechenden USE-Flags setzen zu können. # cat > /etc/portage/package.use/cyrus-sasl << "EOF" dev-libs/cyrus-sasl authdaemond kerberos sample -gdbm EOF Um SASL zum Zwecke von Authentifizierung und Authorisierung an den OpenLDAP anbinden zu können, ist es notwendig, dass nachdem der OpenLDAP Server installiert ist, der obige Dateiinhalt um das Schlüsselwort ''ldap'' erweitert wird und die Software anschliessend neu erstellt wird. Installieren Sie anschliessend das Packet mit dem folgenden Kommando. # emerge --verbose cyrus-sasl * You need to add a user running a service using Courier's * authdaemon to the 'mail' group. For example, do: * gpasswd -a postfix mail * to add the 'postfix' user to the 'mail' group. Nach erfolgreicher Installation weist uns Portage noch darauf hin, dass das Benutzerkonto unter welchem ein Dienst ausgeführt wird, der den ''Authdaemon'' verwenden soll, der ''Mail''-Gruppe hinzuzufügen ist. Diesen Hinweis sollten Sie beachten! \\ ===== CUPS ===== CUPS wird von Samba benötigt. Sie können diese Abhängigkeit auch umgehen, indem Sie mittels ''-cups'' in den USE-Flags zu Samba die Unterstützung von CUPS deaktivieren. Bitte nehmen Sie sich die Zeit und lesen Sie den Abschnitt über die Installation von Samba bevor Sie an dieser Stelle fortfahren. Unter Umständen - wenn Sie Samba nur minimal installieren - können Sie CUPS überspringen! Zunächst muss die Datei ''/etc/portage/package.use/cups'' erstellt und die benötigten USE-Flags (in unserem Fall keine) gesetzt werden. # cat > /etc/portage/package.use/cups << "EOF" net-print/cups EOF Sollten Sie planen, in CUPS die LDAP-Unterstützung zu aktivieren, so müssen Sie nach der Erfolgreichen Installation des OpenLDAP Servers dieser Datei noch das Schlüsselwort ''ldap'' anhängen und CUPS erneut kompilieren. \\ Vor der Installation von OpenLDAP ist dies noch nicht möglich! Installieren Sie Samba mit dem folgenden Kommando. # emerge --verbose cups \\ ===== Samba ===== Sie mögen sich nun vielleicht fragen, warum die Samba-Unterstützung in OpenLDAP aktiviert werden soll. Um OpenLDAP in die Lage zu versetzen, LanMan/NTLM Passwörter verarbeiten zu können, wird diese Unterstützung benötigt. Diese Passwörter kommen z.B. dann zum Einstatz, wenn ein Samba Server den OpenLDAP Server als Backend für die Benutzer-, Gruppen-, und Computerdaten verwenden soll. Ein weiteres Beispiel ist Radius. Kommt dieser in Ihrem Netz zum Einsatz, so ist es recht wahrscheinlich, dass Sie die Passwörter Ihrer Benutzer in genau dieser Form vorliegen haben müssen. Zunächst muss die Datei ''/etc/portage/package.use/samba'' erstellt werden. Diese muss erstellt und der folgende Inhalt darin gespeichert werden. # cat > /etc/portage/package.use/samba << "EOF" net-fs/samba automount doc examples fam kerberos quotas swat syslog winbind oav EOF * Sollten Sie planen, den Samba-Server ebenfalls an OpenLDAP anzubinden, so müssen Sie nach der Erfolgreichen Installation des OpenLDAP Servers dieser Datei noch das Schlüsselwort ''ldap'' anhängen und Samba erneut kompilieren. Vor der Installation von OpenLDAP ist dies noch nicht möglich! * Wissen Sie bereits jetzt, dass Sie Samba nur zum Zwecke der Unterstützung in OpenLDAP installieren, so können Sie auch alle USE-Flags für Samba deaktivieren, wodurch deutlich weniger Packete installiert werden müssen. Installieren Sie Samba mit dem folgenden Kommando. # emerge --verbose samba \\ ====== Installation ====== Nun, da alle Voraussetzungen erfüllt sind, gilt es, OpenLDAP auf Ihrem System zu installieren. Um dies zu bewerkstelligen ist zunächst die Datei ''/etc/portage/package.use/openldap'' wie folgt zu erstellen. # cat > /etc/portage/package.use/openldap << "EOF" net-nds/openldap kerberos overlays samba sasl slp -smbkrb5passwd berkdb crypt perl readline ssl tcpd -debug -gdbm -ipv6 -minimal -selinux EOF Es ist möglich, eine SQL-Datenbank als Backend für den OpenLDAP Server zu verwenden. Zwar geht die Konfiguration eines solchen Szenarios über den Umgang dieses Howtos hinaus, ist dies jedoch gewünscht, so muss noch das ''odbc''-USE-Flag in der oben genannten Datei angehängt werden. Anschliessend wird OpenLDAP installiert. # emerge --verbose openldap \\ ====== Konfiguration ====== Dieser Abschnitt dient dazu, jegliche Konfiguration vorzunehmen, welche notwendig ist, bevor der OpenLDAP Server das erste mal regulär gestartet werden kann. \\ ===== LDAP-Server ===== Wie bereits einleitend erwähnt, werden wir in diesem Howto die in seit OpenLDAP 2.3 verfügbare Laufzeitkonfiguration verwenden. Dies bedeutet, dass wir unsere Konfiguration nicht mehr wie gewohnt in der Datei ''/etc/openldap/slapd.conf'' vornehmen, sondern im DIT, welcher uns von OpenLDAP zur Verfügung gestellt wird. OpenLDAP legt hierzu eine eins-zu-eins Kopie der Konfigurationsdaten im LDIF-Format hierarchisch in Textdateien unterhalb von ''/etc/openldap/slapd.d'' ab. Selbstverständlich lässt sich auch ein anderer Root-Ordner wählen, Standard ist aber der erwähnte. \\ \\ Betrachtet man nun den Inhalt des Ordners ''/etc/openldap'' so fällt auf, dass dieser Ordner noch gar nicht existiert. Hieraus erhält, dass erwähnte LDIF-formatierte Konfiguration noch gar nicht existiert und von uns erstellt werden muss. \\ Der OpenLDAP Server Dämon ''sladpd'' kann zu diesem Zwecke instruiert werden, dies Struktur zu erstellen, wobei der aktuellen Inhalt der ''slapd.conf'' bei der Erstellung verwendet wird. \\ ==== Vorbereitungen ==== Bevor wir die ''slapd.conf'' zur Erzeugung der notwendigen Konfigurations-Struktur verwenden, nehmen wir einige grundlegende Änderungen an der ''slapd.conf'' Konfigurationsdatei vor, damit diese bereits beim Erstellen der benötigten Konfigurations-Datei-Struktur mit übernommen werden. Hierzu werden wir unter anderem die Root-Suffixe für unseren DIT, sowie das Passwort unseres Super-Admin-Accounts anpassen. \\ \\ Wir weden die folgenden zwei Suffixe erstellen. * cn=logs * dc=mydomain,dc=logs \\ Ersterer Suffix wird später in diesem Howto dazu verwendet werden, mittels des ''AccessLog''-Overlays Operationen am Suffix ''dc=mydomain,dc=logs'' zu loggen. Allerdings ist es notwendig, dass dieser Suffix beim Starten von OpenLDAP vor den Suffixen geladen wird, für welche geloggt werden soll. Ist dies nicht der Fall, verweigert der OpenLDAP Server den Start mit einer entsprechenden Fehlermeldung. Da es wirklich sehr viel einfacher ist, die Konfiguration für diesen Suffix gleich an erster Stelle mit kreieren zu lassen, als die Reihenfolge beim Starten später von Hand zu ändern, tun wir dies auch. \\ \\ Wir beginnen damit, dass wir uns ein neues Passwort für den Admin-Account erstellen. # slappasswd -h {MD5} Wir werden sodann aufgefordert werden, ein neues Passwort einzugeben und dieses zu bestätigen. Das Ergebniss für das Wort ''Test'' - welches wir für dieses Howto verwenden - sieht z.B. wie folgt aus: {MD5}DLxmEfVUC9CAmjiNyVphWw== Öffnen Sie nun die Datei ''/etc/openldap/slapd.conf'' mit einem Texteditor und passen Sie die im Folgenden gezeigten Parameter an. Den Rest der Datei können Sie im Originalzustand belassen. modulepath /usr/lib/openldap/openldap moduleload back_hdb.so suffix "dc=logs rootdn "cn=Manager,logs rootpw {MD5}DLxmEfVUC9CAmjiNyVphWw== directory /var/lib/openldap-data-logs Hängen Sie der selben Datei anschliessend diesen Inhalt ganz am Ende an. ####################################################################### # BDB database definition for dc=mydomain,dc=local ####################################################################### database hdb suffix "dc=mydomain,dc=local" checkpoint 32 30 # rootdn "cn=Manager,dc=mydomain,dc=local" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {MD5}DLxmEfVUC9CAmjiNyVphWw== # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/openldap-data-mydomain.local # Indices to maintain index objectClass eq Nachdem Sie diese Änderungen vorgenommen und abgespeichert haben, müssen die für den Parameter ''directory'' angegebenen Ordner und der Ordner, welcher die Datenbankdateien beherbergen wird, erstellt werden, sowie Besitz und Rechte richtig gesetzt werden. # mkdir /var/lib/openldap-data-logs && /var/lib/openldap-data-mydomain.local && mkdir /etc/openldap/slapd.d # chown ldap.ldap /var/lib/openldap-data-logs && chown ldap.ldap /var/lib/openldap-data-mydomain.local && chown ldap.ldap /etc/openldap/slapd.d # chmod 700 /var/lib/openldap-data-logs && chmod 700 /var/lib/openldap-data-mydomain.local && chmod 750 /etc/openldap/slapd.d Nun, da alle notwenidigen Ordner erstellt sind, ist es an der Zeit, sowohl die Konfigurationsstruktur, wie auch die initialen Datenbankdateien zu erstellen. Stellen Sie jedoch unbedingt sicher, dass keine Instanz von ''slapd'' ausgeführt wird. \\ \\ Um nun also alle benötigten Dateien und Strukturen zu erstellen, führen Sie das folgende Kommando aus. # /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d Dies sollte keinen Fehler zurückgeben. Werfen Sie nun einen ersten Blick in den Konfigurationsordner. # ls -al /etc/openldap/slapd.d/ total 16 drwxr-x--- 3 ldap ldap 4096 Dec 22 22:38 . drwxr-xr-x 4 root root 4096 Dec 22 22:36 .. drwxr-x--- 3 root root 4096 Dec 22 22:38 cn=config -rw------- 1 root root 1007 Dec 22 22:38 cn=config.ldif Sehr gut, die initiale Konfiguration ist erstellt. Stoppen Sie den ''slapd''-Dämon nun wieder. # kill -s 15 `pidof slapd` Führen Sie anschliessend noch das folgende Kommando aus, um sicherzustellen, dass der Dämon auch wirklich beendet wurde. Dies ist für den weiteren Verlauf dieses Howtos unabdingbar. # pidof slapd Wird Ihnen eine leere Zeile ausgegeben, so wurde der Dämon erfolgreich beendet. Wenn nicht, versuchen Sie ''kill -9 `pidof slapd`''. \\ ==== cn=config ==== Wie bereits erwähnt, stellt die mittlerweile erstellte Konfigurationsstruktur den Konfigurations-DIT dar, welcher im OpenLDAP Server zur Laufzeit unter dem Suffix ''cn=config'' verfügbar sein wird. Bevor der Server aber das erste mal gestartet wird, müssen noch die ein oder andere Änderung vorgenommen werden. \\ So muss beispielsweise der Admin-User mit einem Passwort versehen werden, welches später zur Anmeldung am Konfigurationssuffix verwendet werden wird. Öffnen Sie hierzu die Datei ''/etc/openldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif'' und ergänzen Sie sie um die folgenden Einträge unterhalb des ''olcRootDN''-Parameters. olcRootDN: cn=config olcRootPW: {MD5}DLxmEfVUC9CAmjiNyVphWw== Achten Sie darauf, auch hier ein eigenes Passwort zu erzeugen. Das hier verwendete ist wieder der Hashwert von ''Test''. \\ ==== Start-Parameter ==== Es ist notwendig, dass man dafür sorge trägt, dass dem ''slapd'' Daemon beim Starten alle notwendigen Information in form von Parametern übergeben wird. Hierzu ist die Datei ''/etc/conf.d/slapd'' zu editieren. Sie sollte wie folgt abgespeichert werden. # conf.d file for openldap # # To enable both the standard unciphered server and the ssl encrypted # one uncomment this line or set any other server starting options # you may desire. # # OPTS="-h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" # Uncomment the below to use the new slapd configuration for openldap 2.3 #OPTS="-F /etc/openldap/slapd.d -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" OPTS="-F /etc/openldap/slapd.d -h 'ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" Beachten Sie, dass der Wert des ''-h'' Parameters gändert wurde. ''%%ldaps://%%'' wurde entfernt. Dies ist notwendig, da SSL/TLS zum jetztigen Zeitpunkt noch nicht konfiguriert ist. \\ ==== Rechte/Besitz ==== Nun müssen wir die Rechte und den Besitz auf die Konfigurations-Strucktur und auf die Datenbankdateien unseres DITs nochmals neu setzen. # chown -Rfv ldap.ldap /etc/openldap/slapd.d # chmod -Rfv 700 /etc/openldap/slapd.d/* # chown -Rfv ldap.ldap /var/lib/openldap-data-logs # chown -Rfv ldap.ldap /var/lib/openldap-data-mydomain.local \\ ==== Bereinigen ==== Der OpenLDAP Server wie er bis hierhin konfiguriert wurde, verfügt noch über den Eintrag ''cn=include{0},cn=config'' im Konfigurations-Suffix, welcher nicht mehr benötigt wird und somit gelöscht werden kann. Um diesen zu löschen, führen Sie das folgende Kommandos aus. # rm -fv /etc/openldap/slapd.d/cn\=config/cn\=include\{0\}.ldif \\ ===== LDAP-Client ===== OpenLDAP installiert nicht nur den LDAP-Server, sondern ebenfalls eine Sammlung an LDAP-Client-Tools. ''ldapsearch'' und ''ldapadd'' waren z.B. solche. Diese Tools müssen nun noch ebenfalls konfiguriert werden. \\ Hierzu passen wir den Inhalt der Datei ''/etc/openldap/ldap.conf'' dahingehen an, dass nur die folgenden Parameter gesetzt sind. BASE dc=mydomain,dc=local URI ldap://127.0.0.1 \\ ====== Inbetriebnahme ====== Nun ist es an der Zeit, unseren OpenLDAP das erste mal zu starten. # /etc/init.d/slapd start Die Angabe dieses Pfades kann umgangen werden, indem man sich eine ''Shortcat'' generiert. Ich beispielsweise lege mir immer nach guter alter SUSE-Manier einen ''rc''-Shortcat an. Für OpenLDAP etwa ''rcslapd''. Man kann diesen erstellen, indem man das Kommando ''ln -s /etc/init.d/slapd /usr/sbin/rcslapd'' ausführt. Anschliessend kann der OpenLDAP Server ganz einfach z.B. wie folgt gesteuert werden. # rcslapd {start|stop|restart|pause|zap} In diesem Howto wird fortan die ''rcslapd''-Variante verwendet werden! Antwortet das Startskript mit einem ''OK'' so haben Sie es geschafft, der OpenLDAP Server läuft. \\ ====== Grundstruktur ====== An dieser Stelle wird der DIT des OpenLDAP Servers zunächst einmal mit ein paar initialen Daten befüllt. \\ Dies erfolgt aus mehreren Gründen. - Sehen Sie mal was, wenn Sie den DIT mit einem graphischen Client-Tool betrachten - Gibt es Ihnen ein Gefühl dafür, wie ein einfacher DIT aufgebaut sein kann - Wird die Existenz bestimmter Einträge im DIT im weitern Verlauf dieses Howtos vorausgesetzt. \\ Erstellen Sie hierzu eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''structure_init.ldif'' ab. dn: dc=mydomain,dc=local objectClass: dcObject objectClass: organization dc: mydomain o: YOUR_COMPANY_NAME_HERE dn: ou=Config,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Config dn: ou=Groups,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Groups dn: ou=People,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: People dn: ou=Special Users,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Special Users Fügen Sie anschliessend diese Daten in den DIT ein. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/structure_init.ldif Enter LDAP Password: adding new entry "dc=mydomain,dc=local" adding new entry "ou=Config,dc=mydomain,dc=local" adding new entry "ou=Groups,dc=mydomain,dc=local" adding new entry "ou=People,dc=mydomain,dc=local" adding new entry "ou=Special Users,dc=mydomain,dc=local" \\ ====== Test ====== Nun, da der OpenLDAP Server läuft und mit einer Grundstruktur versehen wurde, ist es an der Zeit, einen ersten Test durch zu führen. Hierzu führen Sie bitte das folgende Kommando aus. # ldapsearch -D "cn=Manager,dc=mydomain,dc=local" -x -W -LLL objectclass=* Enter LDAP Password: dn: dc=mydomain,dc=local objectClass: dcObject objectClass: organization dc: mydomain o: YOUR_COMPANY_NAME_HERE dn: ou=Config,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Config dn: ou=Groups,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Groups dn: ou=People,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: People dn: ou=Special Users,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: Special Users \\ ====== Schema ====== Sie haben in diesem Howto schon viele male mit LDAP-Attributen, sowie LDAP-Objekklassen gearbeitet. Ein LDAP-Objekt definiert dabei immer, welche Attribute ein Eintrag im DIT haben muss und welche er haben kann, wenn im die jeweilige Objekklasse zugewiesen ist. Welche Attribute und Objektklassen der OpenLDAP Server überhaupt kennt, ist im sogenannten ''Schema'' des Servers festgelegt. Diese Schema lässt sich bei OpenLDAP prinzipiell in zwei Kategorien unterscheiden. * OpenLDAP Konfigurationsschema * Zusätzliche Schematas Wärend das OpenLDAP Konfigurationsschema statisch ist und somit nicht geändert werden kann, sind die zusätzlichen Schematas variabel und können hinzugefügt und auch wieder entfernt werden. Dies bedeutet, dass sich bei einem Schema immer um eine Ansammlung von Attribut- und/oder Objek-Klassen-Definition handelt. Es sind bereits viele verschiedene Schematas verfügbar wovon einige bereits zum Defakto-Standard geworden, andere sehr weit verbreitet und wieder andere immerhin sehr bekannt sind. \\ \\ In diesem Abschnitt werden einige davon vorgestellt werden. Es wird gezeigt, wie diese geladen, somit im OpenLDAP Server verfügbar gemacht werden und, wenn nötig, wie diese auch weiter integriert werden, z.B. welche Indizes evtl. zu definieren sind. \\ ===== Cousine ===== Erstellen Sie eine neue Textdatei und speichern Sie sie mit folgendem Inhalt ab. Anschliessend laden Sie das Schema. dn: cn=cosine,cn=schema,cn=config objectClass: olcSchemaConfig cn: cosine olcAttributeTypes: ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.4 NAME 'info' DESC 'RFC1274: general information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) DESC 'RFC1274: favorite drink' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' DESC 'RFC1274: room number' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.7 NAME 'photo' DESC 'RFC1274: photo (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.8 NAME 'userClass' DESC 'RFC1274: category of user' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.9 NAME 'host' DESC 'RFC1274: host computer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.10 NAME 'manager' DESC 'RFC1274: DN of manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' DESC 'RFC1274: unique identifier of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' DESC 'RFC1274: title of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' DESC 'RFC1274: version of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' DESC 'RFC1274: DN of author of document' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' DESC 'RFC1274: location of document original' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTelephoneNumber' ) DESC 'RFC1274: home telephone number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.21 NAME 'secretary' DESC 'RFC1274: DN of secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' DESC 'RFC1274: DN of entry associated with domain' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' DESC 'RFC1274: home postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' DESC 'RFC1274: personal title' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.41 NAME ( 'mobile' 'mobileTelephoneNumber' ) DESC 'RFC1274: mobile telephone number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) DESC 'RFC1274: pager telephone number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.43 NAME ( 'co' 'friendlyCountryName' ) DESC 'RFC1274: friendly country name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' DESC 'RFC1274: unique identifer' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' DESC 'RFC1274: organizational status' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox' DESC 'RFC1274: Janet mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption' DESC 'RFC1274: mail preference option' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' DESC 'RFC1274: name of building' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality' DESC 'RFC1274: DSA Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.19 SINGLE-VALUE ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality' DESC 'RFC1274: Single Level Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQuality' DESC 'RFC1274: Subtree Mininum Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQuality' DESC 'RFC1274: Subtree Maximun Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature' DESC 'RFC1274: Personal Signature (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect' DESC 'RFC1274: DIT Redirect' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.55 NAME 'audio' DESC 'RFC1274: audio (u-law)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' DESC 'RFC1274: publisher of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcObjectClasses: ( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilotPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelephoneNumber $ organizationalStatus $ mailPreferenceOption $ personalSignature ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ host ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP top STRUCTURAL MUST documentIdentifier MAY ( commonName $ description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ documentTitle $ documentVersion $ documentAuthor $ documentLocation $ documentPublisher ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST commonName MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL MUST commonName MAY ( description $ seeAlso $ telephonenumber $ localityName $ organizationName $ organizationalUnitName ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST domainComponent MAY ( associatedName $ organizationName $ description $ businessCategory $ seeAlso $ searchGuide $ userPassword $ localityName $ stateOrProvinceName $ streetAddress $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart' SUP domain STRUCTURAL MAY ( commonName $ surname $ description $ seeAlso $ telephoneNumber $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) olcObjectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' DESC 'RFC1274: an object related to an domain' SUP top AUXILIARY MUST associatedDomain ) olcObjectClasses: ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country STRUCTURAL MUST friendlyCountryName ) olcObjectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization $ organizationalUnit ) STRUCTURAL MAY buildingName ) olcObjectClasses: ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA' SUP dsa STRUCTURAL MAY dSAQuality ) olcObjectClasses: ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData' SUP top AUXILIARY MUST dsaQuality MAY ( subtreeMinimumQuality $ subtreeMaximumQuality ) ) # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/cosine_schema.ldif Enter LDAP Password: adding new entry "cn=cosine,cn=schema,cn=config" \\ ===== InetOrgPerson ===== Erstellen Sie eine neue Textdatei und speichern Sie sie mit folgendem Inhalt unter dem Dateiname ''inetorgperson_schema.ldif'' ab. Anschliessend laden Sie das Schema. dn: cn=inetorgperson,cn=schema,cn=config objectClass: olcSchemaConfig cn: inetorgperson olcAttributeTypes: ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'RFC2798: vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'RFC2798: identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'RFC2798: preferred name to be used when displaying entries' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'RFC2798: numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'RFC2798: type of employment for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'RFC2798: a JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'RFC2798: preferred written or spoken language for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC 'RFC2798: PKCS#7 SignedData used to support S/MIME' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) olcAttributeTypes: ( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'RFC2798: personal identity information, a PKCS #12 PFX' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) olcObjectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'RFC2798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/inetorgperson_schema.ldif Enter LDAP Password: adding new entry "cn=inetorgperson,cn=schema,cn=config" \\ ===== NIS ===== Erstellen Sie eine neue Textdatei und speichern Sie sie mit folgendem Inhalt unter dem Dateiname ''nis_schema.ldif'' ab. Anschliessend laden Sie das Schema. dn: cn=nis,cn=schema,cn=config objectClass: olcSchemaConfig cn: nis olcAttributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'The path to the login shell' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.6 NAME 'shadowMin' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.7 NAME 'shadowMax' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' SYNTAX 1.3.6.1.1.1.0.0 ) olcAttributeTypes: ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol' SUP name ) olcAttributeTypes: ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber' DESC 'IP address' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} ) olcAttributeTypes: ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' DESC 'IP network' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.1.1.1.22 NAME 'macAddress' DESC 'MAC address' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} ) olcAttributeTypes: ( 1.3.6.1.1.1.1.23 NAME 'bootParameter' DESC 'rpc.bootparamd parameter' SYNTAX 1.3.6.1.1.1.0.1 ) olcAttributeTypes: ( 1.3.6.1.1.1.1.24 NAME 'bootFile' DESC 'Boot image name' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: ( 1.3.6.1.1.1.1.26 NAME 'nisMapName' SUP name ) olcAttributeTypes: ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{1024} SINGLE-VALUE ) olcObjectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' DESC 'Additional attributes for shadow passwords' SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ description ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top STRUCTURAL MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.3 NAME 'ipService' DESC 'Abstraction an Internet Protocol service' SUP top STRUCTURAL MUST ( cn $ ipServicePort $ ipServiceProtocol ) MAY description ) olcObjectClasses: ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' DESC 'Abstraction of an IP protocol' SUP top STRUCTURAL MUST ( cn $ ipProtocolNumber $ description ) MAY description ) olcObjectClasses: ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' DESC 'Abstraction of an ONC/RPC binding' SUP top STRUCTURAL MUST ( cn $ oncRpcNumber $ description ) MAY description ) olcObjectClasses: ( 1.3.6.1.1.1.2.6 NAME 'ipHost' DESC 'Abstraction of a host, an IP device' SUP top AUXILIARY MUST ( cn $ ipHostNumber ) MAY ( l $ description $ manager ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' DESC 'Abstraction of an IP network' SUP top STRUCTURAL MUST ( cn $ ipNetworkNumber ) MAY ( ipNetmaskNumber $ l $ description $ manager ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' DESC 'Abstraction of a netgroup' SUP top STRUCTURAL MUST cn MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) olcObjectClasses: ( 1.3.6.1.1.1.2.9 NAME 'nisMap' DESC 'A generic abstraction of a NIS map' SUP top STRUCTURAL MUST nisMapName MAY description ) olcObjectClasses: ( 1.3.6.1.1.1.2.10 NAME 'nisObject' DESC 'An entry in a NIS map' SUP top STRUCTURAL MUST ( cn $ nisMapEntry $ nisMapName ) MAY description ) olcObjectClasses: ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a MAC address' SUP top AUXILIARY MAY macAddress ) olcObjectClasses: ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' DESC 'A device with boot parameters' SUP top AUXILIARY MAY ( bootFile $ bootParameter ) ) # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/nis_schema.ldif Enter LDAP Password: adding new entry "cn=nis,cn=schema,cn=config" \\ ===== QMAIL ===== Erstellen Sie eine neue Textdatei und speichern Sie sie mit folgendem Inhalt unter dem Dateiname ''qmail_schema.ldif'' ab. Anschliessend laden Sie das Schema. dn: cn=qmail,cn=schema,cn=config objectClass: olcSchemaConfig cn: qmail olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.1 NAME 'qmailUID' DESC 'UID of the user on the mailsystem' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.2 NAME 'qmailGID' DESC 'GID of the user on the mailsystem' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.3 NAME 'mailMessageStore' DESC 'Path to the maildir/mbox on the mail system' EQUALITY caseExactIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.4 NAME 'mailAlternateAddress' DESC 'Secondary (alias) mailaddresses for the same user' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.6 NAME 'mailHost' DESC 'On which qmail server the messagestore of this user is located.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.7 NAME 'mailForwardingAddress' DESC 'Address(es) to forward all incoming messages to.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.8 NAME 'deliveryProgramPath' DESC 'Program to execute for all incoming mails.' EQUALITY caseExactIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.9 NAME 'qmailDotMode' DESC 'Interpretation of .qmail files: both, dotonly, ldaponly, ldapwithprog' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.10 NAME 'deliveryMode' DESC 'multi field entries of: nolocal, noforward, noprogram, reply' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.11 NAME 'mailReplyText' DESC 'A reply text for every incoming message' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{4096} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.12 NAME 'accountStatus' DESC 'The status of a user account: active, noaccess, disabled, deleted' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.14 NAME 'qmailAccountPurge' DESC 'The earliest date when a mailMessageStore will be purged' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.15 NAME 'mailQuotaSize' DESC 'The size of space the user can have until further messages get bounced.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.16 NAME 'mailQuotaCount' DESC 'The number of messages the user can have until further messages get bounced.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.2.1.17 NAME 'mailSizeMax' DESC 'The maximum size of a single messages the user accepts.' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.1 NAME 'dnmember' DESC 'Group member specified as distinguished name.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.2 NAME 'rfc822member' DESC 'Group member specified as normal rf822 email address.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.3 NAME 'filtermember' DESC 'Group member specified as ldap search filter.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{512} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.4 NAME 'senderconfirm' DESC 'Sender to Group has to answer confirmation email.' booleanMatch 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.5 NAME 'membersonly' DESC 'Sender to Group must be group member itself.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.6 NAME 'confirmtext' DESC 'Text that will be sent with sender confirmation email.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{4096} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.7 NAME 'dnmoderator' DESC 'Group moderator specified as Distinguished name.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.8 NAME 'rfc822moderator' DESC 'Group moderator specified as normal rfc822 email address.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.9 NAME 'moderatortext' DESC 'Text that will be sent with request for moderation email.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{4096} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.10 NAME 'dnsender' DESC 'Allowed sender specified as distinguished name.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.11 NAME 'rfc822sender' DESC 'Allowed sender specified as normal rf822 email address.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.3.1.12 NAME 'filtersender' DESC 'Allowed sender specified as ldap search filter.' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{512} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.1 NAME 'qladnmanager' DESC '' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.2 NAME 'qlaDomainList' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.3 NAME 'qlaUidPrefix' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.4 NAME 'qlaQmailUid' DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.5 NAME 'qlaQmailGid' DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.6 NAME 'qlaMailMStorePrefix' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.7 NAME 'qlaMailQuotaSize' DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.8 NAME 'qlaMailQuotaCount' DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.9 NAME 'qlaMailSizeMax' DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: ( 1.3.6.1.4.1.7914.1.4.1.10 NAME 'qlaMailHostList' DESC '' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcObjectClasses: ( 1.3.6.1.4.1.7914.1.2.2.1 NAME 'qmailUser' DESC 'QMail-LDAP User' SUP top AUXILIARY MUST ( mail ) MAY ( uid $ mailMessageStore $ homeDirectory $ userPassword $ mailAlternateAddress $ qmailUID $ qmailGID $ mailHost $ mailForwardingAddress $ deliveryProgramPath $ qmailDotMode $ deliveryMode $ mailReplyText $ accountStatus $ qmailAccountPurge $ mailQuotaSize $ mailQuotaCount $ mailSizeMax ) ) olcObjectClasses: ( 1.3.6.1.4.1.7914.1.3.2.1 NAME 'qmailGroup' DESC 'QMail-LDAP Group' SUP top AUXILIARY MUST ( mail $ mailAlternateAddress $ mailMessageStore ) MAY ( dnmember $ rfc822member $ filtermember $ senderconfirm $ membersonly $ confirmtext $ dnmoderator $ rfc822moderator $ moderatortext $ dnsender $ rfc822sender $ filtersender) ) olcObjectClasses: ( 1.3.6.1.4.1.7914.1.4.2.1 NAME 'qldapAdmin' DESC 'QMail-LDAP Subtree Admin' SUP top AUXILIARY MUST ( qlaDnManager $ qlaDomainList $ qlaMailMStorePrefix $ qlaMailHostList ) MAY ( qlaUidPrefix $ qlaQmailUid $ qlaQmailGid $ qlaMailQuotaSize $ qlaMailQuotaCount $ qlaMailSizeMax ) ) # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/qmail_schema.ldif Enter LDAP Password: adding new entry "cn=qmail,cn=schema,cn=config" \\ ====== Performance ====== Der aktuelle Stand des OpenLDAP Servers an diesem Punkt ist zwar funktionabel, wir unter Performance-Gesichtspunkten jedoch keinen Preis gewinnen. Glücklicherweise bietet uns OpenLDAP einige Möglichkeiten, wie wir diese beeinflussen können. Mit genau diesem Thema beschäftigt sich dieser Abschnitt. \\ ===== Indizes ===== OpenLDAP bietet uns die Möglichkeit, Werte von Attributen indezieren zu lassen, was bei Suchoperationen naturgemäss eine immense Performance-Verbesserung mit sich bringt. Solche Indizes lassen sich im ''cn=config''-Suffix definieren und werden dort im Eintrag der jeweiligen Datenbank (des jeweiligen Suffix) unter der Verwendung des ''olcDbIndex''-Attributs deklariert. \\ \\ OpenLDAP hält hierfür die folgenden Index-Arten bereit. ^ Indexparameter ^ Bedeutung ^ | pres(ent) | Vorhandensein | | eq(ual) | Exaktes Übereinstimmen | | approx(imate) | Annäherndes Übereinstimmen | | sub | Teilstring (Siehe ''special'') | | special | Ergänzungsparameter (Z.B. ''initial'', ''any'', ''final'' bei ''sub'') | \\ Eine Indexdefinition sieht somit in etwa wie folgt aus olcDbIndex: uid pres,sub,eq Im Laufe diese Howtos wurden zwei Datenbanken angelegt. Zum einen ist das ''dc=mydomain,dc=local'', zum anderen ''dc=logs''. Wie Sie sich sicherlich leicht vorstellen können, werden in diese unterschiedliche Indezierungseinstellungen benötigt. \\ Die folgende Darstellung enthält die notwendigen Manipulationen am Konfigurations-DIT im LDIF-Format, um die grundlegensten Indexoptionen zu erstellen. Speichern Sie diese in einer neuen Textdatei unter dem Dateinamen ''indizes.ldif'' ab. dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcDbIndex olcDbIndex: cn pres,sub,eq olcDbIndex: displayName pres,sub,eq olcDbIndex: gidNumber eq olcDbIndex: givenName eq,sub olcDbIndex: mail eq,sub olcDbIndex: memberUID eq,sub olcDbIndex: objectClass eq olcDbIndex: sn pres,sub,eq olcDbIndex: uid pres,sub,eq olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq Führen Sie anschliessend die Änderungen am DIT durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/indizes.ldif Enter LDAP Password: modifying entry "olcDatabase={2}hdb,cn=config" ===== DB_CONF ===== Die unseren Suffix-Datenbanken zugrunde liegenden Datenbankdateien lassen sich durch das Erstellen einer ''DB_CONF''-Datei im jeweiligen Ordner in ihrer Funktionsweise und somit auch in Sachen Performance beeinflussen. \\ \\ Sämtliche verfügbare Parameter können [[http://www.sleepycat.com/docs/ref/env/db_config.html|hier]] nachgelesen werden. \\ \\ In diesem Howto jedoch ist es das Ziel, möglichst alle Konfiguration im DIT vorzunehmen. Hierfür ist eine neue Textdatei zu erstellen, welche mit dem folgenden Inhalt versehen unter dem Dateinamen ''dbConf.ldif'' abgespeichert wird. dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcDbConfig olcDbConfig: set_cachesize 0 4194304 1 olcDbConfig: set_lg_regionmax 262144 olcDbConfig: set_lg_bsize 2097152 olcDbConfig: set_flags DB_LOG_AUTOREMOVE dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcDbConfig olcDbConfig: set_cachesize 0 26214400 1 olcDbConfig: set_lg_regionmax 262144 olcDbConfig: set_lg_bsize 2097152 olcDbConfig: set_flags DB_LOG_AUTOREMOVE Nun müssen diese Daten noch in den DIT. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/dbConf.ldif Enter LDAP Password: modifying entry "olcDatabase={1}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" Damit diese Änderungen übernommen werden können, muss der OpenLDAP Server einmal neu gestartet werden. # rcslapd restart \\ ====== Security ====== Dieser Abschnitt behandelt die Sicherung des OpenLDAP Servers. Hierbei werden zum einen auf die ''Access Control Lists'' angerissen, zum anderen wird aufgezeigt werden, wie die Client-Server-Kommunikaiton mit dem OpenLDAP Server mittes SSL/TLS und SASL abgesichert werden kann. \\ ===== ACL ===== Eine der wichtigsten Aufgaben ist es, den OpenLDAP mittels ACLs gegen unberechtigte Zugriffe zu sichern. An dieser Stellen werden daher einige grundlegende ACLs gesetzt. Speichern Sie hierfür den folgenden Inhalt in einer neuen Textdatei unter dem Dateinamen ''acl_init.ldif'' ab. dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: to dn.base="" by users read by anonymous none olcAccess: to dn.base="cn=subschema" by users read by anonymous none olcAccess: to attrs=userPassword by self write by * auth olcAccess: to * by users read by anonymous none Beachten Sie bitte, dass es sich hierbei um die minimal notwendige ACL-Konfiguration, welche unbedingt vorhanden sein sollte. Die ACLs des OpenLDAP Servers werden im Weitern Verlauf dieses Howtos noch erweitert werden. Führen Sie anschliessend das folgende Kommando aus, um die Modifikationen am Konfigurations-DIT vorzunehmen. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/acl_init.ldif Enter LDAP Password: modifying entry "olcDatabase={-1}frontend,cn=config" \\ ===== SSL/TLS ===== Der voran gegangene Abschnitt hat die Erstellung und Aktivierung einiger grundlegender ACLs aufgezeigt. Diese allein reichen natürlich nicht aus, um den OpenLDAP Server zu sichern. Ebenso gilt es darauf zu achten, dass es Drittn nicht gelingt, evtl. mitgeschnittenen Datenverkehr auszuwerten und z.B. Zugangsdaten zum Server zu ermitteln. Hierzu ist es notwendig, dass die Kommunikation mit dem OpenLDAP Server verschlüsselt wird. \\ Um dies bewerkstelligen zu können, benötigen Sie ein Server-Zertifikat, welches vom OpenLDAP Server dazu verwendet werden kann, die erwähnte Verschlüsselung der Kommunikation technisch zu realisieren. Solten Sie bereits über ein solches verfügen, so fähren Sie bitte umgehend mit den Erläuterungen zur Einrichtung von SSL/TLS fort. Anderenfalls finden Sie im [[howtos:linux:security:openssl|OpenSSL Howto]] genaue Instruktionen, wie ein solches erstellt werden kann. \\ ==== Vorbereitungen ==== Zunächst ist ein Ordner auszuwählen, in welchem das Zertifikat und der zugehörige Schlüssel, sowie das CA-Zertifikat gespeichert werden und auf welchen in der Konfiguration des OpenLDAP Servers verwiesen werden kann. Dieses Hotwo verwenden hierzu den Ordner ''/data/pki'' für das CA-Zertifikat und ''/data/pki/certs/ldap'' für die Server-Zertifikat-Dateien. Selbstverständlich steht es Ihnen frei, eine andere Ordnerstruktur zu verwenden. Achten Sie in diesem Fall aber unbedingt darauf, die in der folgenden Konfiguration verwendeten Pfade anzupassen. # mkdir -p /data/pki/certs/ldap Anschliessend kopieren Sie das CA-Zertifikat, sowie das Server-Zertifikat und die dazugehörige Zertifikatschlüsseldatei in diese Ordner. Sie sollten danach die folgende Struktur verfügbar haben. # ll /data/pki/ total 16 drwxr-xr-x 3 root root 4096 Dec 25 01:06 . drwxr-xr-x 4 root root 4096 Dec 22 11:35 .. -rw-r--r-- 1 root root 1375 Dec 10 21:18 cacert.pem drwxr-xr-x 3 root root 4096 Dec 25 01:04 certs # ll /data/pki/certs/ldap/ total 20 drwxr-xr-x 2 root root 4096 Dec 25 01:16 . drwxr-xr-x 3 root root 4096 Dec 25 01:04 .. -rw-r--r-- 1 root root 4542 Dec 25 01:16 certificate.pem -rw-r--r-- 1 root root 1679 Dec 25 01:16 privkey.pem ==== Konfiguration ==== Nun müssen die Entsprechenden Modifikationen am Konfigurations-DIT vorgenommen werden, damit SSL/TLS aktiviert werden kann. Erstellen Sie hierzu eine neue Textdatei und speichern Sie sie mit folgenden Inhalt unter dem Dateinamen ''ssl-tls_init.ldif'' ab. dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /data/pki/cacert.pem dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /data/pki/certs/ldap/certificate.pem dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /data/pki/certs/ldap/privkey.pem dn: cn=config changetype: modify replace: olcTLSVerifyClient olcTLSVerifyClient: try Anschliessend führen Sie die Modifikationen wie folgt durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/ssl-tls_init.ldif Enter LDAP Password: modifying entry "cn=config" modifying entry "cn=config" modifying entry "cn=config" modifying entry "cn=config" ==== Aktivierung ==== Um nun Zugang zum OpenLDAP Server mittels SSL/TLS zu erhalten, muss das Bereitstellen des LDAP Servers über SSL (''ldaps'') und TLS mittels der Parameter aktiviert werden, welche dem ''slapd''-Dämon beim Starten übergenben werden. Hierzu öffnen Sie die Datei ''/etc/conf.d/slapd'' mit einem Texteditor und stellen sicher, dass der Inhalt dieser dem folgenden entspricht. # conf.d file for openldap # # To enable both the standard unciphered server and the ssl encrypted # one uncomment this line or set any other server starting options # you may desire. # # OPTS="-h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" # Uncomment the below to use the new slapd configuration for openldap 2.3 OPTS="-F /etc/openldap/slapd.d -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'" Anschliessend muss der OpenLDAP Server neu gestartet werden. # rcslapd restart Benutzen Sie nun das Kommandozeilentool ''netstat'' um zu überprügen, ob der OpenLDAP Server nun am ''ldaps''-Port (636) auf eingehende Verbindungen horcht. # netstat -tulpen | grep slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 0 7789 8982/slapd tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 7788 8982/slapd Entspricht die Ausgabe des Tools in etwa der obigen, so sollte der OpenLDAP Server nun via SSL/TLS erreichbar sein. \\ ==== Test (SSL) ==== Testen Sie den OpenLDAP Server nun, indem Sie eine einfache Abfrage im DIT ausführen, welche die Verbindung zum Server über SSL aufbaut. # ldapsearch -D cn=Manager,dc=mydomain,dc=local -x -W -H ldaps://127.0.0.1 objectclass=* Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed **__UPS...__** \\ \\ Keine Bange, das ist ganz normal so. Dies geschieht, weil unser LDAP-Client-Tool (''ldapsearch'') dem Zertifikat des OpenLDAP Servers schlicht nicht vertraut und somit die Verbindung fehlschlagen lässt. \\ ==== Client ==== Damit die LDAP-Client-Tools auch für die Verbindung unter SSL/TLS verwendet werden können, muss ihnen bekannt gegeben werden, welches das CA-Zertifikat ist, bei welchem allen Server-Zertifikation vertraut werden soll, die damit gezeichnet wurden. Öffnen Sie hierzu die Datei ''/etc/openldap/ldap.conf'' mit einem Texteditor und stellen Sie sicher, dass der Inhalt mit dem folgenden übereinstimmt. BASE dc=mydomain,dc=local URI ldap://127.0.0.1 TLS_CACERT /data/pki/cacert.pem TLS_REQCERT try \\ Versuchen Sie es nun erneut, die Abfrage mittels SSL durchzuführen. # ldapsearch -D cn=Manager,dc=mydomain,dc=local -x -W -H ldaps://127.0.0.1 objectclass=* Enter LDAP Password:ldap_bind: Can't contact LDAP server (-1) additional info: TLS: hostname does not match CN in peer certificate **__Aber he, immer noch nicht...?__** \\ \\ Keine Bange, auch das ist ganz normal so. Dieser Fehler tritt auf, wie man der Fehlermeldung entnehmen kann, weil der Name des Servers in der URI (''-h''-Parameter) des Aufrufs von ''ldapsearch'' nicht mit dem übereinstimmt, welcher im ''CN''-Feld des vom OpenLDAP Server verwendeten Zertifikats eingetragen ist. \\ \\ Hier nun bestehen zwei Möglichkeiten, wie sie die LDAP-Client-Tools dazu bewegen können, mit dem Server zusammen zu arbeiten. Zum einen ist dies natürlich, dass der Name im ''CA''-Feld des Server-Zertifikats auch mit dem übereinstimmt, der in der URI angegeben wird. Zum anderen jedoch besteht auch die Möglichkeit, den LDAP-Client-Tools mitzuteilen, dass sie nicht auf diese Übereinstimmung überprüfen sollen. Um dies zu aktivieren ist in der Datei ''/etc/openldap/ldap.conf'' der folgenden Parameter zu ändern. TLS_REQCERT never Im Rahmen dieses Howtos setzen Sie den Parameter bitten auf ''never''. Nach Abschluss dieses Howtos sollten Sie ihn aber wieder auf try setzen, um Sicherheitsprobleme vermeiden, sowie Fehlkonfigurationen erkennen zu können. \\ ==== Test (TLS) ==== Testen Sie nun noch, ob es ebenfalls möglich ist, mittels TLS eine sichere Verbindung zum OpenLDAP Server herzustellen. Führen Sie hierzu die folgende Abfrage aus. # ldapsearch -D cn=Manager,dc=mydomain,dc=local -x -W -H ldaps://127.0.0.1 -ZZ objectclass=* ldap_start_tls: Operations error (1) additional info: TLS already started **__Und schon wieder... :-\__** \\ \\ Ich wollte Sie mit diesem forsierten Fehler auf eine wesentlichen Umstand aufmerksam machen. Betrachenten Sie das Kommando genauer, so fällt Ihnen auf, dass ein weiterer Parameter (''-ZZ'') hinzu gekommen ist. Dieser instruiert ''ldapsearch'' die Verbindung unter der Verwendung von TLS aufzubauen (''-Z''). Die Angabe von doppel-Z (''-ZZ'') bewirkt, dass ''ldapsearch'' eine erfolgreiche Antwort vom Server zurückerhalten muss, damit die Kommunikation fortgesetzt wird. \\ Es ist jedoch wichtig zu wissen und diest auch der Grund, dass die Suche fehlschlug, dass TLS nicht über SSL funktioniert. Das heisst, um TLS für eine Verbindung aktivieren zu können, muss diese auf einem nicht-verschlüsselten Weg aufgebaut werden. \\ \\ Hieraus erhält, dass der URI in obigen Kommando entsprechend angepasst werden muss. Versuchen Sie es noch einmal wie folgt. # ldapsearch -D cn=Manager,dc=mydomain,dc=local -x -W -H ldap://127.0.0.1 -ZZ objectclass=* \\ ===== SASL ===== [[http://asg.web.cmu.edu/sasl|''Simple Authentication and Security Layer'']] ist eine Methode, welche es erlaubt, Operationen im Kontext eines bestimmten Benutzers auszuführen, während die Daten eines anderen Benutzers zur Authentifizierung verwendet wurden. Diese Methode kann unabhängig von der Art der Verbindung (Plain, SSL oder TLS) verwendet werden. \\ \\ Da der OpenLDAP Server diese Methode unterstützt, wird dieser Abschnitt zeigen, wie er hierfür zu konfigurieren ist. \\ ==== Unterstützte Mechanismen ==== Bevor die Unterstützung von SASL im OpenLDAP Server konfiguriert wird, sollte zunächst ausfindig gemacht werden, welche Mechanismen aktuell vom OpenLDAP Server unterstütz werden. Hierzu kann man eine Suche im DIT durchführen, welche die gewünschte Information liefert. Diese Suche sieht wie folgt aus. # ldapsearch -D "cn=Manager,dc=mydomain,dc=local" -x -W -H ldap:// -b '' -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM Aus dieser Antwort geht hervor, dass der OpenLDAP Server ''GSSAPI'', ''DIGEST-MD5'', ''CRAM-MD5'' und ''NTLM'' unterstützt. Was auffällt ist, dass kein Mechanismus aufgeführt wird, welcher die Verwendung von Klartextpasswörtern voraussetzt. Dies ist ein Sicherheitsmechanismus von OpenLDAP. Dieser bietet immer nur die Mechanismen an, welche auf dem verwendeten Kommunikationsweg als sicher betrachtet werden können. Da die obige Abfrage im Klartext (''%%ldap://%%'') über die Leitung geht, werden erwähnte, fehlende Mechanismen nicht unterstützt. Führt man die Anfrage hingegen unter der Verwendung von SSL, TLS oder gegen die ''ldapi''-Schnittstelle durch, sieht dies schon anders aus. # ldapsearch -D "cn=Manager,dc=mydomain,dc=local" -x -W -H ldap:// -b '' -s base -ZZ -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM Das obige Kommando wurde unter Verwendung von TLS ausgeführt. Der Rückgabewert ist identisch zu dem einer Verbindung mittels SSL. Wird die Verbindung zum OpenLDAP Server nun nocht über ''ldapi'' hergestellt, ändert sich das Ergebnis ein weiteres mal. # ldapsearch -D "cn=Manager,dc=mydomain,dc=local" -x -W -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: EXTERNAL Somit wissen wir nun also, dass die folgenden Mechanismen aktuell vom OpenLDAP Server unterstütz werden. * PLAIN * GSSAPI * DIGEST-MD5 * LOGIN * CRAM-MD5 * NTLM * EXTERNAL \\ ==== Vorbereitungen ==== Es ist wichtig zu wissen, dass für die Verwendung von SASL das Passwort des jeweils zum Einsatz kommenden Benutzereintrags im Klartext vorliegen muss. Um sicher zu stellen, dass das Passwort beim Anlegen eines Benutzereintrags oder beim Ändern des Passworts eines Benutzereintrags im Klartext abgespeichert wird, ist die ''PasswortHash''-Policy im Konfigurations-DIT zu ändern. \\ Erstellen Sie hierzu eine neue Textdatei und speichern Sie sie mit folgendem Inhalt unter dem Dateinamen ''sasl_passwortHash.ldif'' ab. dn: cn=config changetype: modify replace: olcPasswordHash olcPasswordHash: {CLEARTEXT} Führen Sie anschliessend die Änderung im DIT durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/sasl_passwortHash.ldif Enter LDAP Password: modifying entry "cn=config" ==== Konfiguration ==== Nachdem nun ausfindig gemacht wurde, welche Mechanismen der OpenLDAP Server verarbeiten kann, gilt es, diejenigen zu konfigurieren, welche er auch wirklich anbieten können soll. Um den OpenLDAP Server in die Lage zu versetzen, SASL "reden" zu können, muss ein sogenanntes Mapping konfiguriert werden. Ein solches Mapping definiert, wie der Authentisierungs-String das SASL-Requests auf einen Benutzer im DIT des Servers zu mappen ist. Hierbei gilt, dass der Authentifizierungs-String immer eines der beiden folgenden Formate hat. * ''uid=,cn=digest-md5,cn=auth'' * ''uid=,cn=,cn=digest-md5,cn=auth'' \\ Ob das Format dem Ersten oder Zweiten oben gezeigten entspricht, hängt davon ab, ob der jeweilige Mechanismus das Konzept der ''realms'' unterstützt oder nicht. \\ \\ Einige Beispiele hierzu. ^ Benutzername ^ REALM ^ Mechanismus ^ Authentifizierungs-String ^ | test | | DIGEST-MD5 | uid=test,cn=digest-md5,cn=auth | | test | | GSSAPI | uid=test,cn=,cn=gssapi,cn=auth | | test | MYDOMAIN.LOCAL | GSSAPI | uid=test,cn=mydomain.local,cn=gssapi,cn=auth | \\ Somit ist es möglich, mittels eines regulären Ausdrucks die zur Authentifizierung verwendeten Daten dem Authentifizierungs-String zu entnehmen und z.B. in einer LDAP-Suche zu verwenden. Dies zumman nennt man dann ein Mapping. Ein solches könnte in etwa wie folgt gestaltet sein. uid=(.*),cn=digest-md5,cn=auth uid=$1,ou=people,dc=mydomain,dc=local oder uid=(.*),cn=mydomain.local,cn=gssapi,cn=auth uid=$1,ou=people,dc=mydomain,dc=local Ebenso ist aber auch das folgende Mapping denkbar, welches natürlich sehr generisch ist und somit zwar die meisten Fälle abdecken sollte, allerdings auch die Gefahr in sich birgt, dass Authentifizierungsversuche auf einen Benutzer gemappt werden, zu welchem sie eigentlich keinen Zugang haben sollten. uid=(.*),cn=.*,cn=auth uid=$1,ou=people,dc=mydomain,dc=local Um dieser Gefahr entgegen zu wirken, werden in diesem Howto ausschliesslich genaue Mappings erstellt. \\ === DIGEST-MD5 === Erstellen Sie dann eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''sasl_mapping_digest-md5.ldif'' ab. dn: cn=config changetype: modify replace: olcAuthzRegexp olcAuthzRegexp: uid=([^,]*),cn=SPECIALUSERS,cn=DIGEST-MD5,cn=auth ldap:///ou=Special Users,dc=mydomain,dc=local??one?(&(uid=$1)(objectClass=person)) olcAuthzRegexp: uid=([^,]*),cn=DIGEST-MD5,cn=auth ldap:///ou=Peopledc=mydomain,dc=local??one?(&(uid=$1)(objectClass=person)) Führen Sie anschliessend die Änderung am DIT durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/sasl_mapping_digest-md5.ldif Enter LDAP Password: modifying entry "cn=config" \\ === CRAM-MD5 === Erstellen Sie dann eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''sasl_mapping_cram-md5.ldif'' ab. dn: cn=config changetype: modify replace: olcAuthzRegexp olcAuthzRegexp: uid=(.*),cn=DIGEST-MD5,cn=auth ldap:///dc=mydomain,dc=local??sub?uid=$1 olcAuthzRegexp: uid=(.*),cn=CRAM-MD5,cn=auth ldap:///dc=mydomain,dc=local??sub?uid=$1 Führen Sie anschliessend die Änderung am DIT durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/sasl_mapping_cram-md5.ldif Enter LDAP Password: modifying entry "cn=config" \\ === NTLM === Erstellen Sie dann eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''sasl_mapping_ntlm.ldif'' ab. dn: cn=config changetype: modify replace: olcAuthzRegexp olcAuthzRegexp: uid=(.*),cn=DIGEST-MD5,cn=auth ldap:///dc=mydomain,dc=local??sub?uid=$1 olcAuthzRegexp: uid=(.*),cn=CRAM-MD5,cn=auth ldap:///dc=mydomain,dc=local??sub?uid=$1 olcAuthzRegexp: uid=(.*),cn=NTLM,cn=auth ldap:///dc=mydomain,dc=local??sub?uid=$1 Führen Sie anschliessend die Änderung am DIT durch. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/sasl_mapping_ntlm.ldif Enter LDAP Password: modifying entry "cn=config" \\ ==== Test ==== Nachdem die Unterstützung der verschiedenen SASL-Machanismen per Mappings im DIT des OpenLDAP aktiviert wurde, gilt es zu überprüfen, ob sie auch tatsächlich funktionieren. \\ \\ Hierzu bedarf es allerdings eines Benutzerkontos, welches zum Zwecke der Anmeldung verwendet werden kann. Ferner benötigt man noch ein weiters Benutzerkonto, um die Funktionalität des Kontextwechsels veranschaulichen zu können. \\ \\ Erstellen Sie eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt ab. dn: uid=LoginUser,ou=Special Users,dc=mydomain,dc=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount cn: SASL Test Login User description: User to use for SASL testing gidNumber: 4523 givenName: Login Test User homeDirectory: /home/LoginUser sn: SASL uid: LoginUser uidNumber: 1006 userPassword:: TestPasswort dn: uid=OperationalUser,ou=Special Users,dc=mydomain,dc=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount cn: SASL Test Operational User description: User to use for SASL testing gidNumber: 4524 givenName: Operational Test User homeDirectory: /home/OperationalUser sn: SASL uid: OperationalUser uidNumber: 1006 userPassword:: TestPasswort Fügen Sie anschliessend diese beiden Benutzerkonten Ihrem DIT hinzu. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/sasl_test_users.ldif Enter LDAP Password: adding new entry "uid=LoginUser,ou=Special Users,dc=mydomain,dc=local" adding new entry "uid=OperationalUser,ou=Special Users,dc=mydomain,dc=local" === DIGEST-MD5 === Führen Sie das folgende Kommando aus # ldapsearch -I -Z -Y DIGEST-MD5 objectclass=* \\ ====== Overlays ====== OpenLDAP kommt mit einer kleinen aber feinen Sammlung an Overlays daher. Ein Overlay ist eine Art Funktionserweiterung des OpenLDAP und wird über eine bestimmte, interne Schnittstelle in den OpenLDAP Server eingebunden. Man kann sich das wie eine Art Plugin vorstellen. Einige wenige davon werden nachfolgend vorgestellt und installiert, sowie konfiguriert werden. \\ ===== PPolicy ===== Dieses Overlay erlaubt es dem OpenLDAP Administrator, Regelwerke bezüglich des Passwortes eines Benutzers zu definieren und ausgewählten Benutzern zuzuweisen. Diese Regelwerke enthalten unter Anderem die folgenden Angaben. * Maximales Passwortalter * Minimales Passwortalter * Minimale Passwortlänge * Maximale Anzahl von fehlschlagenden Anmeldungsversuchen mit anschliessender Blockierung des Benutzers * Angaben zur geforderten Komplexität eines neuen Passworts * ... und noch vieles mehr... \\ ==== Schema ==== Zu erst muss der OpenLDAP Server mit dem für das Overlay notwendigen Schema versehen werden. Da diese Schema direkt in den DIT des laufenden Servers installiert werden wird, muss auch dieses im LDIF-Format vorliegen. \\ \\ Sie finden dieses Schema {{howtos:ldap:openldap-gentoo:ppolicy_schema.ldif|hier}}. \\ Laden Sie es sich bitte auf Ihren Rechner herunter und fügen Sie es mit folgendem Kommando der Konfiguration Ihres OpenLDAP Servers hinzu. # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/ppolicy_schema.ldif Enter LDAP Password: adding new entry "cn=ppolicy,cn=schema,cn=config" \\ ==== Aktivieren ==== Um das PPolicy-Overlays zu aktivieren, müss OpenLDAP zunächst instruiert werden, das zugehörige Modul zu laden. Öffnen Sie hierzu eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''ppolicy_moduleLoad.ldif'' ab. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: ppolicy.so Anschliessend wird die Modifikation am Konfigurations-DIT durchgeführt. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/ppolicy_moduleLoad.ldif Enter LDAP Password: modifying entry "cn=module{0},cn=config" Es ist nicht notwendig, den OpenLDAP Server neu zu starten, das Modul wird automatisch zur Laufzeit geladen. Zu guter letzt muss das Overlay für jeden Suffix aktiviert werden, in welchem es verfügbar sein soll. In Rahmen dieses Howtos ist das der ''dc=mydomain,dc=local''-Suffix. Erstellen Sie eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''ppolicy_activateOnSuffix.ldif'' ab. dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=Default,ou=PPolicy,ou=Config,dc=mydomain,dc=local olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE Der Wert für das Attribut ''dn'' enthält den Eintrag ''olcDatabase={2}hdb''. Wenn Sie bis hierher ausschliesslich diesem Howto gefolgt sind, sollte dies so richtig sein. Sind Sie jedoch gerade daran, einen weiteren Suffix zu konfigurieren, so wird dies nicht richtig sein. Passen Sie bitten diesen Teil entsprechend richtig an! Nun müssen diese Daten wieder in den DIT. # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/ppolicy_activateOnSuffix.ldif Enter LDAP Password: adding new entry "olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config" ==== Regelwerke ==== Es können beliebig viele Regelwerke definiert werden. Eines davon wird mittels der Konfiguration des Overlays als Standard-Regelwerk deklariert und immer dann angewendet, wenn einem Benutzer kein spezielles zugewiesen ist. Für die Zuweisung eines speziellen Regelwerks wird das Attribute ''pwdPolicySubentry'' mit dem vollen DN des Regelwerkeintrags im DIT dem jeweiligen Benutzerkonto-Eintrag hinzugefügt. Die meisten graphischen LDAP-Clients, welche mir zum Zeitpunkt der Erstellung dieses Howtos bekannt waren, sind entweder nicht in der Lage, dieses Attribute zu editieren oder zeigen es erst gar nicht an. Prinzipiell handelt es sich hierbei jedoch um ein ganz normales Attribut und kann auch wie ein solches editiert werden. === Standard === Bevor das PPolicy-Overlay konfiguriert werden kann, muss das Standard-Regelwerk erstellt werden. In diesem Howto werden alle erstellten Regelwerke unterhalb des Knoten mit dem DN ''ou=Policies,ou=PPolicy,ou=Config,dc=mydomain,dc=local'' gespeichert. Hierfür ist zunächst die notwendige Struktur im DIT des ''dc=mydomain,dc=local''-Suffix zu erstellen. Öffnen Sie hierzu eine neue Textdatei und speicher Sie sie unter dem Dateinamen ''ppolicy_structure.ldif'' ab, nachdem Sie den folgenden Inhalt hinzugefügt haben. dn: ou=PPolicy,ou=Config,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: PPolicy Anschliessend sind diese Daten in den DIT einzufügen. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/ppolicy_structure.ldif Enter LDAP Password: adding new entry "ou=PPolicy,ou=Config,dc=mydomain,dc=local" Jetzt, da die Struktur erstellt wurde, kann der Standard-Regelwerk-Eintrag dem DIT hinzgefügt werden. Dafür ist die Datei ''ppolicy_defaultRule.ldif'' zu erstellen und mit dem folgenden Inhalt zu versehen. dn: cn=Default,ou=PPolicy,ou=Config,dc=mydomain,dc=local objectClass: top objectClass: pwdPolicy objectClass: device cn: Default pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 1 pwdExpireWarning: 120 pwdFailureCountInterval: 120 pwdGraceAuthNLimit: 3 pwdInHistory: 3 pwdLockout: TRUE pwdLockoutDuration: 60 pwdMaxAge: 8640000 pwdMaxFailure: 3 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: FALSE Anschliessend sind die Daten dem DIT hinzuzufügen. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/ppolicy_defaultRule.ldif Enter LDAP Password: adding new entry "cn=Default,ou=PPolicy,ou=Config,dc=mydomain,dc=local" \\ === Dienstkonten === Normalerweise sollten für Dienstkonten andere Regelwerke angewand werden, als wie für Benutzerkonten. Da aber auch Dienstkonten meist über das ''userPasswort''-Attribut verfügen, werden sie unter die Restriktionen vom PPolicy-Pverlay fallen. Ein solches ''Dienstkonten-Regelwerk'' muss aber noch von Ihnen erstellt werden. Hierzu öffnen Sie eine neue Textdatei und fügen den folgenden Inhalt ein. Speichern Sie sie anschliessend unter dem Dateinamen ''ppolicy_serviceAccountsRule.ldif'' ab. dn: cn=ServiceAccounts,ou=PPolicy,ou=Config,dc=mydomain,dc=local objectClass: device objectClass: pwdPolicy objectClass: top cn: ServiceAccounts pwdAllowUserChange: FALSE pwdAttribute: userPassword pwdSafeModify: FALSE Anschliessend sind die Daten dem DIT hinzuzufügen. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/ppolicy_serviceAccountsRule.ldif Enter LDAP Password: adding new entry "cn=ServiceAccounts,ou=PPolicy,ou=Config,dc=mydomain,dc=local" Um nun das PPolicy-Overlay zu veranlassen, dass für ein bestimmtes Dienstkonto dieses spezielle ''ServiceAccounts''-Regelwerk angewand werden soll, muss dem Konto lediglich das ''pwdPolicySubentry''-Attribut mit dem Wert ''cn=ServiceAccounts,ou=PPolicy,ou=Config,dc=mydomain,dc=local'' hinzugefügt werden. \\ ===== DynList ===== Diese Overlay erlaubt es, dynamisch die Mitglieder von Gruppen erstellen zu lassen, wobei die Gruppenmitgliedschaft mittels einer LDAP-Abfrage definiert wird. \\ ==== Schema ==== Zu erst muss der OpenLDAP Server mit dem für das Overlay notwendigen Schema versehen werden. Da diese Schema direkt in den DIT des laufenden Servers installiert werden wird, muss auch dieses im LDIF-Format vorliegen. \\ \\ Sie finden dieses Schema {{howtos:ldap:openldap-gentoo:dyngroup_schema.ldif|hier}}. \\ Laden Sie es sich bitte auf Ihren Rechner herunter und fügen Sie es mit folgendem Kommando der Konfiguration Ihres OpenLDAP Servers hinzu. # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/dyngroup_schema.ldif Enter LDAP Password: adding new entry "cn=dyngroup,cn=schema,cn=config" \\ ==== Aktivieren ==== Um das DynList-Overlays zu aktivieren, müss OpenLDAP zunächst instruiert werden, das zugehörige Modul zu laden. Öffnen Sie hierzu eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''dynlist_moduleLoad.ldif'' ab. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: dynlist.so Anschliessend wird die Modifikation am Konfigurations-DIT durchgeführt. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/dynlist_moduleLoad.ldif Enter LDAP Password: modifying entry "cn=module{0},cn=config" Es ist nicht notwendig, den OpenLDAP Server neu zu starten, das Modul wird automatisch zur Laufzeit geladen. Zu guter letzt muss das Overlay für jeden Suffix aktiviert werden, in welchem es verfügbar sein soll. In Rahmen dieses Howtos ist das der ''dc=mydomain,dc=local''-Suffix. Erstellen Sie eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''dynlist_activateOnSuffix.ldif'' ab. dn: olcOverlay=dynlist,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcDLattrSet: groupOfURLs memberURL member olcOverlay: dynlist Mittels dem ''olcDLattrSet'' dieser Daten wird dem DynList-Overlay mitgeteilt, dass wann immer ein Eintrag aus dem DIT ausgelesen wird, welcher die Objektklasse ''groupOfURLs'' gesetzt hat, dieses Overlay angewand werden soll. Ferner sagt diese Konfiguration, dass der Wert des ''memberURL''-Attributs den LDAP-Such-String definiert, welcher die Gruppenmitglidschaft regelt. Zu guter letzt sagt diese Konfiguration noch aus, dass Benutzerobjekte, welche auf Grund des LDAP-Such-Strings gefunden wurden, als Wert des ''member''-Attributs dem Rückgabewert der Ausleseoperation hinzugefügt werden sollen. Der Wert für das Attribut ''dn'' enthält den Eintrag ''olcDatabase={2}hdb''. Wenn Sie bis hierher ausschliesslich diesem Howto gefolgt sind, sollte dies so richtig sein. Sind Sie jedoch gerade daran, einen weiteren Suffix zu konfigurieren, so wird dies nicht richtig sein. Passen Sie bitten diesen Teil entsprechend richtig an! Nun müssen diese Daten wieder in den DIT. # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/dynlist_activateOnSuffix.ldif Enter LDAP Password: adding new entry "olcOverlay=dynlist,olcDatabase={2}hdb,cn=config" \\ ===== AccessLog ===== Diese Overlay erlaubt es, Zugriffe jeder Art - add, read, modify und delete - unterhalb eines separaten Suffix zu loggen. \\ ==== Datenbank ==== An dieser Stelle gehe ich davon aus, dass Sie Konfiguration für den ''dc=logs''-Suffix bereits im Abschnitt der Konfiguration mit erstellt haben und so muss die zugehörige Datenbank lediglich noch mit initialen Daten befüllt werden. Hierzu legen Sie eine Textdatei mit folgendem Inhalt an und speichern Sie sie unter dem Dateinamen ''suffix_logs_init.ldif'' ab. dn: dc=logs objectClass: dcObject objectClass: organization dc: logs o: Logging Dummy Organization Nun initiieren Sie den ''dc=logs''-Suffix mit folgendem Kommando. # ldapadd -D "cn=Manager,dc=logs" -x -W -f /root/build/openldap/ldif/suffix_logs_init.ldif Enter LDAP Password: adding new entry "dc=logs" \\ ==== Aktivieren ==== Um das AccessLog-Overlays zu aktivieren, müss OpenLDAP zunächst instruiert werden, das zugehörige Modul zu laden. Öffnen Sie hierzu eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''accesslog_moduleLoad.ldif'' ab. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: accesslog.so Anschliessend wird die Modifikation am Konfigurations-DIT durchgeführt. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/accesslog_moduleLoad.ldif Enter LDAP Password: modifying entry "cn=module{0},cn=config" Es ist nicht notwendig, den OpenLDAP Server neu zu starten, das Modul wird automatisch zur Laufzeit geladen. Zu guter letzt muss das Overlay für jeden Suffix aktiviert werden, in welchem es verfügbar sein soll. In Rahmen dieses Howtos ist das der ''dc=mydomain,dc=local''-Suffix. Erstellen Sie eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''accesslog_activateOnSuffix.ldif'' ab. dn: olcOverlay=accesslog,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcAccessLogDB: dc=logs olcAccessLogOps: writes #olcAccessLogOps: reads olcAccessLogPurge: 30+00:00 1+00:00 olcOverlay: accesslog Mit diesem Eintrag wird das AccessLog-Overlay für den ''dc=mydomain,dc=local''-Suffix aktiviert und konfiguriert. \\ Die folgenden Einstellungen sind hier abgebildet. * ''olcAccessLogOps: writes'' aktiviert das Logging für Schreibeoperationen wie ''add'', ''modifiy'', ''delete'' * ''olcAccessLogOps: reads'' aktiviert das Logging für alle Such- und Leseoperationen (Hier auskommentiert -> Performance) * ''olcAccessLogPurge: 30+00:00 1+00:00'' legt fest, dass einmal pro Tag alle Logeinträge gelöscht werden, die älter als 30 Tage sind Der Wert für das Attribut ''dn'' enthält den Eintrag ''olcDatabase={2}hdb''. Wenn Sie bis hierher ausschliesslich diesem Howto gefolgt sind, sollte dies so richtig sein. Sind Sie jedoch gerade daran, einen weiteren Suffix zu konfigurieren, so wird dies nicht richtig sein. Passen Sie bitten diesen Teil entsprechend richtig an! Nun müssen diese Daten wieder in den DIT. # ldapadd -D "cn=config" -x -W -f /root/build/openldap/ldif/accesslog_activateOnSuffix.ldif Enter LDAP Password: adding new entry "olcOverlay=accesslog,olcDatabase={2}hdb,cn=config" \\ ==== Indizes ==== Nun, da das ''AccessLog''-Overlay aktiviert wurde, sollten noch ein, zwei Indizes für den ''dc=log''-Suffix definiert werden, welche die Suche innerhalb dessen deutlich beschleunigen werden. \\ \\ Erstellen Sie hierzu eine neue Textdatei und speichern Sie sie mit folgendem Inhalt ab. dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcDbIndex olcDbIndex: objectClass eq olcDbIndex: reqStart eq olcDbIndex: reqStop eq Anschliessend aktivieren Sie diese Indizes durch den Aufruf des folgenden Kommandos. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/accesslog_indizes.ldif \\ ==== Test ==== Erstellen Sie eine neue Textdatei mit dem folgenden Inhalt und speichern Sie sie unter dem Dateinamen ''accesslog_test.ldif'' ab. dn: ou=TEST,ou=Config,dc=mydomain,dc=local objectClass: organizationalUnit objectClass: top ou: TEST Führen Sie nun die folenden Kommandos aus. # ldapadd -D "cn=Manager,dc=mydomain,dc=local" -x -W -f /root/build/openldap/ldif/accesslog_test.ldif Enter LDAP Password: adding new entry "ou=TEST,ou=Config,dc=mydomain,dc=local" # ldapdelete -D "cn=Manager,dc=mydomain,dc=local" -x -W ou=TEST,ou=Config,dc=mydomain,dc=local Nun überprügen Sie, dass die Ausgabe des folgenden Kommandos in etwa wie nach stehend aussieht. # ldapsearch -D "cn=Manager,dc=logs" -x -W -b dc=logs objectClass=* Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: objectClass=* # requesting: ALL # # logs dn: dc=logs objectClass: dcObject objectClass: organization dc: logs o: Logging Dummy Organization # 20071223154546.000001Z, logs dn: reqStart=20071223154546.000001Z,dc=logs objectClass: auditAdd reqStart: 20071223154546.000001Z reqEnd: 20071223154546.000002Z reqType: add reqSession: 14 reqAuthzID: cn=config reqDN: ou=TEST,ou=Config,dc=mydomain,dc=local reqMessage: no write access to parent reqResult: 50 reqMod: objectClass:+ organizationalUnit reqMod: objectClass:+ top reqMod: ou:+ TEST reqMod: structuralObjectClass:+ organizationalUnit reqMod: entryUUID:+ df122c3e-45b9-102c-8125-350e647f3b53 reqMod: creatorsName:+ cn=config reqMod: createTimestamp:+ 20071223154546Z reqMod: entryCSN:+ 20071223154546Z#000000#00#000000 reqMod: modifiersName:+ cn=config reqMod: modifyTimestamp:+ 20071223154546Z # 20071223154613.000001Z, logs dn: reqStart=20071223154613.000001Z,dc=logs objectClass: auditAdd reqStart: 20071223154613.000001Z reqEnd: 20071223154613.000002Z reqType: add reqSession: 15 reqAuthzID: cn=Manager,dc=mydomain,dc=local reqDN: ou=TEST,ou=Config,dc=mydomain,dc=local reqResult: 0 reqMod: objectClass:+ organizationalUnit reqMod: objectClass:+ top reqMod: ou:+ TEST reqMod: structuralObjectClass:+ organizationalUnit reqMod: entryUUID:+ ef028774-45b9-102c-8127-350e647f3b53 reqMod: creatorsName:+ cn=Manager,dc=mydomain,dc=local reqMod: createTimestamp:+ 20071223154613Z reqMod: entryCSN:+ 20071223154613Z#000000#00#000000 reqMod: modifiersName:+ cn=Manager,dc=mydomain,dc=local reqMod: modifyTimestamp:+ 20071223154613Z # 20071223154710.000001Z, logs dn: reqStart=20071223154710.000001Z,dc=logs objectClass: auditDelete reqStart: 20071223154710.000001Z reqEnd: 20071223154710.000002Z reqType: delete reqSession: 16 reqAuthzID: cn=Manager,dc=mydomain,dc=local reqDN: ou=TEST,ou=Config,dc=mydomain,dc=local reqResult: 0 # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 \\ ===== RefInt ===== FIXME Zum Zeitpunkt der Erstellung dieses Howtos ist die Unterstützung der Konfiguration des RefInt-Overlays im DIT noch nicht implementiert. Auf Anfrage bei den Entwicklern des OpenLDAP Servers wurde mir mitgeteilt, dass dies für die Versionen 2.4.x geplant sei. Somit gilt es leider abzuwarten, bis diese Implementierung vorliegt. Diese Overlay garantiert uns Referentiele Integrität innerhalb unseres DITs. Wann immer ein Eintrag aus dem DIT gelöscht wird, sucht dieses Overlay im DIT nach Einträgen, bei denen ein oderer mehrere Attribute im Wert den DN des zu löschenden Eintrags einthalten und sorgt dafür, dass sie entfernt werden. \\ ==== Aktivieren ==== Um das DynList-Overlays zu aktivieren, müss OpenLDAP zunächst instruiert werden, das zugehörige Modul zu laden. Öffnen Sie hierzu eine neue Textdatei und speichern Sie sie mit dem folgenden Inhalt unter dem Dateinamen ''refint_moduleLoad.ldif'' ab. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: refint.so Anschliessend wird die Modifikation am Konfigurations-DIT durchgeführt. # ldapmodify -D "cn=config" -x -W -f /root/build/openldap/ldif/refint_moduleLoad.ldif Enter LDAP Password: modifying entry "cn=module{0},cn=config" Es ist nicht notwendig, den OpenLDAP Server neu zu starten, das Modul wird automatisch zur Laufzeit geladen. \\