Nachdem Sie jetzt einen LDAP-Server eingerichtet haben, soll es in diesem Kapitel um die ersten Schritte zur Objektverwaltung gehen. Hier werden wir Ihnen zeigen, wie Sie neue Objekte sowohl über LDIF-Dateien als auch über grafische Werkzeuge verwalten können. Die Distribution, die Sie verwenden, spielt jetzt keine Rolle mehr. Die Verwendung der Kommandos ist bei allen Distributionen identisch.
| 6.1 | Anlegen neuer Objekte |
Während der Installation haben Sie schon gesehen, wie Sie Benutzer und Gruppen mithilfe von LDIF-Dateien anlegen können. An dieser Stelle möchten wir jetzt etwas genauer auf diesen Vorgang eingehen.
Immer, wenn Sie neue Objekte anlegen, stellt sich die Frage: „Mache ich das über die Kommandozeile oder mit einem grafischen Werkzeug?“ Aus diesem Grund wollen wir Ihnen beide Möglichkeiten hier erklären. Anfangen möchten wir mit der Erstellung von Objekten über LDIF-Dateien. Warum das? Weil Sie damit später auch die Möglichkeit haben, sehr viele Objekte über Skripte anlegen zu können. Sie sind dann in der Lage, die Informationen, die Sie für die Objekte benötigen, aus CSV-Dateien zu lesen, und brauchen nicht jedes Objekt einzeln zu erstellen.
Wenn Sie neue Objekte anlegen, überlegen Sie sich erst, welche Objektklassen für das Objekt benötigt und welche Attribute aus den verwendeten Objektklassen unbedingt vergeben werden. Ein Objekt, das Sie neu anlegen, muss immer genau eine Structural Object-Class besitzen. Wie viele Auxiliary ObjectClasses ein Objekt besitzt, hängt nur davon ab, welche Attribute Sie verwenden wollen.
| 6.1.1 | Anlegen von Organizational Units (OUs) |
Der große Vorteil eines LDAP-Baums ist, dass Sie Ihre Objekte strukturiert anlegen können. Der LDAP-Baum kann Ihre komplette Unternehmensstruktur abbilden, und so sind Sie in der Lage, einfach und schnell bestimmte Objekte finden und neue Objekte an der passenden Stelle ablegen zu können.
Durch die Verwendung von Organizational Units (OUs) können Sie später auch die Zugriffe auf die Objekte im LDAP-Baum über Access Control Lists (ACLs) steuern. Wie ACLs verwendet, eingerichtet und verwaltet werden, lesen Sie in Kapitel 9, «Berechtigungen mit ACLs».
Sie brauchen nicht für jede OU eine eigene LDIF-Datei anlegen, sondern können mit einer LDIF-Datei auch mehrere OUs auf einmal einrichten. Auch verschachtelte OUs lassen sich so mit einer LDIF-Datei erzeugen. Achten Sie nur darauf, dass Sie die obersten Ebenen als Erstes in die Datei schreiben, da die LDIF-Datei der Reihe nach abgearbeitet wird. Als Erstes machen Sie sich Gedanken, wie Ihre Struktur aussehen soll. In Bild 6.1 sehen Sie die Struktur, die wir hier anlegen wollen und auf die wir auch später bei der Einrichtung der ACLs zurückkommen werden.
Bild 6.1 Struktur des LDAP-Baums
In Listing 6.1 sehen Sie die LDIF-Datei, mit der die Struktur angelegt wird:
Listing 6.1 LDIF-Datei für die Struktur
dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example dn: ou=users,dc=example,dc=net ou: users objectClass: organizationalUnit dn: ou=groups,dc=example,dc=net ou: groups objectClass: organizationalUnit dn: ou=Verwaltung,dc=example,dc=net ou: Verwaltung objectClass: organizationalUnit objectClass: top dn: ou=Produktion,dc=example,dc=net ou: Produktion objectClass: organizationalUnit objectClass: top dn: ou=users,ou=Produktion,dc=example,dc=net ou: users objectClass: organizationalUnit objectClass: top dn: ou=Adressen,ou=Produktion,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=groups,ou=Produktion,dc=example,dc=net ou: groups objectClass: organizationalUnit objectClass: top dn: ou=Adressen,ou=Verwaltung,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=groups,ou=Verwaltung,dc=example,dc=net ou: groups objectClass: organizationalUnit objectClass: top dn: ou=users,ou=Verwaltung,dc=example,dc=net ou: users objectClass: organizationalUnit objectClass: top dn: ou=Adressen,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top
Nachdem Sie die LDIF-Datei für die Struktur erstellt haben, können Sie die neue Struktur mit dem Kommando ldapadd einspielen, so wie in Listing 6.2:
Listing 6.2 Einspielen der LDIF-Datei
root@provider01:/daten# ldapadd -x -D "cn=admin,dc=example,dc=net" -W -f /daten/struktur.ldif Enter LDAP Password: adding new entry "ou=Firma,dc=example,dc=net" adding new entry "ou=Verwaltung,ou=Firma,dc=example,dc=net" adding new entry "ou=users,ou=Verwaltung,ou=Firma,dc=example,dc=net" adding new entry "ou=groups,ou=Verwaltung,ou=Firma,dc=example,dc=net" adding new entry "ou=Produktion,ou=Firma,dc=example,dc=net" adding new entry "ou=users,ou=Produktion,ou=Firma,dc=example,dc=net" adding new entry "ou=groups,ou=Produktion,ou=Firma,dc=example,dc=net"
Auch mit den grafischen Werkzeugen können Sie sich die Struktur ansehen. In Bild 6.2 sehen Sie die Struktur in der Baumansicht des LAM.
Bild 6.2 Die Struktur im LAM
Hinweise zur Struktur
An dieser Stelle möchten wir kurz erklären, warum wir die Struktur so gewählt haben. Bei der Planung Ihrer Struktur achten Sie immer darauf, dass Sie die Struktur einfach erweitern können und dass sie übersichtlich bleibt. Die Struktur sollte oben schmal und nach unten breiter werden. Sie sehen, dass wir in der Ebene unterhalb der Domäne einen Standort ou=Firma erstellt haben. So bleibt die Möglichkeit, weitere Standorte auf derselben Ebene zu erstellen und darunter eine ähnliche Struktur mit Abteilungen, Benutzern und Gruppen anzulegen. Die beiden OUs auf derselben Ebene wie der Standort dienen dazu, Benutzer und Gruppen zu verwalten, die den Standorten übergeordnet sind. Dort werden wir immer Gruppen und Benutzer ablegen, die entweder für einen Dienst verantwortlich sind oder standortübergreifend genutzt werden. Es folgen ein paar Vorschläge, die Sie bei Ihrer Planung berücksichtigen sollten:
Planen Sie erst auf dem Papier, bevor Sie die Struktur im LDAP anlegen. Denn wer kennt das nicht? Da hat man etwas erstellt, und jetzt soll alles wieder gelöscht werden, weil es anders besser wäre. Auf Papier ist eine Änderung schneller gemacht.
Erstellen Sie vor der Planung der Struktur einen Namensstandard für alle Objekte. Gerade beim Aufbau der Struktur und der späteren Verwendung von ACLs kann eine einheitliche Namensgebung von Vorteil sein.
Planen Sie die Struktur von oben nach unten.
Erstellen Sie Dokumentationen, wie ein neuer Standort anzulegen und wie die Struktur der OUs in den Standorten zu erstellen ist. Auch hier werden Sie spätestens bei den ACLs sehen, wie wichtig das ist.
| 6.1.2 | Anlegen von Benutzern und Gruppen |
Bei der Verwaltung der Benutzer- und Gruppenobjekte haben Sie im OpenLDAP sehr viele Möglichkeiten: von einfachen POSIX-Accounts bis hin zu komplexen Benutzer-Accounts, die sich aus den verschiedensten Objektklassen zusammensetzen. Egal ob Sie die ssh-Schlüssel der Benutzer oder ihre Mail-Attribute verwalten wollen, alles ist möglich. Auch haben Sie immer noch die Möglichkeit, eigene Schemata mit eigenen Attributen und Objektklassen zu entwerfen und damit die Benutzerobjekte zu erweitern. Alle Möglichkeiten hier anzusprechen, würde bei Weitem den Rahmen dieses Buches sprengen. Im Verlauf des Buches werden wir Ihnen aber noch zeigen, wie Sie die bestehenden Benutzer um Kerberos-Attribute erweitern können. Auch werden Sie erfahren, wie Sie eigene Gruppentypen erstellen.
In Listing 6.3 sehen Sie eine LDIF-Datei, mit der zusätzliche Gruppen und Benutzer angelegt werden:
Listing 6.3 LDIF für Benutzer und Gruppen
dn: dn: cn=u1-Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u1-prod uid: u1-prod cn: u1-Prod userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZGJmZGRkc3NzMTIzNDU$W+3 A5630GWZE2pOfoT4pI8huoD9Uuss0tFw/CGmhIJ0 uidNumber: 10001 gidNumber: 10000 sn: Prod givenName: u1 dn: cn=u2-Prod,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u2-prod uid: u2-prod cn: u2-Prod userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1 $ZGJmZGRkc3NzMTIzNDY$WhTyubew41XRmGwvqpcPcnN/ri2XhpBdnvHJO/tw69c uidNumber: 10002 gidNumber: 10000 sn: Prod givenName: u2 dn: cn=prod-al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/prod-al uid: prod-al cn: prod-al userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1 $ZGJmZGRkc3NzMTIzNDc$87VL92CE8AHQoS7vP4UpQetGJgLH39MdxjGlzIAMNWU uidNumber: 10003 gidNumber: 10000 sn: al givenName: prod employeeType: Abteilungsleiter dn: cn=u1-Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u1-verw uid: u1-verw cn: u1-Verw userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1 $ZGJmZGRkc3NzMTIzNDg$0tRScpmdeUoX14JfH6SWf7mtx6sjL30vFR+IeVgmiK8 uidNumber: 10004 gidNumber: 10000 sn: Verw givenName: u1 dn: cn=u2-Verw,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/u2-verw uid: u2-verw cn: u2-Verw userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1 $ZGJmZGRkc3NzMTIzNDk$4gzEyjyU3kviVI867268fd4s/VZR8sVCMBNtD38AvRA uidNumber: 10005 gidNumber: 10000 sn: Verw givenName: U2 dn: cn=Verw-al,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixAccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person loginShell: /bin/bash homeDirectory: /home/verw-al uid: verw-al cn: Verw-al userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1 $ZGJmZGRkc3NzMTIzNDA$zGsNJMhksq6c7RfWWpQXa2WMBrdJ6sM7P1KH9AD9pCI uidNumber: 10006 gidNumber: 10000 sn: al givenName: Verw employeeType: Abteilungsleiter dn: ou=Adressen,cn=u1 Verw,ou=users,ou=Verwaltung,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=U2 Verw,ou=users,ou=Verwaltung,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=Verw al,ou=users,ou=Verwaltung,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=prod al,ou=users,ou=Produktion,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=u1 Prod,ou=users,ou=Produktion,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: ou=Adressen,cn=u2 Prod,ou=users,ou=Produktion,dc=example,dc=net ou: Adressen objectClass: organizationalUnit objectClass: top dn: cn=verwaltung,ou=groups,ou=Verwaltung,ou=firma,dc=example,dc=net objectClass: posixGroup gidNumber: 10002 cn: verwaltung memberUid: u1-verw memberUid: u2-verw memberUid: verw-al dn: cn=produktion,ou=groups,ou=Produktion,ou=firma,dc=example,dc=net objectClass: posixGroup gidNumber: 10003 cn: produktion memberUid: prod-al memberUid: u1-prod memberUid: u2-prod
Bei den Benutzern fällt auf, dass hier auch gleich das Passwort mit eingespielt wird. Sie können Passwörter auf zwei verschiedene Arten in eine LDIF-Datei eintragen. Eine Möglichkeit wäre es, das Kennwort Base64-kodiert einzutragen. Dann müssten Sie zwei Doppelpunkte hinter userPassword setzen. Die Base64-Kodierung hat aber den Nachteil, dass sich der ursprüngliche Wert mit dem Befehl base64 leicht berechnen lässt. Jeder, der die LDIF-Datei lesen kann, kann dann auch die Kennworte der Benutzer auslesen. Daher empfiehlt es sich, das Passwort in dem von Ihnen bevorzugten Passworthash (hier ARGON2) einzutragen. Dann folgt dem Attributsnamen nur ein Doppelpunkt.
Tipp: Neue Passwörter können Sie auf der Kommandoebene mit dem Kommando slappasswd generieren und anschließend in die LDIF-Datei eintragen. Für ARGON2-Passwörter verwenden Sie das Kommando echo -n "passwort" | argon2 "saltsalt" -e.
| 6.2 | Ändern von Attributen |
Wenn Sie die Benutzer angelegt haben und später einzelne Attribute verändern oder hinzufügen wollen, können Sie die Änderungen ebenfalls über LDIF-Dateien durchführen. Für die Modifizierungen der Objekte verwenden Sie das Kommando ldapmodify. Für die Modifizierung der Attribute können Sie die folgenden Aktionen wählen:
add
Mit add können Sie neue Attribute zu Objekten hinzufügen. Im Beispiel in Listing 6.4 soll einem Benutzer das Attribut mail hinzugefügt werden.
Listing 6.4 Hinzufühen eines Attributes
dn: cn=prod-al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net changetype: modify add: mail mail: prod-al@example.net
Handelt es sich um ein single value-Attribut und ist dies bereits mit einem Wert belegt, so bekommen Sie die Fehlermeldung wie in Listing 6.5:
Listing 6.5 Fehler beim Hinzufügen
[root@provider01]# ldapmodify -x -D cn=admin,dc=example,dc=net \ -W -f add-mail.ldif Enter LDAP Password: modifying entry "cn=prod-al,ou=users,ou=Produktion,ou=firma,\ dc=example,dc=net" ldap_modify: Type or value exists (20) additional info: modify/add: mail: value #0 already exists
Im Fall eines multi value-Attributes – wie z.B. beim Attribut member einer Gruppe – würde ein weiteres Attribut mit dem Wert hinzugefügt.
delete
Einzelne Attribute können Sie mit der Option delete löschen. Wollen Sie den Wert für die E-Mail-Adresse aus dem vorigen Beispiel wieder löschen, können Sie dies mit dem Beispiel aus Listing 6.6 tun:
Listing 6.6 Löschen eines Attributes
dn: cn=prod-al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net changetype: modify delete: mail
Handelt es sich bei dem Attribut um ein multi value-Attribut, können Sie so auch einzelne Werte löschen. Dann muss die LDIF-Datei noch das Attribut und den zu löschenden Wert enthalten.
replace
Mit der Option replace haben Sie die Möglichkeit, einzelne Attribute zu ersetzen. Ist ein Attribut noch nicht vergeben, wird das Attribut gesetzt. Geben Sie keinen Wert an, aber das Attribut ist im Objekt mit einem Wert belegt, wird das Attribut gelöscht. Wollen Sie die E-Mail aus unserem Beispiel nicht löschen, sondern ersetzen, so könnten Sie das Beispiel aus Listing 6.7 verwenden.
Listing 6.7 Ersetzen eines Attributes
dn: cn=prod-al,ou=users,ou=Produktion,ou=firma,dc=example,dc=net changetype: modify replace: mail mail: al-prod@example.net
Sie können Änderungen an einem Objekt sowie an mehreren Objekten auch zusammenfassen. In Listing 6.8 sehen Sie eine LDIF-Datei, mit der mehrere Attribute bei mehreren Benutzern angepasst werden.
Listing 6.8 LDIF-Datei für die Anpassung
dn: cn=prod-al,ou=users,ou=produktion,ou=firma,dc=example,dc=net changetype: modify add: mail mail: al-prod@example.net - replace: loginShell loginShell: /usr/bin/zsh - delete: employeeType dn: cn=u1-prod,ou=users,ou=produktion,ou=firma,dc=example,dc=net changetype: modify add: employeeType employeeType: Abteilungsleiter - replace: description description: Neuer Abteilungsleiter
Tipp: Bevor Sie die Änderung einspielen, können Sie mit dem Kommando ldapmodify -n -f <LDIF-datei> testen, was passiert und ob die Syntax korrekt ist.
Als Erstes müssen Sie immer den dn des Objektes angeben, welches verändert werden soll. In der nächsten Zeile geben Sie an, dass Sie ein bestehendes Objekt modifizieren wollen. Würden Sie hier modify durch ein add ersetzen, könnten Sie so mit dem Kommando ldapmodify auch ein neues Objekt erzeugen. Dann folgt die durchzuführende Änderung an dem Objekt. Wie Sie sehen, trennen Sie Änderungen an einem einzelnen Objekt mit einem Minuszeichen, Änderungen an unterschiedlichen Objekten mit einer Leerzeile.
Wichtig: Achten Sie auf die Leerzeichen! Weder am Anfang der Zeile noch am Ende darf ein zusätzliches Leerzeichen stehen. Nach dem Doppelpunkt müssen Sie genau ein Leerzeichen einfügen. Jedes weitere Leerzeichen führt später zu Fehlermeldungen. Wenn Sie mit vi als Editor arbeiten, können Sie die Option set list aktiveren. Dann bekommen Sie alle Sonderzeichen angezeigt.
Wollen Sie, so wie im Beispiel, mehrere Benutzer über eine LDIF-Datei anpassen, achten Sie darauf, dass zwischen dem letzten Attribut des ersten Benutzers und dem neuen DN immer eine Leerzeile vorhanden ist, welche keine Leerzeichen enthält.
| 6.3 | Der neue Administrator |
Im Moment werden Sie stets alle Änderungen am LDAP-Baum mit dem rootDN durchführen, da dieser Benutzer immer alle Rechte an allen Objekten besitzt. Im Hinblick auf die Sicherheit ist das aber keine gute Lösung. Besser ist, ein Benutzerobjekt anzulegen, dem Sie später über die ACLs die Möglichkeit geben, alle Änderungen an Ihrem LDAP-Baum durchzuführen. Der Vorteil ist der, dass Sie diesen Benutzer jederzeit wieder in seinen Rechten einschränken können. So haben Sie auch die Chance, zwei oder mehr Benutzern die Administration zu übergeben und die Administration des LDAP-Baums auch in einzelne Teilbäume unterteilen zu können. In Kapitel 9, «Berechtigungen mit ACLs», werden Sie dann sehen, wie Sie die entsprechenden Rechte vergeben können. Bei dem Benutzer handelt es sich jetzt nicht um einen POSIX-Account, sondern nur um ein simpleSecurityObject. Dieses Objekt hat den Vorteil, dass eine Anmeldung an einem Host nicht möglich ist. Diese Art von Benutzer dient ausschließlich der Authentifizierung am LDAP-Verzeichnis. In dem Objekt werden auch nur zwei Attribute benötigt: uid und userPassword.
Auch für diese Benutzer schreiben Sie entweder eine LDIF-Datei (ein Beispiel finden Sie in Listing 6.9) oder Sie legen den Benutzer über das grafische Werkzeug Ihrer Wahl an:
Listing 6.9 LDIF für den neuen Administrator
dn: uid=ldap-admin,ou=users,dc=example,dc=net objectClass: account objectClass: simpleSecurityObject objectClass: top uid: ldap-admin userPassword: $argon2i$v=19$m=4096,t=3,p=1$dGVzdHRlc3R0ZXN0$EtO6f9GaTUasR \ ZpzDNVuwSDzGRW8NKYWX4bC+gKdJUo
Zur Zeit können Sie diesen Benutzer nur für lesende Zugriffe auf den LDAP-Baum nutzen. Erst wenn Sie die ACLs angepasst haben, können Sie mit diesem Benutzer die Änderungen am LDAP-Baum durchführen.
Sorgen Sie jetzt noch dafür, dass der ldap-admin auch alle Objekte lesen kann. In der Grundkonfiguration haben wir den Wert für olcSizeLimit auf 500 festgelegt. Dieser Wert gilt für alle Benutzer außer für den rootDN. Wenn Sie das Limit für den ldap-admin nicht anpassen, könnte der ldap-admin immer nur die ersten 500 Objekte auflisten lassen. In Listing 6.10 sehen Sie die Änderungen, die Sie benötigen:
Listing 6.10 Limit des ldap-admin aufheben
dn: olcDatabase={2}mdb,cn=config changetype: modify add: olcLimits olcLimits: dn.exact="cn=uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited
| 6.4 | Änderungen direkt in der Datenbank |
Bis hierher haben wir Änderungen direkt am laufenden LDAP-Server durchgeführt. Mit den slap*-Tools haben Sie die Möglichkeit, direkt auf der Datenbank zu arbeiten, ohne dass der Dienst läuft. Dies hat zum Beispiel der Vorteil, den Dienst zu Wartungszwecken herunterzufahren und trotzdem auf die Datenbank zugreifen zu können. Zu den Tools gehören unter anderem die folgenden:
slapacl testet den Zugriff eines Benutzers innerhalb der Datenbank. Folgendes Beispiel prüft, ob ein Benutzer user1 das Kennwort von user2 ändern darf:
Listing 6.11 Anwendung von slapacl
root@provider01:~# slapacl -b cn=user1,dc=example,dc=net \ -D "cn=user2,dc=example,dc=net" "userPassword/write" authcDN: "cn=u1-prod,ou=users,ou=produktion,ou=firma,dc=example,dc=net" write access to userPassword: DENIED
slapadd fügt Objekte im LDIF-Format der Datenbank hinzu. Dabei können Sie mit der Option -l eine LDIF-Datei angeben. Mit der Option -u können Sie zudem das Hinzufügen zunächst testen.
Wichtig: Sollten durch slapadd LDIF-Dateien erstellt werden, so ist der Besitzer, welcher den Befehl ausführt, automatisch Besitzer dieser Dateien. Verwenden Sie diesen Befehl daher – beispielsweise unter Benutzung von sudo – unter dem Benutzer, mit welchem der slapd läuft, oder ändern Sie vor dem Start des Dienstes die Rechte ggf. mit chown.
slapcat gibt Ihnen den Inhalt (von Teilen) der Datenbank als LDIF-Datei zurück. Mit der Option -a können Sie die Ausgabe auf einen Teilbaum beschränken. Darüber hinaus können Sie mit der Option -H eine LDAP-URI zur Filterung angeben. Zwei Beispiele wären dafür
ldap:///ou=firma,dc=example,dc=net??? liefert alle Objekte aus dem Teilbaum ou=firma,dc=example,dc=net.
ldap:///???(&(objectClass=inetOrgPerson)(cn=*prod*)) liefert aus der gesamten Datenbank alle Objekte der Klasse inetOrgPerson, deren CN die Zeichenkette prod enthält.
slapindex erstellt den Index der Datenbank neu. Mit der Option -n können Sie zudem die Nummer der Datenbank angeben, für welche dies durchgeführt werden soll. Ansonsten wird die erste Datenbank verwendet, für die eine Indexierung möglich ist.
slapmodify erlaubt Änderungen an Datenbankobjekten. Die Änderungen müssen wie bei slapadd im LDIF-Format angegeben werden (auch hier gilt der Hinweis hinsichtlich der eventuell erstellten LDIF-Dateien und den Rechten).
slappasswd ermöglicht das Ändern des Kennwortes.
slapschema erlaubt die Prüfung, ob Objekte in der Datenbank gegen das Schema verstoßen.
slaptest prüft die Syntax der Konfiguration auf mögliche Fehler. Sinnvoll kann dies nach manuellen Änderungen sein, bevor der Dienst neu gestartet wird.
Wichtig: Führen Sie Änderungen an der Datenbank mit diesen Tools durch, während der Dienst läuft, so hat der Dienst keine Kenntnis von diesen Änderungen. Diese werden erst nach einem Neustart des Dienstes sichtbar.