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:

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.

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.

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 OpenSSL Howto beschrieben.

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"

...

Bevor OpenLDAP installiert werden kann, müssen zunächst die folgenden Packete installiert werden.

1. MIT-Kerberos
2. Courier-Authlib
3. Courier-IMAP
4. Cyrus-SASL
5. CUPS
6. Samba

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

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

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 ??? 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.

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

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

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.

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

Installieren Sie Samba mit dem folgenden Kommando.

# emerge --verbose cups

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

Installieren Sie Samba mit dem folgenden Kommando.

# emerge --verbose samba

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

Anschliessend wird OpenLDAP installiert.

# emerge --verbose openldap

Dieser Abschnitt dient dazu, jegliche Konfiguration vorzunehmen, welche notwendig ist, bevor der OpenLDAP Server das erste mal regulär gestartet werden kann.

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.

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 # <kbyte> <min>
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`.

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==

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.

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

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

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

Nun ist es an der Zeit, unseren OpenLDAP das erste mal zu starten.

# /etc/init.d/slapd start

# rcslapd {start|stop|restart|pause|zap}

Antwortet das Startskript mit einem OK so haben Sie es geschafft, der OpenLDAP Server läuft.

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.

1. Sehen Sie mal was, wenn Sie den DIT mit einem graphischen Client-Tool betrachten
2. Gibt es Ihnen ein Gefühl dafür, wie ein einfacher DIT aufgebaut sein kann
3. 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"

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

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.

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"

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"

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"

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"

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.

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.

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"

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 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

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.

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

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"

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 OpenSSL Howto genaue Instruktionen, wie ein solches erstellt werden kann.

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

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"

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.

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.

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

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=*

''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.

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

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"

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=<username>,cn=digest-md5,cn=auth
• uid=<username>,cn=<realm>,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.

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.

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"

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"

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"

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"

Führen Sie das folgende Kommando aus

# ldapsearch -I -Z -Y DIGEST-MD5 objectclass=*

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.

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…

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 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"

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"

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

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"

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.

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"

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"

Diese Overlay erlaubt es, dynamisch die Mitglieder von Gruppen erstellen zu lassen, wobei die Gruppenmitgliedschaft mittels einer LDAP-Abfrage definiert wird.

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 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"

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"

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.

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"

Diese Overlay erlaubt es, Zugriffe jeder Art - add, read, modify und delete - unterhalb eines separaten Suffix zu loggen.

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"

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"

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

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"

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

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 <dc=logs> 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

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.

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"