LDAP-Auth-Server
Grundbegriffe der Datenbank eines LDAP-Servers (SLAPD)
Inhalt
- Einführung
- Vorteile gegenüber anderen Datenbanken
- Konfigurationsmöglichkeiten
- Arbeitsweise
- Performanz
- Erstellen der Datenbank
- Quellen
- Anhang
- slapd.conf
- LDIF-Datei
Einführung
LDAP ist das Lightweight Directory Access Protocol. Dieses Dokument soll eine Einführung in die Datenbank LDBM des LDAP-Unix-Daemons Slapd geben.
Vorteile gegenüber anderen Datenbanken
Die LDBM Datenbank von Slapd ist gegenüber anderen konventionellen Datenbank leseoptimiert. Da bei LDAP die meisten Datenbankzugriffe im Lesemodus stattfinden, ist das auch durchaus sinnvoll. Änderungen oder Ergänzungen zum bestehenden Inhalt (schreiben) sind relativ selten im Gegensatz zu Abfragen (lesen).
In der LDBM können problemlos und performant bis zu einer Million Einträge existieren.
Importe und Exporte von Daten aus der bzw. in die Datenbank können mithilfe sogenannter LDIF-Dateien vereinfacht werden.
Für die Datenbank stehen Konsolenwerkzeuge zur Verfügung, mit denen zügig Inhalte korrigiert, ergänzt und kontrolliert werden können (ldbmcat, ldbmtest).
LDBM kann zu jedem Eintrag einen Modifier-Eintrag erstellen, in diesem wird festgehalten, wer was wann geändert hat.
Konfigurationsmöglichkeiten
Die LDBM kann einfach über die slapd.conf konfiguriert werden. Dort werden Parameter für den Ort der Datenbank im System, cachesize etc festgelegt. Hier können auch alternative Quellen angegeben werden, wie etwa die '/etc/passwd'. Ein Beispiel für eine mögliche Konfiguration finden Sie im Anhang.
Arbeitsweise
Ein typischer Zugriff auf die Datenbank erfolgt beispielsweise so:
Slapd nimmt von einem LDAP-Client eine Anfrage entgegen. Dieser möchte aus der Datenbank alle Einträge auslesen, dessen Attribut NACHNAME den String 'Eismann' enthält. Slapd fragt LDBM nach dem Index des Attributs NACHNAME, durchsucht diese Liste nach 'Eismann' und erhält von der LDBM die EID's (Eintrag ID's) der zugeordneten Einträge. Jetzt weiss Slapd, nach welchen EID's zu suchen ist, und erhält aus dem id2entry-Index die Locationen der Strings, die der Anfrage entsprechen. Slapd wandelt den String (hier:Text) in LDAP-Format um, und verschickt ihn an den Client.
Performanz
LDBM benutzt harddisc-basierende Indexdateien.
Da die gesamte Performanz der Datenbank von diesen Indexdateien abhängt, können hier auch Optimierungen durchgeführt werden.
Zuerst möchte ich anführen, das in der Konfigurationsdatei slapd.conf die Möglichkeit besteht, diese Indexdateien in den Arbeitsspeicher der Maschine zu laden. Wird jetzt nicht mehr von der Festplatte, sondern aus dem Speicher gelesen, erhöht sich die Abfragegeschwindigkeit erheblich.
Als zweiten Punkt kann ich noch die richtige Indexierung der Datenbank anführen. Werden zuwenige Indexe gesetzt, werden die Suchzeiten (seektime) nach oben schnellen. Die 'richtigen' Indexe zu setzen, ist ebenso entscheidend. Wird etwa oft nach dem Attribut NACHNAME gesucht, empfiehlt es sich darauf einen index zu setzen. Einen Überblick erhält der Administrator, wenn er in der slapd.conf die Einträge für die Indexe kontrolliert und sicherstellt, das dort auch nur die Einträge verzeichnet sind, die auch wirklich gebraucht werden.
Für die Indexierung kann das Konsolentool 'ldif2index' benutzt werden.
Erstellen der Datenbank
Um eine LDBM-Datenbank zu erstellen, gibt es zwei Möglichkeiten: online oder offline. Haben etwa viele User Schreibzugriff auf eine LDBM-Datenbank während umfangreiche Modifikationen/Ergänzungen durchgeführt werden, kann es zu Komplikationen kommen, wenn gleichzeitig Einträge modifiziert werden. Derartige Offlineänderungen am LDAP-Verzeichnisdienst werden am unkompliziertesten mit dem Tool 'ldif2ldbm' bzw. mit dem Programm LDIF durchgeführt. Eigens für solche Zwecke wurde das LDIF-Dateiformat entwickelt, im Anhang können Sie ein Beispiel finden.
Kleinere Änderungen (bis zu einer Grössenordnung von etwa 5000 Einträgen) können auch alternativ mit einem LDAP-Client gemacht werden, ebenfalls gibt es wieder Konsolentools mit den leicht zu merkenden Namen 'ldapadd' und 'ldapmodify'.
Quellen
'SLAPD and SLURPD Administrator's Guide', University of Michigan, April 1996.
Anhang
- slapd.conf
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/redhat/rfc822-MailMember.schema
include /etc/openldap/schema/redhat/autofs.schema
include /etc/openldap/schema/redhat/kerberosobject.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
#pidfile //var/run/slapd.pid
#argsfile //var/run/slapd.args
# Create a replication log in /var/lib/ldap for use by slurpd.
#replogfile /var/lib/ldap/master-slapd.replog
# Load dynamic backend modules:
# modulepath /usr/sbin/openldap
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
#
# The next three lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions
# on slapd.pem so that the ldap user or group can read it.
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
# TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
#
# Sample Access Control
# Allow read access of root DSE
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
#
access to dn="" by * read
access to *
by self write
by users read
by anonymous auth
#
# if no access controls are present, the default is:
# Allow read by all
#
# rootdn can always write!
loglevel 4
##############################################
# ldbm database definitions
##############################################
database ldbm
#suffix "dc=my-domain,dc=com"
#suffix "o=My Organization Name,c=US"
#praktikant-51.internal.bln.de.colt-isc.net
suffix "dc=praktikant-51.internal.bln.de.colt-isc,dc=net"
#rootdn "cn=Manager,dc=my-domain,dc=com"
rootdn "cn=Manager,dc=praktikant-51.internal.bln.de.colt-isc,dc=net"
#rootdn "cn=Manager,o=My Organization Name,c=US"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
# Replicas to which we should propagate changes
#replica host=ldap-1.example.com:389 tls=yes
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com.at.EXAMPLE.COM
- LDIF-Datei
dn: dc=praktikant-51.internal.bln.de.colt-isc, dc=net
dc: colt-isc
objectClass: top
objectClass: domain
dn: dc=colt-isc, dc=net
dc: colt-isc
objectClass: top
objectClass: domain
dn: dc=de, dc=colt-isc, dc=net
dc: de
objectClass: top
objectClass: domain
dn: dc=bln, dc=de, dc=colt-isc, dc=net
dc: bln
objectClass: top
objectClass: domain
dn: dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
dc: internal
objectClass: top
objectClass: domain
dn: dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
dc: praktikant-51
objectClass: top
objectClass: domain
dn: ou=Hosts,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Hosts
objectClass: top
objectClass: organizationalUnit
dn: ou=Rpc,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Rpc
objectClass: top
objectClass: organizationalUnit
dn: ou=Services,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Services
objectClass: top
objectClass: organizationalUnit
dn: nisMapName=netgroup.byuser,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
nismapname: netgroup.byuser
objectClass: top
objectClass: nisMap
dn: ou=Mounts,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Mounts
objectClass: top
objectClass: organizationalUnit
dn: ou=Networks,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Networks
objectClass: top
objectClass: organizationalUnit
dn: ou=People,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: People
objectClass: top
objectClass: organizationalUnit
dn: ou=Group,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Group
objectClass: top
objectClass: organizationalUnit
dn: ou=Netgroup,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Netgroup
objectClass: top
objectClass: organizationalUnit
dn: ou=Protocols,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Protocols
objectClass: top
objectClass: organizationalUnit
dn: ou=Aliases,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
ou: Aliases
objectClass: top
objectClass: organizationalUnit
dn: nisMapName=netgroup.byhost,dc=praktikant-51, dc=internal, dc=bln, dc=de, dc=colt-isc, dc=net
nismapname: netgroup.byhost
objectClass: top
objectClass: nisMap
Inhalt
- Einführung
- Vorteile gegenüber anderen Datenbanken
- Konfigurationsmöglichkeiten
- Arbeitsweise
- Performanz
- Erstellen der Datenbank
- Quellen
- Anhang
- slapd.conf
- LDIF-Datei
Malte Eismann malte(_at_)fuldastrasse.de 23.2.2004