Alle Linux-Distributionen stellen den kostenlosen LDAP Server OpenLDAP zur Verfügung. Er kann problemlos über den Paket Manager der jeweiligen Distribution installiert werden. Für die Zwecke dieses Tutorials reichen die vorgeschlagenen Defaults zunächst aus. Später werden wir dann eine angepasste Directory-Struktur manuell konfigurieren.
Unter Debian werden die Pakete slapd und ldap-utils so installiert:
# apt-get install slapd ldap-utils Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libiodbc2 libldap-2.3-0 libltdl3 libslp1 ... Setting up slapd (2.3.30-5+etch1) ... Creating initial slapd configuration... done. Creating initial LDAP directory... done. Starting OpenLDAP: slapd. Setting up ldap-utils (2.3.30-5+etch1) ... |
Die LDAP Datenbank wird mit einer Standard Struktur und einem einzigen User, dem Admin-User, initialisiert. Für die ersten Experimente sind die vorgeschlagenen Defaults völlig ausreichend. Um diese Konfiguration bei Bedarf erneut durchzuführen, einfach
dpkg-reconfigure slapd |
ausführen.
Die folgenden Dialoge können für verschiedene Linux-Distributionen unterschiedlich sein.
Der erste Dialog fragt nach dem gewünschten "Base DN (distinguished name)" des LDAP Directories. Ein LDAP Server kann mehrere Directories verwalten, mit dieser Bezeichnung kann man direkt darauf zugreifen. Die Standardkonfiguration verwendet einfach den Domainnamen, um die Base DN zu erstellen. Dies ist nicht immer sinnvoll, eine Organisation wie eine Firma kann ja durchaus mehrere Domainnamen besitzen (oder auch gar keine), aber für die ersten Tests reichen die vorgeschlagenen Defaults aus.
Hier kann man eine beliebige Bezeichnung, z.B. den Firmennamen, angeben.
Außerdem wird das Administrator-Passwort abgefragt.
Alle weiteren Einstellungen sollte man bei den vorgeschlagenen Defaults belassen.
Diese Konfiguration wird (unter Debian) in /etc/ldap/slapd.conf abgespeichert, die etwa so aussehen sollte:
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel 0
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb
# The base of your directory in database #1
suffix "dc=schirmacher,dc=de"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# Indexing options for database #1
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=admin,dc=schirmacher,dc=de" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=schirmacher,dc=de" write
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=schirmacher,dc=de" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>
# The base of your directory for database #2
#suffix "dc=debian,dc=org"
|
Zunächst testen wir, ob der Zugriff auf unseren neuen LDAP Server funktioniert. Ein praktischer LDAP-Client ist z.B. JXplorer, den man kostenlos von http://www.jxplorer.org/ downloaden kann.
Die Default Einstellungen, die wir gerade konfiguriert haben, erlauben den anonymen Lese-Zugriff, wir brauchen also vorerst kein Passwort. Es reicht, den Servernamen und den Port anzugeben (der Port 389 ist der offizielle LDAP Port).
Wenn der LDAP Server läuft, sollte JXplorer in etwa das obige Bild darstellen. Durch Klicken auf die einzelnen Einträge in der Baumansicht kann man sich weitere Details anzeigen lassen.
Ein Eintrag in einem LDAP Directory wird durch seinen DN (Distinguished Name) identifiziert. Der "admin"-Eintrag in obigem Screenshot hat den DN "cn=admin,dc=schirmacher,dc=de". Um den DN herauszufinden, muss man sich in der Hierarchie von unten nach oben durchklicken und sich jeweils den blau hervorgehobenen Attribut-Typ sowie dessen Wert notieren.
Jeder Eintrag kann beliebig viele object classes enthalten, die ihrerseits unterschiedliche attributes enthalten. Dabei kann ein bestimmtes Attribut, z.B. "cn (common name)", durchaus in verschiedenen Objektklassen enthalten sein. Es ist so möglich, die benötigten Felder in einem Eintrag ganz nach Bedarf durch Kombinieren von vordefinierten Objektklassen zusammenzustellen. Ein Eintrag hat auch stets einen Parent DN (übergeordneten Eintrag). Auf diese Weise kann man beliebige Hierarchien aufbauen.
Der "admin" Eintrag hat z.B. die Objektklassen "simpleSecurityObject" sowie "organizationalRole". Die erste Klasse definiert das Attribut "userPassword", die zweite alle anderen Attribute. Fett dargestellte Attribute sind Pflichtfelder.
Wir wollen nun ein paar neue Einträge anlegen. Dazu müssen wir uns zunächst als Administrator einloggen, und zwar mit obigem DN sowie dem vorhin angegebenen Passwort. Übrigens kann man sich alle Angaben (bis auf das Passwort) auch abspeichern.
Durch Rechtsklick auf einen Eintrag kann man diesem Eintrag einen weiteren hinzufügen. Daher klicke ich auf "schirmacher", dann auf "Neu" und wähle die gewünschten Objektklassen. Der Eintrag soll Informationen über eine Person enthalten, wie Name, Login, Passwort, Telefonnummer usw. Die geeigneten Objektklassen sind "person" oder "inetOrgPerson" (enthält mehr Attribute). Nach Klick auf den "OK"-Button zeigt der JXplorer einen neuen Eintrag vom gewünschten Typ an.
Hinweis: Dieser Eintrag ist noch nicht im LDAP-Server gespeichert! Falls man auf einen anderen Eintrag in der Baumansicht klickt, geht der neue Eintrag verloren.
Nun kann man alle gewünschten Felder ausfüllen und die Daten zum LDAP Server senden. Alle fett dargestellte Attribute sind Pflichtfelder und müssen in jedem Fall ausgefüllt werden. Durch Klick auf den "Abschicken"-Button werden die Daten zum LDAP-Server gesendet und sind dauerhaft gespeichert.
ldapsearch -x -D 'cn=admin,dc=schirmacher,dc=de' -w geheim -H ldap://ldap.schirmacher.de -b 'dc=schirmacher,dc=de' cn |
Der Debian Installer gibt als Base DN des Directories den Domain Namen vor. Man kann natürlich auch beliebige andere wählen, für eine kleine Firma könnte man z.B. die Objektklasse "organization" wählen: "o=Meine GmbH".
Für die Mitarbeiter sollte man eine eigene Hierarchie aufbauen, z.B. die Objektklasse "organizationalUnit": "ou=people", in der dann die Einträge abgelegt sind.
Es hat sich bewährt, für Funktionsuser (z.B. den Administrator, einen Read-Only-User) ebenfalls eine separate Hierarchie anzulegen. In diesem Beispiel heißt sie "specialaccounts".
Mit LDAP kann man Zugriffsrechte sehr fein einstellen. In diesem Beispiel eines Firmen-LDAP-Servers gibt es folgende Policy: