OpenLDAP vor Precise
Hinweis:
Ab Ubuntu 12.04 bitte den Artikel Archiv/OpenLDAP ab Precise nutzen.
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
OpenLDAP 🇬🇧 stellt das Anwendungsprotokoll LDAP als freie Software für Linux zur Verfügung. Mit diesem Dienst ist es beispielsweise möglich, eine zentrale Benutzerverwaltung aufzubauen. Zudem kann OpenLDAP als Adressbuch eingesetzt werden. Der LDAP-Verzeichnisdienst ist eine hierarchische Datenbank, in der strukturierte Objekte abgelegt werden. Jedes Objekt wird mit einer Menge von Attributen ausgestattet, die in einer Objektklasse festgelegt sind. Ein Objekt kann dazu mehreren Objektklassen angehören, um unterschiedliche Eigenschaften auszudrücken.
Hinweis:
LDAP ist ein recht komplexes Thema. Es ist empfehlenswert vor der Nutzung weitere Literatur zu gebrauchen, um ein besseres Verständnis für die Funktionsweise und die Möglichkeiten zu bekommen.
Installation¶
Die Installation von OpenLDAP ist leider etwas kompliziert geworden. So wird nicht mehr nach einem Admin-Passwort gefragt und man muss die Datenbank selbst aufsetzen. Das geht übrigens nur mehr mit dem Root-Benutzerrechten des Rechners, auf dem OpenLDAP später seine Arbeit verrichten soll. Hier 🇬🇧 gibt es ein offizielles Statement dazu (in Kurzform: das ist Teil einer zukünftigen Strategie, um LDAP breitgefächerter - vor allem in Unternehmen - einzusetzen, Stichwort: z.B. Archiv/Kerberos).
Hinweis:
Die folgenden Befehle müssen immer als root ausgeführt werden:
Ubuntu-Pakete installieren¶
Am Anfang steht natürlich die Installation [1] von OpenLDAP:
slapd
ldap-utils
Befehl zum Installieren der Pakete:
sudo apt-get install slapd ldap-utils
Oder mit apturl installieren, Link: apt://slapd,ldap-utils
Weitere Pakete sind optional und für die Funktionalität von OpenLDAP nicht zwingend erforderlich.
Achtung!
slapd kann nicht mehr mittels Dialog über dpkg-reconfigure slapd konfiguriert werden. Die Eingabe von dpkg-reconfigure slapd setzt das cn=config-Backend in den Ausgangszustand zurück. Alle nachfolgend beschriebenen Konfigurationsschritte an dem Backend müssen dann neu ausgeführt werden. Es ist deswegen ratsam, die für die Konfiguration verwendeten .ldif-Dateien im Verzeichnis /etc/ldap abzulegen, damit die Informationen nicht verloren gehen. dpkg-reconfigure slapd sollte nur noch zum gezielten Zurücksetzen des Backends verwendet werden. Das eigentliche LDAP-Verzeichnis bleibt dabei erhalten.
LDAP-Schemata einfügen¶
Anschließend fügt man einige von Ubuntu im LDIF-Format schon mitgelieferte Schemata hinzu. Bis Ubuntu 10.10 ist core.schema ist das einzige Schema, bei der Installation von slapd automatisch in das cn=config-Backend aufgenommen wird):
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
Ab Ubuntu 11.04 kann man auch noch folgende weitere Schemata hinzufügen:
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
Weitere Schemata (wie z. B. samba.schema), die nicht im LDIF-Format vorliegen, müssen zunächst konvertiert werden. Das folgende Beispiel fügt die gängigsten Schemata hinzu:
Erstellen einer Datei schema_convert.conf im Verzeichnis /etc/ldap/schema mit folgendem Inhalt:
include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/amavis.schema include /etc/ldap/schema/ldapns.schema # PMI schema makes problems when checking # database with slapcat for correctness # in Ubuntu 9.10; see bug report # include /etc/ldap/schema/pmi.schema include /etc/ldap/schema/samba.schema
Auch die schon in die cn=config-Datenbank eingefügten Schemata müssen in schema_convert.conf aufgeführt werden, da die anderen Schemata teilweise. auf sie aufbauen.
Hinweis:
Man beachte, dass Canonical darauf hinarbeitet, die OpenLDAP-Pakete von allen LDAP-anwendungsspezifischen Konfigurationen zu befreien und diese stattdessen in die Installationsskripts der Anwendungen zu verlagern. So könnte z.B. in zukünftigen Ubuntu-Releases ein Installationsskript des Samba-Pakets das samba.schema automatisch zum cn=config-Verzeichnis hinzufügen. Bis Ubuntu 11.04 läuft das leider noch nicht so komfortabel. Canonical legt stattdessen die Schemata 'samba.schema' und 'ldapns.schema' im doc-Verzeichnis der Anwendungen ab.
Das Schema samba.schema bekommt man über das Paket:
samba-doc
Befehl zum Installieren der Pakete:
sudo apt-get install samba-doc
Oder mit apturl installieren, Link: apt://samba-doc
gunzip /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz cp -v /usr/share/doc/samba-doc/examples/LDAP/samba.schema /etc/ldap/schema
Das Schema amavis.schema ist über das gleichnamige Paket zu beziehen:
amavis
Befehl zum Installieren der Pakete:
sudo apt-get install amavis
Oder mit apturl installieren, Link: apt://amavis
Bis Ubuntu 10.10 bekommt man das Schema ldapns.schema über das Paket:
libpam-ldap
Befehl zum Installieren der Pakete:
sudo apt-get install libpam-ldap
Oder mit apturl installieren, Link: apt://libpam-ldap
Bei der Installation des Pakets öffnet sich ein Konfigurationsdialog, der im Kapitel LDAP Authentication beschrieben wird. Spätere Änderungen an der LDAP-Authentication-Konfiguration sind durch Aufruf von dpkg-reconfigure ldap-auth-config jederzeit möglich.
cp -v /usr/share/doc/libpam-ldap/ldapns.schema /etc/ldap/schema
Ab Ubuntu 11.04 muss man auch das Schema amavis.schema nachinstallieren. Man bekommt es über das Paket:
amavisd-new
Befehl zum Installieren der Pakete:
sudo apt-get install amavisd-new
Oder mit apturl installieren, Link: apt://amavisd-new
direkt in das Verzeichnis /etc/ldap/schema installiert.
2. Erstellen eines temporären Verzeichnisses für die LDIF-Dateien
mkdir /tmp/ldif_output
3. Konvertieren der Schemata ins LDIF-Format mit Hilfe von slapcat und Kopieren ins Verzeichnis /etc/ldap/schema:
cd /etc/ldap/schema
slapcat -f schema_convert.conf -F /tmp/ldif_output -n0
cd /tmp/ldif_output/cn\=config/cn\=schema/
cp cn={11}ppolicy.ldif cn={12}amavis.ldif cn={13}ldapns.ldif cn={14}samba.ldif cn={2}corba.ldif cn={4}duaconf.ldif cn={5}dyngroup.ldif cn={7}java.ldif /etc/ldap/schema 4. Öffnen der neuen LDIF-Dateien in einem Editor und Anpassen der Attribute dn (in der 1. Zeile) und cn (in der 3. Zeile), nachfolgend gezeigt am Beispiel des samba-Schemas:
dn: cn=samba,cn=schema,cn=config ... cn: samba
Löschen der letzten sieben Zeilen in der LDIF-Datei:
structuralObjectClass: olcSchemaConfig entryUUID: bc124984-712d-102e-9274-5bec14760b98 creatorsName: cn=config createTimestamp: 20091129122324Z entryCSN: 20091129122324.626040Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20091129122324Z
Das Ganze hier dann automatisiert in einem bash script:
#!/bin/sh
WORKINGDIR=/tmp/ldapconfig
LDAPCONFIGDIR=/etc/ldap
SCHEMADIR=$LDAPCONFIGDIR/schema
SAMBAINSTALLED=''
if [ ! $UID -eq 0 ]; then
echo Thsi script must be run as superuser 'root'!
exit 0
fi
if [ -d $WORKINGDIR ]; then
echo -n It seems that a prevoius config is present. Titiying up.
rm -rf $WORKINGDIR/*
echo done!
fi
if [ -f /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz ]; then
echo Samba documentaion seems to be installed, copying schema file to working directory
zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > $WORKINGDIR/samba.schema
SAMBAINSTALLED=='n'
else
echo "Samba seems not to be installed. Shall I do that for you temporary? [Y|n]"
read SAMBAINSTALLED
if [ $SAMBAINSTALLED=='Y' ]; then
apt-get --yes install samba-doc
fi
cat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > $WORKINGDIR/samba.schema
fi
cat << EOF > $WORKINGDIR/slapd_temporary.conf
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/ldapns.schema
include /etc/ldap/schema/pmi.schema
include /etc/ldap/schema/samba.schema
EOF
slapcat -f $WORKINGDIR/slapd_temporary.conf -F $WORKINGDIR -n0 2>&1 > /dev/null
for FILE in $WORKINGDIR/cn\=config/cn\=schema/*.ldif; do
echo Generate ldif schema file for \'${FILE#*\}}\'
# remove file vefore filling it with contents
rm -f $SCHEMADIR/${FILE#*\}}
while read LINE; do
case ${LINE%%:*} in
"dn")
LINE="dn: "${LINE#*\}}",cn=schema,cn=config"
;;
"cn")
LINE="cn: "${LINE#*\}}
;;
"structuralObjectClass")
unset LINE
;;
"entryUUID")
unset LINE
;;
"creatorsName")
unset LINE
;;
"createTimestamp")
unset LINE
;;
"entryCSN")
unset LINE
;;
"modifiersName")
unset LINE
;;
"modifyTimestamp")
unset LINE
;;
esac
echo ${LINE#:*} >> $SCHEMADIR/${FILE#*\}}
done < $FILE
done
echo Setting password for the config database ...
slappasswd > /tmp/secret.txt
PASSWORD=`cat /tmp/secret.txt`
cat << EOF > $WORKINGDIR/config_modify.ldif
# Modify directory database
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcSuffix
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcSuffix
olcSuffix: dc=meinedomain,dc=local
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcRootDN
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcRootDN
olcRootDN: cn=admin,dc=meinedomain,dc=local
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcRootPW
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcRootPW
olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcDbIndex
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: uid pres,eq
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: cn,sn,mail pres,eq,approx,sub
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: objectClass eq
###########################################################
# REMOTE CONFIGURATION DEFAULTS
###########################################################
# Some defaults need to be added in order to allow remote
# access by DN cn=admin,cn=config to the LDAP config
# database. Otherwise only local root will
# administrative access.
\#dn: olcDatabase={0}config,cn=config
\#changetype: modify
\#add: olcRootDN
\#olcRootDN: cn=admin,cn=config
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
EOF
echo "olcRootPW: "$PASSWORD >> $WORKINGDIR/config_modify.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f $WORKINGDIR/config_modify.ldif
exit 1 5. Abschließend werden die Schemata dem config-Backend hinzugefügt:
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ppolicy.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/amavis.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/samba.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/corba.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/duaconf.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/dyngroup.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/java.ldif
Konfiguration über cn=config-Datenbank (/etc/ldap/slapd.d/)¶
Nachdem nun alle Schemata ins Backend eingefügt worden sind, setzt man die initiale cn=config-Datenbank auf. Diese Datenbank hält die gesamte Konfiguration von OpenLDAP, welche bis Ubuntu 8.04 in /etc/ldap/slapd.conf geschrieben stand. Zunächst muss man dazu ein Passwort für die LDAP-Superuser festlegen. Für diesen Wiki-Artikel werden beispielhaft zwei Superuser im LDAP-Backend angelegt:
cn=admin,cn=config (Root für die cn=config-Datenbank, d. h. das Konfigurationsverzeichnis des LDAP-Servers)
cn=admin,dc=meinedomain,dc=local (Root für das eigentliche LDAP-Verzeichnis der Domäne meinedomain.local).
Beiden LDAP-Root-Benutzern wird beispielhaft das Passwort '1234' vergeben. Das Passwort sollte natürlich angepasst und nur verschlüsselt in cn=config abgelegt werden. Deshalb wird zunächst ein Hash des Passwortes erzeugt:
slappasswd
New password:
Re-enter new password:
{SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1Den Hash sollte man sich notieren, da er nachfolgend immer wieder benötigt wird.
Ab Ubuntu 11.04 wird die cn=config-Datenbank weitgehend schon bei der Installation aufgesetzt. Es sind dennoch einige Anpassungen ratsam. Dafür erstellt man eine Datei db.ldif. Dort fügt man folgendes ein:
###########################################################
# DEFAULT DATABASE MODIFICATION
###########################################################
# Modify directory database
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcSuffix
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcSuffix
olcSuffix: dc=meinedomain,dc=local
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcRootDN
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcRootDN
olcRootDN: cn=admin,dc=meinedomain,dc=local
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcRootPW
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcRootPW
olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcDbIndex
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: uid pres,eq
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: cn,sn,mail pres,eq,approx,sub
dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcDbIndex
olcDbIndex: objectClass eq
###########################################################
# REMOTE CONFIGURATION DEFAULTS
###########################################################
# Some defaults need to be added in order to allow remote
# access by DN cn=admin,cn=config to the LDAP config
# database. Otherwise only local root will
# administrative access.
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,cn=config
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1Bis Ubuntu 10.10 sieht die Datei db.ldif wie folgt aus:
###########################################################
# DATABASE SETUP
###########################################################
# Load modules for database type
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
# Create directory database
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=meinedomain,dc=local
olcRootDN: cn=admin,dc=meinedomain,dc=local
olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=meinedomain,dc=local" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=meinedomain,dc=local" write by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn,mail pres,eq,approx,sub
olcDbIndex: objectClass eq
###########################################################
# REMOTE CONFIGURATION DEFAULTS
###########################################################
# Some defaults need to be added in order to allow remote
# access by DN cn=admin,cn=config to the LDAP config
# database. Otherwise only local root will
# administrative access.
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,cn=config
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
Der Wert für das Attribut 'olcRootPW' sollte natürlich durch den weiter oben erzeugten eigenen Passwort-Hash ersetzt werden.
Diese Konfiguration wird mit folgendem Befehl in slapd eingelesen:
ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif
Dadurch wird ein Superuser cn=admin,dc=meinedomain,dc=local mit dem Passwort 1234 erstellt, der von nun an alle Rechte am LDAP-Verzeichnis für meinedomain.local hat und über dessen Account nachfolgend das eigentliche LDAP-Verzeichnis initialisiert wird.
Das Passwort sollte natürlich angepasst werden.
Bis Ubuntu 10.10 muss man jetzt noch die minimalen Einträge für den LDAP DIT (= "Directory Information Tree", also das eigentliche Verzeichnis des LDAP-Servers) anlegen. Dazu erstellt man eine weitere Datei namens base.ldif und fügt dort folgendes ein:
# Tree root
dn: dc=meinedomain,dc=local
objectClass: dcObject
objectClass: organization
o: meinedomain.local
dc: meinedomain
description: Tree root
# LDAP admin
dn: cn=admin,dc=meinedomain,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
userPassword: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1
description: LDAP administratorHier wird nun der eigentliche LDAP-Administrator für das meinedomain.local-Verzeichnis definiert. Über diesen Account wird nachfolgend dann das Verzeichnis Schritt für Schritt mit Daten (wie z. B. Benutzeraccounts und deren Passwörter) gefüllt. Bitte auch hier den Passwort-Hash entsprechend anpassen.
Die Datei base.ldif wird über den Superuser-Account "cn=admin,dc=meinedomain,dc=local" eingelesen (wenn nach dem Passwort gefragt wird, das weiter oben definierte Passwort eingeben):
ldapadd -x -D cn=admin,dc=meinedomain,dc=local -W -f base.ldif
Ab jetzt sollte man auf dem Stand einer frischen Installation von OpenLDAP wie unter Ubuntu 9.04 sein und kann das LDAP-Verzeichnis ganz normal weiter aufsetzen.
Testen¶
Mit den folgenden Befehlen, die direkt auf dem Rechner mit dem OpenLDAP-Server ausgeführt werden müssen, kann die LDAP-Konfiguration testweise ausgelesen werden:
ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb
ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W Um die Konfiguration etwas komfortabler darzustellen, kann ein beliebiger LDAP-Browser verwendet werden, indem als Basis-DN 'cn=config' (nicht: dc=meinedomain,dc=local) angegeben wird.
Zum Auslesen der eigentlichen Verzeichnisdaten dient folgender Befehl (diesmal als anonymer Benutzer ohne Passworteingabe - daher wird beim Eintrag unter cn=admin,dc=meinedomain,dc=local das Passwort-Attribut nicht angezeigt):
ldapsearch -xLLL -b dc=meinedomain,dc=local
Weitere Konfiguration¶
Im nachfolgenden Kapitel wird nun zunächst die Installation des LDAP-Servers bis Ubuntu 9.04 beschrieben. Anschließend folgen weitere Kapitel, in denen z. B. die Migration existierender Benutzer-Accounts nach LDAP und die LDAP-Authentication vorgestellt werden. Mit nachfolgendem Link gelangen Nutzer von Ubuntu 9.10 und später direkt dorthin: {Weitere Konfiguration}
Installation bis Ubuntu 9.04¶
Ubuntu-Pakete installieren¶
Hinweis:
Die folgenden Befehle müssen immer als root ausgeführt werden:
Als erstes müssen die entsprechenden Pakete heruntergeladen und installiert werden:
slapd
ldap-utils
php5-ldap
db4.2-util
Befehl zum Installieren der Pakete:
sudo apt-get install slapd ldap-utils php5-ldap db4.2-util
Oder mit apturl installieren, Link: apt://slapd,ldap-utils,php5-ldap,db4.2-util
Zum Testen wird außerdem - optional - das Paket
nmap
Befehl zum Installieren der Pakete:
sudo apt-get install nmap
Oder mit apturl installieren, Link: apt://nmap
benötigt.
Unter Ubuntu 8.10 und 9.04 wurde das Verfahren zum Einrichten des LDAP-Servers sehr vereinfacht. Nach der Installation gibt man am Terminal
sudo dpkg-reconfigure slapd
ein und wird dann mit ein paar Fragen durch die Grundkonfiguration geführt. Danach kann man die weitere Konfiguration bequem mit phpldapadmin durchführen. Dieses Verfahren funktioniert allerdings ab Ubuntu 9.10 nicht mehr.
Damit ist die Grundinstallation abgeschlossen. Während der Installation von slapd wird man übrigens nach einem Passwort gefragt. Dort gibt man ein neues Passwort ein.
Vorbereitung und Allgemeines¶
Test mittels lsof¶
Wenn man nmap noch nicht installiert hat bzw. nicht installieren möchte, kann man aber auch lsof zum Überprüfen des LDAP-Servers verwenden [3]. Dieses ist meistens schon in der Grundinstallation von Ubuntu enthalten.
lsof -a -i TCP:389 -c slapd
Die Ausgabe sollte etwa so aussehen:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 9395 openldap 8u IPv6 1616216 TCP *:ldap (LISTEN) slapd 9395 openldap 9u IPv4 1616217 TCP *:ldap (LISTEN)
Hier ist zu erkennen, dass slapd auf Port 389 lauscht. Der Server läuft also ordnungsgemäß.
Test mittels nmap¶
Jetzt kann man überprüfen, ob der neue LDAP-Server auch läuft. Dazu kann man z.B. nmap nutzen [3].
nmap localhost | grep ldap
Nun sollte Folgendes erscheinen:
389/tcp open ldap
SSHA-Schlüssel¶
Bis einschließlich Ubuntu Hard Heron 8.04 benötigt man einen SSHA-Schlüssel als Passwort, der durch folgenden Befehl vom System generiert wird:
slappasswd
New password: PASSWORT
Re-enter new password: PASSWORT
{SSHA}...Den so generierten Schlüssel muss man sich nun merken, er wird später für die Konfiguration benötigt.
Konfiguration mittels slapd.conf¶
Hinweis:
Seit Ubuntu 8.10 wird nicht mehr die slapd.conf-Konfigurationsdatei verwendet, sondern die Konfiguration ins LDAP-Verzeichnis (cn=config) selbst geschrieben. Das hat einige Vorteile, u.a. dass der OpenLDAP-Server bei Konfigurationsänderungen nicht mehr neu gestartet werden muss. Die Vorteile werden allerdings mit einer etwas umständlicheren Konfiguration erkauft.
Wer also statt der cn=config lieber die alte Konfigurationsmethode über die Datei slapd.conf verwenden will, erstellt die Datei slapd.conf im Verzeichnis /etc/ldap und kopiert nachfolgende Konfiguration in die Datei.
# This is the main slapd configuration file. See slapd.conf 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
# 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/slapd.args
# Read slapd.conf(5) for possible values
loglevel none
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend hdb
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
database config
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database hdb
# The base of your directory in database #1
suffix "dc=yourdomain,dc=tld"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=admin,cn=config"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts. They do NOT override existing an existing DB_CONFIG
# file. You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Indexing options for database #1
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# 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
# acl specific for phamm
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=webhabitat,dc=be" write
by anonymous auth
by self write
by * none
access to *
by dn="cn=admin,dc=yourdomain,dc=tld" write
by * read
access to dn.base="" 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=yourdomain,dc=tld" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be hdb 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"Nun sucht man folgende Zeile und ändert diese nach seinen Bedürfnissen ab:
suffix "dc=meinedomain,dc=local"
Und am Ende der Datei fügt man Folgendes ein:
rootdn "cn=admin,dc=meinedomain,dc=local"
rootpw {SSHA}...Dort fügt man den SSHA-Schlüssel ein, den man vorhin generiert habt.
slapd.conf "aktivieren"¶
Jetzt muss die neue slapd.conf erst „aktiviert“ werden.
Zunächst stoppt man den LDAP-Server:
/etc/init.d/slapd stop
Danach geht man in den entsprechenden Ordner /etc/ldap
Die alte Konfiguration slapd.d wird zunächst gesichert, z.B. im Terminal [2] mit
mv slapd.d slapd.d.bck
Danach erstellt man ein neues slapd.d-Verzeichnis und lädt die slapd.conf
mkdir slapd.d slaptest -f slapd.conf -F slapd.d
Nun sollte Folgendes erscheinen:
config file testing succeeded
Jetzt werden nur noch die Benutzerrechte der neuen Konfigurationsdatei geändert [4]:
chown -R openldap:openldap slapd.d
Nun kann der LDAP-Server wieder gestartet werden:
/etc/init.d/slapd start
Jetzt könnte man die slapd.conf wieder löschen, es empfiehlt sich allerdings, diese für eine spätere Änderung beizubehalten. Dazu muss man diese allerdings wieder wie oben beschrieben Schritt für Schritt „aktivieren“.
Dies ist aber erst ab Ubuntu 8.10 nötig. Bei älteren Versionen reicht das Bearbeiten der slapd.conf und anschließende Neustarten des LDAP-Servers aus.
LDAP-Admin-Benutzer hinzufügen¶
Im nächsten Schritt muss man dem LDAP-Server einen Verzeichnisadministrator mitteilen. Dazu erstellt man eine Datei base.ldif. Dort fügt man Folgendes ein:
dn:dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain dc: meinedomain dn:cn=admin,dc=meinedomain,dc=local objectClass: organizationalRole cn: admin
Dieses muss jetzt nur noch in die LDAP-Datenbank eingefügt werden.
ldapadd -x -h <hostname> (-p <port>) -W -D cn=admin,dc=meinedomain,dc=local -f base.ldif
Enter LDAP Password: PASSWORT adding new entry "dc=meinedomain,dc=local" adding new entry "cn=admin,dc=meinedomain,dc=local"
Jetzt überprüft man nur noch, ob der neue Benutzer auch eingetragen wurde:
ldapsearch -x
# extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL # # meinedomain.local dn: dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain dc: meinedomain # admin, meinedomain.local dn: cn=admin,dc=meinedomain,dc=local objectClass: organizationalRole cn: admin # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
Damit ist die Konfiguration abgeschlossen und der LDAP-Server läuft.
LDAP Client konfigurieren¶
Damit die Clients wissen, wo sie den LDAP-Server finden, müssen ihnen ein paar grundlegende Informationen bekannt gemacht werden. Dazu öffnet man die Datei [3] /etc/ldap/ldap.conf und ändert den Inhalt:
ldap_version 3 URI ldap://meinedomain.local SIZELIMIT 0 TIMELIMIT 0 DEREF never BASE dc=meinedomain,dc=local
Danach wird die Datei gespeichert und geschlossen.
Linux-Benutzeraccounts nach LDAP migrieren¶
Für die Migration der in den Dateien /etc/passwd und /etc/group abgelegten Linux-Benutzer- und Gruppen-Accounts stellt Ubuntu ein Skript zur Verfügung. Dieses Skript ist Teil des Pakets smbldap-tools, das eigentlich Werkzeuge für die vereinfachte Konfiguration eines Samba-Servers zur Verfügung stellt. Es kann aber auch, ohne dass ein Samba-Server verwendet wird, benutzt werden. Nachfolgend die für die Migration erforderlichen Schritte:
Anlegen der für die Migration benötigten LDAP-OUs
Erstellen der Datei init.ldif im Verzeichnis /etc/ldap. Ersetze 'dc=meinedomain,dc=local' durch den eigenen Domänenname:
dn: ou=Users,dc=meinedomain,dc=local objectClass: organizationalUnit ou: Users dn: ou=Groups,dc=meinedomain,dc=local objectClass: organizationalUnit ou: Groups dn: ou=Computers,dc=meinedomain,dc=local objectClass: organizationalUnit ou: Computers dn: ou=Idmap,dc=meinedomain,dc=local objectClass: organizationalUnit ou: Idmap
Diese müssen jetzt nur noch in die LDAP-Datenbank eingefügt werden:
sudo ldapadd -x -h <hostname> (-p <port>) -W -D cn=admin,dc=meinedomain,dc=local -f init.ldif
2. Installation und Konfiguration des Pakets
smbldap-tools
Befehl zum Installieren der Pakete:
sudo apt-get install smbldap-tools
Oder mit apturl installieren, Link: apt://smbldap-tools
Die Skripte aus dem smbldap-tools-Paket werden über die Dateien smbldap.conf und smbldap_bind.conf im Verzeichnis /etc/smbldap-tools konfiguriert. Das Verzeichnis ist nach der Installation des Paketes zwar vorhanden, es fehlen aber die Konfigurationsdateien. Die Vorlagen hierfür liegen unter /usr/share/doc/smbldap-tools/examples. Die nachfolgenden Befehle müssen immer als root ausgeführt werden:
cd /etc/smbldap-tools zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > smbldap.conf cat /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf > smbldap_bind.conf chmod 0644 smbldap.conf chmod 0600 smbldap_bind.conf
Anschließend die Datei smbldap.conf editieren und das LDAP-Suffix korrekt einstellen, d.h. auf das bei der Konfiguration von OpenLDAP (siehe oben) verwendete Suffix dc=meinedomain,dc=local. Wenn kein Samba-Server installiert ist, sollten die Einträge für SID und sambaDomain auskommentiert werden. Wenn kein TLS für den LDAP-Server verwendet wird, sollten auch die Werte für verify, cafile, clientcert und clientkey entfernt werden. Andernfalls entsprechend der slapd.conf bzw. des cn=config-Backends einstellen. Die abgeänderte Datei sollte dann in etwa so aussehen:
...
##############################################################################
#
# General Configuration
#
##############################################################################
# Put your own SID. To obtain this number do: "net getlocalsid".
# If not defined, parameter is taking from "net getlocalsid" return
# SID="S-1-5-21-2252255531-4061614174-2474224977"
# Domain name the Samba server is in charged.
# If not defined, parameter is taking from smb.conf configuration file
# Ex: sambaDomain="IDEALX-NT"
# sambaDomain="DOMSMB"
##############################################################################
#
# LDAP Configuration
#
##############################################################################
# Notes: to use to dual ldap servers backend for Samba, you must patch
# Samba with the dual-head patch from IDEALX. If not using this patch
# just use the same server for slaveLDAP and masterLDAP.
# Those two servers declarations can also be used when you have
# . one master LDAP server where all writing operations must be done
# . one slave LDAP server where all reading operations must be done
# (typically a replication directory)
# Slave LDAP server
# Ex: slaveLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
slaveLDAP="127.0.0.1"
# Slave LDAP port
# If not defined, parameter is set to "389"
slavePort="389"
# Master LDAP server: needed for write operations
# Ex: masterLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
masterLDAP="127.0.0.1"
# Master LDAP port
# If not defined, parameter is set to "389"
masterPort="389"
# Use TLS for LDAP
# If set to 1, this option will use start_tls for connection
# (you should also used the port 389)
# If not defined, parameter is set to "1"
ldapTLS="0"
# How to verify the server's certificate (none, optional or require)
# see "man Net::LDAP" in start_tls section for more details
verify=""
# CA certificate
# see "man Net::LDAP" in start_tls section for more details
cafile=""
# certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientcert=""
# key certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientkey=""
# LDAP Suffix
# Ex: suffix=dc=IDEALX,dc=ORG
suffix="dc=meinedomain,dc=local"
# Where are stored Users
# Ex: usersdn="ou=Users,dc=IDEALX,dc=ORG"
# Warning: if 'suffix' is not set here, you must set the full dn for usersdn
usersdn="ou=Users,${suffix}"
# Where are stored Computers
# Ex: computersdn="ou=Computers,dc=IDEALX,dc=ORG"
# Warning: if 'suffix' is not set here, you must set the full dn for computersdn
computersdn="ou=Computers,${suffix}"
# Where are stored Groups
# Ex: groupsdn="ou=Groups,dc=IDEALX,dc=ORG"
# Warning: if 'suffix' is not set here, you must set the full dn for groupsdn
groupsdn="ou=Groups,${suffix}"
# Where are stored Idmap entries (used if samba is a domain member server)
# Ex: groupsdn="ou=Idmap,dc=IDEALX,dc=ORG"
# Warning: if 'suffix' is not set here, you must set the full dn for idmapdn
idmapdn="ou=Idmap,${suffix}"
# Where to store next uidNumber and gidNumber available for new users and groups
# If not defined, entries are stored in sambaDomainName object.
# Ex: sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
# Ex: sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
# Default scope Used
scope="sub"
# Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT)
hash_encrypt="SSHA"
# if hash_encrypt is set to CRYPT, you may set a salt format.
# default is "%s", but many systems will generate MD5 hashed
# passwords if you use "$1$%.8s". This parameter is optional!
crypt_salt_format=""
##############################################################################
#
# Unix Accounts Configuration
#
##############################################################################
# Login defs
# Default Login Shell
# Ex: userLoginShell="/bin/bash"
userLoginShell="/bin/bash"
# Home directory
# Ex: userHome="/home/%U"
userHome="/home/%U"
# Default mode used for user homeDirectory
userHomeDirectoryMode="700"
# Gecos
userGecos="System User"
# Default User (POSIX and Samba) GID
defaultUserGid="513"
# Default Computer (Samba) GID
defaultComputerGid="515"
# Skel dir
skeletonDir="/etc/skel"
# Default password validation time (time in days) Comment the next line if
# you don't want password to be enable for defaultMaxPasswordAge days (be
# careful to the sambaPwdMustChange attribute's value)
defaultMaxPasswordAge="45"
##############################################################################
#
# SAMBA Configuration
#
##############################################################################
# The UNC path to home drives location (%U username substitution)
# Just set it to a null string if you want to use the smb.conf 'logon home'
# directive and/or disable roaming profiles
# Ex: userSmbHome="\\PDC-SMB3\%U"
userSmbHome="\\PDC-SRV\%U"
# The UNC path to profiles locations (%U username substitution)
# Just set it to a null string if you want to use the smb.conf 'logon path'
# directive and/or disable roaming profiles
# Ex: userProfile="\\PDC-SMB3\profiles\%U"
userProfile="\\PDC-SRV\profiles\%U"
# The default Home Drive Letter mapping
# (will be automatically mapped at logon time if home directory exist)
# Ex: userHomeDrive="H:"
userHomeDrive="H:"
# The default user netlogon script name (%U username substitution)
# if not used, will be automatically username.cmd
# make sure script file is edited under dos
# Ex: userScript="startup.cmd" # make sure script file is edited under dos
userScript="logon.bat"
# Domain appended to the users "mail"-attribute
# when smbldap-useradd -M is used
# Ex: mailDomain="idealx.com"
mailDomain="idealx.com"
##############################################################################
#
# SMBLDAP-TOOLS Configuration (default are ok for a RedHat)
#
##############################################################################
# Allows not to use smbpasswd (if with_smbpasswd == 0 in smbldap_conf.pm) but
# prefer Crypt::SmbHash library
with_smbpasswd="0"
smbpasswd="/usr/bin/smbpasswd"
# Allows not to use slappasswd (if with_slappasswd == 0 in smbldap_conf.pm)
# but prefer Crypt:: libraries
with_slappasswd="0"
slappasswd="/usr/sbin/slappasswd"
# comment out the following line to get rid of the default banner
# no_banner="1"Zum Schluss werden noch in der Datei smbldap_bind.conf die Einträge für den LDAP-Administrator und dessen Passwort angepasst. Dass Passwort muss als Klartext hinterlegt werden, weswegen die Zugriffsrechte weiter oben auf root beschränkt worden sind:
############################ # Credential Configuration # ############################ # Notes: you can specify two differents configuration if you use a # master ldap for writing access and a slave ldap server for reading access # By default, we will use the same DN (so it will work for standard Samba # release) slaveDN="cn=admin,dc=meinedomain,dc=local" slavePw="1234" masterDN="cn=admin,dc=meinedomain,dc=local" masterPw="1234"
3. Linux-Benutzeraccounts nach LDAP migrieren
Mit Hilfe des Skripts smbldap-migrate-unix-accounts werden alle Linux-Benutzer und Passwörter nach LDAP migriert. Das Skript verwendet dabei die Konfigurationsdatei von smbldap-tools (/etc/smbldap-tools/smbldap.conf).
Normalerweise sollten nicht alle Benutzer aus der /etc/passwd nach LDAP übernommen werden. Insbesondere die Systembenutzer (root, sys, daemon, ...) belässt man besser lokal in der /etc/passwd, da diese Accounts nicht über LDAP an die anderen PCs im Netz exportiert werden sollten. Deshalb erstellt man zuerst eine Kopie der /etc/passwd und entfernt dort alle System- und Computeraccounts.
cd /root zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-accounts.gz > smbldap-migrate-unix-accounts chmod u+x smbldap-migrate-unix-accounts cp /etc/passwd passwd.users vi passwd.users ... (Benutzer entfernen, die nicht importiert werden sollen)
Jetzt können die zu migrierenden Accounts in die LDAP-Datenbank übernommen werden:
./smbldap-migrate-unix-accounts -P passwd.users -S /etc/shadow -v
Hinweis:
Die Datei /etc/shadow kann direkt verwendet werden, da hieraus nur die Zeilen mit entsprechendem Eintrag in der angegebenen passwd.users-Datei übernommen werden.
4. Linux-Gruppen nach LDAP migrieren
Die Migration der Linux-Gruppen funktioniert nach demselben Prinzip wie die Migration der Benutzer. Es werden nur die Gruppen in die Datenbank übertragen, die nicht Systemgruppen sind.
zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-groups.gz > smbldap-migrate-unix-groups chmod u+x smbldap-migrate-unix-groups cp /etc/group group.import vi group.import ... (Gruppen entfernen, die nicht importiert werden sollen) ./smbldap-migrate-unix-groups -G group.import -v
Hinweis:
Falls das Hinzufügen von Benutzern oder Gruppen fehlschlägt (bisher nur unter Ubuntu 11.10 aufgetreten) muss man die Dateien smbldap-migrate-unix-groups und smbldap-migrate-unix-accounts editieren: Man sucht die Zeile mit dem Eintrag my $ldap_master=connect_ldap_master(); und fügt darunter folgendes ein:
1 2 3 | $ldap_master->bind ( "cn=admin,dc=meinedomain,dc=local", password => "1234", version => 3 ); |
Man muss eventuell die Werte für das Passwort und den Adminuser anpassen.
5. Test, ob die Linux-Benutzer und -Gruppen im LDAP-Verzeichnis eingetragen sind
Nach Eingabe von
ldapsearch -x -D cn=admin,dc=meinedomain,dc=local -W -b dc=meinedomain,dc=local
sollten alle Benutzer und Gruppen mit den dazugehörigen Attributen angezeigt werden.
Achtung!
Ubuntu verwendet zumindest seit Release 9.10 standardmäßig Simple Authentication and Security Layer (SASL) als Authentifizierungs-Framework für OpenLDAP. Damit das korrekt funktioniert, müssen die Passwörter der LDAP-Benutzer im LDAP-Directory als Klartext im Attribut userPassword hinterlegt sein. Das Migrationsscript hinterlegt sie aber standardmäßig verschlüsselt. In diesem Fall funktioniert nur die einfache Authentifizierung am LDAP-Server, z. B. mittels ldapsearch -x -D cn=carmen,dc=meinedomain,dc=local -W -b dc=meinedomain,dc=local für die Benutzerin carmen. Die deutlich sichere Methode über SASL mittels: ldapsearch -b dc=meinedomain,dc=local scheitert nach der Passwortabfrage durch SASL mit Fehlermeldung Invalid credentials (49). Abhilfe schafft, die Passwörter nochmals neu zu setzen, wie im nachfolgenden Kapitel gezeigt.
Verwendung von SASL¶
Die von OpenLDAP bereitgestellten LDAP-Client-Tools wie ldapsearch und ldapmodify versuchen standardmäßig, die Benutzer am LDAP-Verzeichnis-Server über Simple Authentication and Security Layer (SASL) mit DIGEST-MD5-Mechanismus zu authentifizieren. Daneben gibt es noch eine einfache Authentifizierung (mittels Option -x), die in den vorangegangenen Installations- und Konfigurationskapiteln zur Anwendung kam. Mit ein paar zusätzlichen Schritten kann aber jedem Benutzer der Zugriff auf das LDAP-Verzeichnis mittels SASL-Authentifizierung ermöglicht werden. Dazu müssen die Linux-Benutzeraccounts wie vorangehend beschrieben in das LDAP-Verzeichnis migriert werden. Darüber hinaus müssen einige Attribute im cn=config-Backend bzw. der Konfigurationsdatei slapd.conf (im Verzeichnis /etc/ldap) korrekt gesetzt sein.
Für den Fall der Konfiguration mittels cn=config-Backend muss eine Datei sasl-digestmd5.ldif im Verzeichnis /etc/ldap mit nachfolgendem Inhalt erstellt werden.
###########################################################
# DEFAULTS MODIFICATION for SASL DIGEST-MD5
###########################################################
# Some of the defaults need to be modified in order to allow
# SASL supported access to the LDAP config.
# The LDAP administrator will need to tell the slapd server
# how to map an authentication request DN to a user's
# authentication DN. This is done by adding one or more
# olcAuthzRegexp attributes to the cn=config backend.
# This attribute takes two arguments:
#
# olcAuthzRegexp <search pattern> <replacement pattern>
#
# Please note, that more than one attribute can be specified.
# The LDAP server will serve them sequentially.
dn: cn=config
changetype: modify
add: olcAuthzRegexp
olcAuthzRegexp: uid=root,cn=[^,]*,cn=auth cn=admin,dc=meinedomain,dc=local
dn: cn=config
changetype: modify
add: olcAuthzRegexp
olcAuthzRegexp: uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=Users,dc=meinedomain,dc=local
# set the correct authentication policy
dn: cn=config
changetype: modify
add: olcAuthzPolicy
olcAuthzPolicy: to
# User passwords have to stored as cleartext within the
# LDAP directory
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcPasswordHash
olcPasswordHash: {CLEARTEXT}Diese muss dann anschließend in das LDAP-Backend eingefügt werden:
ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/sasl-digestmd5.ldif
Falls OpenLDAP noch über slapd.conf im Verzeichnis /etc/ldap konfiguriert wird, müssen folgende Einträge hinzugefügt bzw. angepasst werden.
# SASL DIGEST-MD5 authorisation replacement directive
# This parameter is in the format of:
# uid=<username>,cn=<realm>,cn=<mech>,cn=auth
# The username is taken from sasl and inserted into the ldap search
# string in the place of $1. Your realm is supposed to be your FQDN
# (fully qualified domain name)
authz-regexp uid=admin,cn=[^,]*,cn=auth cn=admin,dc=meinedomain,dc=local
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=Users,dc=meinedomain,dc=local
authz-policy to
# enable LDAP to help SASL to use passworts stored in LDAP database
password-hash {CLEARTEXT}Neustart von slapd mittels:
sudo /etc/init.d/slapd restart
Nun müssen noch die Passwörter in Klartext im LDAP-Verzeichnis hinterlegt werden. Dazu muss das Passwort neu gesetzt werden. Dies kann jeder Benutzer (z. B. carmen) selber durchführen:
ldappasswd -x -D uid=carmen,ou=Users,dc=meinedomain,dc=local -W -s MeinPasswort uid=carmen,ou=Users,dc=meinedomain,dc=local
oder der LDAP-Administrator (durch Neuvergabe)
sudo ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -s NeuesPasswort uid=carmen,ou=Users,dc=meinedomain,dc=local
Nach Eingabe von
carmen@MeinComputer:~$ ldapsearch -b dc=meinedomain,dc=local
und dem Passwort sollte jeder Benutzer die im LDAP-Verzeichnis hinterlegten Benutzer und Gruppen mit den dazugehörigen Attributen angezeigt bekommen.
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: carmen SASL SSF: 128 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=meinedomain,dc=local> with scope subtree # filter: (objectclass=*) # requesting: ALL # # meinedomain.local dn: dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain.local dc: meinedomain description: Tree root # admin, meinedomain.local dn: cn=admin,dc=meinedomain,dc=local objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator ...
Zum Abschluss muss auch noch dass Passwort des LDAP-Verzeichnis-Administrators (cn=admin,dc=meinedomain,dc=local) in Klartext in dem LDAP-Verzeichnis hinterlegt werden. Ganz zu Beginn der Installation des OpenLDAP-Servers wurde ja nur ein Passwort-Hash eingetragen. Der von den LDAP-Client-Tools standardmäßig für die Benutzerauthentifizierung verwendete SASL-DIGEST-MD5-Mechanismus erfordert aber zwingend die Ablage der Passwörter in Klartext im LDAP-Verzeichnis. LDAP-Abfragen durch den Ubuntu-Superuser root wie z. B.
sudo ldapsearch -b ou=Users,dc=meinedomain,dc=local -LLL uid=carmen SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: root SASL SSF: 128 SASL data security layer installed
werden aus Sicherheitsgründen mittels der oben definierten Authentication-Replace-Anweisung authz-regexp uid=admin,cn=[^,]*,cn=auth cn=admin,dc=meinedomain,dc=local über den LDAP-Admin authentifiziert. Unter Please enter your password: ist deshalb das Passwort des LDAP-Admin einzugeben (z. B. "1234"). So kann root, ohne selbst im LDAP-Verzeichnis abgelegt zu sein, auf dasselbe zugreifen. Die Hinterlegung des Passwortes in Klartext erfolgt über
ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -S cn=admin,dc=meinedomain,dc=local
Sichere Übertragung mit TLS/SSL¶
Nach der sicheren Authentifizierung geht es nun an den verschlüsselten Transport der Informationen zwischen LDAP-Server und Client. Dafür wird das Verschlüsselungsprotokoll Transport Layer Security (TLS), auch bekannt unter der früheren Bezeichnung Secure Sockets Layer (SSL), herangezogen. Der in Ubuntu zur Verfügung gestellte OpenLDAP-Server (slapd) und die OpenLDAP-Clients verwenden GnuTLS als TLS-Bibliothek. Das löst zwar Lizenzprobleme, bringt aber einige Komplikationen mit sich, die das Einrichten von Transport Layer Security in OpenLDAP schnell zu einem Alptraum werden lassen können. Es ist deshalb ratsam, durch striktes Befolgen der Anleitung zunächst einen funktionierenden TLS-Layer einzurichten. Anschließend kann man diesen dann den eigenen Bedürfnissen entsprechend weiter anpassen. Wie SASL ist auch die Verschlüsselung mittels TLS zwingend erforderlich, um einen LDAP v3 kompatiblen LDAP-Verzeichnisdienst zu betreiben.
Achtung!
slapd verzeiht Fehler bei der Konfiguration von TLS nicht. Gewöhnlich lässt sich der Dämon dann erst einmal nicht mehr starten und somit auch nicht mehr konfigurieren. Stattdessen beglückt der Dämon den frustrierten Nutzer auch bei höchster Debug-Stufe mit einer (!) einzigen nichtssagenden Fehlermeldung: TLS init def ctx failed: -1.
In diesem Fall bleibt nur noch der Ausweg, durch Eingabe von dpkg-reconfigure slapd das cn=config-Backend in den Ausgangszustand zurückzusetzen. Alle bis hier erfolgten Konfigurationsschritte an dem Backend müssen dann wieder neu ausgeführt werden. Es wird daher nochmals dringend empfohlen, die für die Konfiguration verwendeten .ldif-Dateien im Verzeichnis /etc/ldap/ abzulegen. Nur so lässt sich OpenLDAP zügig reparieren. Sollten zwischenzeitlich schon Daten in das eigentliche LDAP-Verzeichnis eingetragen worden sein, ist das kein Problem. Solange man nicht in Panik gerät und ruhig und gezielt die Konfiguration des Backends wiederherstellt, bleiben alle (!) Verzeichnisdaten erhalten!
Erstellung der benötigten Server-Zertifikate¶
OpenLDAP benötigt X.509-Zertifikate zur Verschlüsselung der Daten. Es wird zwischen Server- und Client-Zertifikaten unterschieden. LDAP v3-konforme Server müssen auf gültige Zertifikate zurückgreifen können. Für LDAP-Clients ist die Verwendung von eigenen Zertifikaten optional und wird deshalb hier nicht weiter beschrieben. Um das Server-Zertifikat zu generieren, gibt es drei Möglichkeiten:
Selbstsigniertes Zertifikat
Bezug von einer Zertifizierungsstelle (Certification Authority)
Einrichtung und Verwendung einer eigenen Zertifizierungsstelle
Selbstsigniertes Zertifikat¶
Hier macht es Sinn, die eher noch nicht so ausgereifte, dafür aber schnell und einfach zu verwendende GnuTLS-Bibliothek einzusetzen, gegen die ja auch OpenLDAP kompiliert wurde:
gnutls-bin
Befehl zum Installieren der Pakete:
sudo apt-get install gnutls-bin
Oder mit apturl installieren, Link: apt://gnutls-bin
Für TLS werden zwei Zertifikate und ein privater Schlüssel benötigt. Die Erstellung erfolgt am besten in einem eigenen Arbeitsverzeichnis, das hinterher ggf. auch wieder gelöscht werden kann:
sudo mkdir /var/ssl cd /var/ssl
CA-Zertifikat (cacert.pem)¶
Für die Erstellung des Zertifikats wird eine Konfigurationsdatei (/var/ssl/ca.cfg) benötigt:
cn = meinedomain ca cert_signing_key
Mit Hilfe der Konfigurationsdaten erstellt man das CA-Zertifikat wie folgt:
sudo sh -c "certtool --generate-privkey > cakey.pem"
sudo certtool --generate-self-signed --load-privkey cakey.pem --template ca.cfg --outfile cacert.pem
Privater Schlüssel für Server-Zertifikat (ldap_slapd_key.pem)¶
sudo sh -c "certtool --generate-privkey > ldap_slapd_key.pem
Server-Zertifikat (ldap_slapd_cert.pem)¶
Auch für das Server-Zertifikat wird eine Konfigurationsdatei (/var/ssl/slapd.cfg) benötigt:
organization = meinedomain cn = ldap.meinedomain.local tls_www_server encryption_key signing_key
Der common name im Zertifikat muss dabei auf den eindeutigen, vollständigen Namen (FQDN) des LDAP-Servers verweisen, da sonst LDAP-Clients ggf. das Zertifikat nur nach Rückfrage beim Benutzer akzeptieren. Der Befehl:
sudo certtool --generate-certificate --load-privkey ldap_slapd_key.pem --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem --template slapd.cfg --outfile ldap_slapd_cert.pem
erstellt das Server-Zertifikat.
Bereitstellung durch eine eigene Zertifizierungsstelle¶
Wer sich schon eine eigene CA aufgebaut hat, besitzt genügend Erfahrung, um sich das für den LDAP-Server benötigte Zertifikat selbst zu erstellen und zu beglaubigen. Für diese Experten geht es im Abschnitt Installation weiter. Für alle anderen wird nachfolgend exemplarisch das Vorgehen skizziert. Dreh- und Angelpunkt ist die Erstellung einer eigenen, dauerhaften Zertifizierungsstelle. Dafür empfiehlt sich die Verwendung der ausgereifteren OpenSSL-Bibliothek, die auf den meisten Ubuntu-Installationen ohnehin schon vorhanden ist.
openssl
Befehl zum Installieren der Pakete:
sudo apt-get install openssl
Oder mit apturl installieren, Link: apt://openssl
CA (cacert.pem)¶
Der Wiki-Artikel CA beschreibt den Aufbau der Zertifizierungsstelle und die Erstellung des zugehörigen Stammzertifikats cacert.pem. Ein steinaltes, aber sehr empfehlenswertes HowTo mit vielen weiteren Informationen dazu gibt es hier 🇬🇧.
Die Erstellung und Verwaltung der eigenen Certification Authority erfolgt am besten in einem eigenen Arbeitsverzeichnis. In dem vorliegenden Artikel wird vom Verzeichnis /var/ssl ausgegangen:
sudo mkdir /var/ssl cd /var/ssl
Will man die Zertifizierungsstelle wie in CA beschrieben mit Hilfe des Skripts CA.pl erstellen, muss man im Skript noch folgende Variable anpassen:
$CATOP="/var/ssl";
damit Zertifikate und weitere Daten nicht in einem demoCA-Unterverzeichnis abgelegt werden.
Aufgrund der Sensivität der Daten sollten alle Aktivitäten als Benutzer root (mit sudo) ausgeführt werden.
sudo /usr/lib/ssl/misc/CA.pl -newca
Das Stammzertifikat cacert.pem sollte sich nun im Verzeichnis /var/ssl befinden. Da es sich um ein reales, wenn auch eigenes Stammzertifikat handelt, muss es noch System-weit bekannt gemacht werden. Dazu wird es in die offizielle Stammzertifikatsliste im Verzeichnis /etc/ssl/certs eingefügt:
openssl x509 -text -fingerprint -in /var/ssl/cacert.pem > meinedomain.crt cat /etc/ssl/certs/ca-certificates.crt meinedomain.crt > ca-certificates.crt sudo mv ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
LDAP-Server-Zertifikat¶
Hat man in ersten Schritt alles richtig gemacht, befinden sich die eigene Stammzertifizierungsstelle und das zugehörige Zertifikat im Verzeichnis /var/ssl. Nun wird ausgehend vom Verzeichnis /var/ssl das eigentliche Server-Zertifikat erstellt. Dafür wird eine eigene angepasste Konfigurationsdatei verwendet:
sudo cp /usr/lib/ssl/openssl.cnf /etc/ssl
Die Datei /etc/ssl/openssl.cnf editieren und folgende Sektionen hinzufügen:
#################################################################### [ server_ca ] dir = /var/ssl # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. unique_subject = no # Set to 'no' to allow creation of # several ctificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number #crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = v3_server # The extentions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = sha1 # which md to use. preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_anything # For the server policy [ v3_server ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. nsCertType = server # This is typical in keyUsage for a server certificate. keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, msSGC, nsSGC # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Server Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always # This stuff is for subjectAltName and issuerAltname. # Import the email address. subjectAltName=email:copy # Copy subject details issuerAltName=issuer:copy
Anschließend erstellt man eine Zertifikatsanforderung und den privaten Schlüssel ldap_slapd_key.pem für das neue Zertifikat:
ce /var/ssl sudo openssl req -new -config /etc/ssl/openssl.cnf -nodes -keyout ldap_slapd_key.pem -out ldap_slapd_req.pem -days 730 -passin pass:whatever -passout pass:whatever
OpenSSL verlangt mehrere Benutzereingaben, die nachfolgend erläutert werden:
Country Name (2 letter code) [AU]: # z.B. DE
State or Province Name (full name) [Some-State]: # kann ausgelassen werden
Locality Name (eg, city) []: # z.B. Mönchengladbach
Organization Name (eg, company) [Internet Widgits Pty Ltd]: # z.B. meinedomain oder Gas, Wasser Scheisse GmbH
Organizational Unit Name (eg, section) []: # kann man wieder auslassen
Common Name (eg, YOUR name) []: # FQDN des LDAP-Servers
# z.B. ldap.meinedomain.local
Email Address []: # z.B. postmaster@meinedomain.local
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: # Passwort eingeben wie unter passin/passout, z. B. whatever
An optional company name []: # <Enter> drückenDas Passwort für die Verschlüsselung der Anforderung sollte natürlich entsprechend angepasst werden. Anschließend wird die erste Rohform des Server-Zertifikats erstellt und von der eigenen CA signiert:
sudo openssl ca -config /etc/ssl/openssl.cnf -name server_ca -out newcert.pem -infiles ldap_slapd_req.pem
Die Datei newcert.pem enthält die erste Version des X.509-Zertifikats. Aus dieser wird nun das eigentliche LDAP-Server-Zertifikat ldap_slapd_cert.pem erzeugt:
sudo openssl pkcs12 -export -in newcert.pem -inkey ldap_slapd_key.pem -out ldap_slapd_cert.p12 -clcerts -passin pass:whatever -passout pass:whatever sudo openssl pkcs12 -in ldap_slapd_cert.p12 -out ldap_slapd_cert.pem -passin pass:whatever -passout pass:whatever
Natürlich ist auch hier das verwendete Passwort anzupassen.
Installation des LDAP-Server-Zertifikats¶
Achtung!
Grundsätzlich sollten die für TLS benötigten Zertifikate an jedem beliebigen Ort ablegbar sein. Wenn allerdings AppArmor aktiviert ist (wie es in Ubuntu Standard ist) müssen die Zertifikate für OpenLDAP mit GnuTLS an passender Stelle abgelegt werden. Mögliche Verzeichnisse sind u.a. /etc/ssl/certs/, /usr/local/share/ca-certificates/ (letzteres mit Unterverzeichnissen) und /etc/ssl/private/ für den privaten Schlüssel.
Im Verzeichnis /var/ssl/ befinden sich nun alle benötigten Dateien:
Stammzertifikat cacert.pem
Server-Zertifikat ldap_slapd_cert.pem
privater Schlüssel für Server-Zertifikat ldap_slapd_key.pem.
Diese werden nun ins zentrale Verzeichnis /etc/ssl/certs installiert:
sudo install -D -o openldap -g openldap -m 600 /var/ssl/ldap_slapd_key.pem /etc/ssl/private/ldap_slapd_key.pem sudo install -D -o openldap -g openldap -m 600 /var/ssl/ldap_slapd_cert.pem /etc/ssl/certs/ldap_slapd_cert.pem sudo install -D -o openldap -g openldap -m 600 /var/ssl/cacert.pem /etc/ssl/certs/ldap_slapd_cacert.pem
Hinweis:
Sollte man den privaten Schlüssel auf einer anderen Maschine erstellt haben so kann dies unter Umständen dazu führen, dass der Server sich immer mit folgender Fehlermeldung beendet:
TLS init def ctx failed: -207
In diesem Fall hilft es den Inhalt der privaten Schlüsseldatei (/etc/ssl/certs/ldap_slapd_cacert.pem) durch die Ausgabe des Befehls "certtool --infile /etc/ssl/certs/ldap_slapd_cacert.pem -k" ab der Zeile
1 | -----BEGIN PRIVATE KEY----- |
zu ersetzen.
Anpassung der Konfiguration (cn=config-Datenbank)¶
Jetzt muss noch dem LDAP-Serverdämon slpad mitgeteilt werden, dass er TLS verwenden soll. Dazu erstellt man die Datei /etc/ldap/tls.ldif mit folgendem Inhalt:
########################################################### # CONFIGURATION for Support of TLS ########################################################### # Add TLS supported access to user passwords for LDAP clients # to the LDAP config. #dn: cn=config #changetype: modify #delete: olcTLSCACertificateFile dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/ldap_slapd_cacert.pem #dn: cn=config #changetype: modify #delete: olcTLSCertificateKeyFile dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap_slapd_key.pem #dn: cn=config #changetype: modify #delete: olcTLSCertificateFile dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap_slapd_cert.pem
Diese muss dann ins LDAP-Backend eingefügt werden:
ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/tls.ldif
Hinweis:
Von einer Konfiguration des Parameters TLSCipherSuite, wie in manchen Anleitungen vorgeschlagen, sollte abgesehen werden. GnuTLS sucht sich ohnehin die sicherste Verschlüsselung aus. Wird hingegen ein falscher Wert für die TLSCipherSuite eingegeben, startet slapd nicht mehr und muss neu konfiguriert werden.
OpenLDAP unterstützt zwei Verfahren zum Aufbau einer sicheren Kommunikation zwischen LDAP-Server und Client über TLS/SSL:
StartTLS ist eine LDAP-Operation zwischen LDAP-Server und Client, die eine normale LDAP-Verbindung um TLS/SSL-Verschlüsselung erweitert. TLS/SSL wird nach erfolgreichem Abschluss dieser LDAP-Operation initialisiert. Es wird kein zusätzlicher Kommunikationsport benötigt. LDAP-Clients wie der System Security Services Daemon (SSSD) sind so intelligent gebaut, dass sie TLS/SSL nur vorübergehend für die Verschlüsselung der Übertragung sensitiver Daten, wie z. B. Passwörter, einrichten und danch wieder auf die normale LDAP-Verbindung zurückfallen
LDAPS oder ldaps:// verweisen auf LDAP Secured, d. h. LDAP über TLS/SSL. Für die Kommunikation zwischen LDAP-Server und Client wird dauerhaft eine TLS/SSL-Schicht oberhalb von TCP eingerichtet. Das LDAP-Protokoll verwendet normalerweise Port 389 für die Kommunikation. LDAPS benötigt hingegen einen eigenen Kommunikationsport (üblicherweise 636).
Die Extended LDAP Operation StartTLS ist das standardisierte Verfahren in LDAPv3 für die Einrichtung der TLS/SSL Datenverschlüsselung. Bis auf wenige Ausnahmen wird es von allen LDAP-Clients unterstützt. Deswegen wird hier auf die Einrichtung eines weiteren LDAP-Listeners (Option -h von slapd) verzichtet. Dies erfolgt durch Anpassen des Eintrags SLAPD_SERVICES in /etc/default/slapd:
SLAPD_SERVICES="ldap:/// ldapi:///"
Damit ist die Einrichtung von TLS/SSL abgeschlossen.
sudo /etc/init.d/slapd restart
startet den LDAP-Server neu. Nun mit Unterstützung des StartTLS-Verfahrens für die sichere Kommunikation zwischen LDAP-Server und Client.
Test¶
Zum Testen verwendet man am einfachsten die sowieso schon installierten OpenLDAP-Clients. Dazu muss man deren Konfigurationsdatei /etc/ldap/ldap.conf überprüfen und ggf. anpassen. Folgende Einträge sind zwingend erforderlich:
uri ldap://ldap.meinedomain.local/ ldap_version 3 ssl start_tls tls_cacert /etc/ssl/certs/ca_certificates.crt
Dabei den FQDN des LDAP-Servers entsprechend anpassen. Für den Fall, dass der LDAP-Server nur ein selbstsigniertes Zertifikat verwendet, muss der Eintrag tls_cacert angepasst und noch folgender Parameter in /etc/ldap/ldap.conf eingefügt werden:
tls_cacert /etc/ssl/certs/ldap_slapd_cacert.pem TLS_REQCERT allow
Hinweis:
GnuTLS und damit die OpenLDAP-Clients vertrauen nur Server-Zertifikaten, die von Stammzertifizierungstellen mit entsprechendem Stammzertifikat signiert sind. Wurde das Server-Zertifikat von einer nachgeordneten CA signiert, muss die unter Option tls_cacert genannte Datei alle Zertifikate der Signaturkette bis zur Stammzertifizierungsstelle enthalten. Selbstsignierten Zertifikaten wird grundsätzlich nicht vertraut. Sie und alle anderen nicht vertrauenswürdigen Server-Zertifikate werden aber dennoch verwendet, wenn die TLS_REQUEST-Option den Wert allow oder never hat.
Nun kann man endlich die TLS/SSL-Verschlüsselung testen.
ldapsearch -xLLL -Z -W -D cn=admin,cn=config -b cn=config cn=config
Die Option -Z fordert die StartTLS-Operation beim OpenLDAP-Client an. Wenn die Ausführung des Befehls erfolgreich ist, d. h. die TLS-Einstellungen des LDAP-Servers angezeigt werden, kann man sich die Initialisierung von TLS/SSL im Detail ansehen. Dazu gibt man folgenden Befehl ein:
ldapsearch -d 2 -xLLL -Z -W -D cn=admin,cn=config -b cn=config cn=config
In der Ausgabe sollte die StartTLS-Operation, die verwendete TLS-Version und die Übertragung des Server-Zertifikats sichtbar sein. Hier ein Ausschnitt:
ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 -> 1.3.6.1.4.1.1466.20037 is the StartTLS LDAP operation code ldap_read: want=8, got=8 0000: 30 0c 02 01 01 78 07 0a 0....x.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... -> 01 00: 00 is resultCode = success tls_write: want=93, written=93 0000: 16 03 02 00 58 01 00 00 54 03 02 4f 48 1b 02 ca ....X...T..OH... 0010: 6e 94 24 b1 bf 50 08 38 1e 12 21 6d c6 78 7f 84 n.$..P.8..!m.x.. 0020: ee 02 14 a7 1d 93 e5 f6 dd 23 1d 00 00 24 00 33 .........#...$.3 0030: 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 .E.9.....2.D.8.. 0040: 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 ...f./.A.5...... 0050: 00 04 01 00 00 07 00 09 00 03 02 00 01 ............. tls_read: want=5, got=5 0000: 16 03 02 00 4a ....J tls_read: want=74, got=74 0000: 02 00 00 46 03 02 4f 48 1b 02 a9 af 24 4c 96 32 ...F..OH....$L.2 -> 0x0302 is TLS v1.1 0010: 07 f0 e3 1a 18 91 98 cc fd 5f 1b d1 b7 9e e5 36 ........._.....6 0020: d8 3a c2 16 bc 8c 20 da 87 37 f2 b3 84 e5 47 cb .:.... ..7....G. 0030: 0e e0 61 6a 22 1d cc 9f 77 67 cf 9b 1a 45 7c db ..aj"...wg...E|. 0040: 32 02 50 1f 30 f7 4e 00 2f 00 2.P.0.N./. tls_read: want=5, got=5 0000: 16 03 02 08 5d ....] ...
LDAP Authentication¶
Nachdem der LDAP-Server eingerichtet ist, die Linux-Accounts in das LDAP-Verzeichnis migriert worden sind und auch die Authentifizierung am LDAP-Server mittels Simple Authentication and Security Layer (SASL) mit DIGEST-MD5-Mechanismus funktioniert, wird in diesem Abschnitt der Ubuntu-Client in die Lage versetzt, Benutzer mit Eintrag im LDAP-Verzeichnis am LDAP-Server zu authentifizieren. Aufgrund umfangreicher und nach wie vor noch nicht abgeschlossener Umbauten der PAM-basierten Authentifizierung ist die Einrichtung der LDAP-Authentifizierung nicht trivial. Zum Glück gibt es aber einige Ubuntu-Pakete, die, sofern man sie einsetzt, die Arbeit doch erheblich erleichtern.
Achtung!
Die Konfiguration der LDAP-basierten Authentifizierung in Ubuntu ändert sich zur Zeit von Release zu Release. Sie ist schlecht dokumentiert. Selbst der Ubuntu Server Guide 🇬🇧 behandelt das Thema nur sehr oberflächlich. Das hier beschriebene Vorgehen ist aber bis Ubuntu 11.04 getestet. Ob es für frühere Releases anwendbar ist, ist zumindest zweifelhaft.
Es werden folgende Pakete zusätzlich benötigt:
libnss-ldapd
libpam-ldapd
auth-client-config
ldap-auth-client
ldap-auth-config
nslcd
nscd
Befehl zum Installieren der Pakete:
sudo apt-get install libnss-ldapd libpam-ldapd auth-client-config ldap-auth-client ldap-auth-config nslcd nscd
Oder mit apturl installieren, Link: apt://libnss-ldapd,libpam-ldapd,auth-client-config,ldap-auth-client,ldap-auth-config,nslcd,nscd
Hinweis:
Das Paket libpam-ldapd steht erst ab Ubuntu 10.04 zur Verfügung. Für frühere Ubuntu-Versionen muss stattdessen die veraltete libpam-ldap-Bibliothek installiert werden. Doch auch ab Ubuntu 10.04 kommt man an libpam-ldap nicht ganz vorbei, da nur es das LDAP-Schema ldapns.schema bereitstellt. Sobald die zugehörige ldif-Datei aber erstellt ist, kann libpam-ldap bedenkenlos wieder per Hand oder automatisch durch die Installation von libpam-ldapd vom System entfernt werden. Falls alternde Passwörter im LDAP Schema, d. h. Eigenschaften wie ShadowLastChange aus dem ShadowAccount-Schema, verwendet werden und das Datum der letzten Passwortänderung nicht aktualisiert wird: Unter Umständen kann das Problem gelöst werden, indem man die neueren Bibliotheken libnss-ldapd und libpam-ldapd durch die älteren libnss-ldap und libpam-ldap ersetzt.
Benötigte Pakete installieren und konfigurieren¶
Man startet mit libnss-ldapd, das ein Name-Service-Switch-Modul (NSS) zur Verfügung stellt, mit dem der LDAP-Server seine Clients mit Benutzer-Accounts, Gruppen, Host-Namen, Aliases und weiteren Informationen, die üblicherweise in Konfigurationsdateien im Verzeichnis /etc abgelegt sind, versorgen kann.
Es öffnet sich ein Konfigurationsdialog, mit dem festgelegt wird, welche Services mittels LDAP-Lookup zugänglich sein sollen. Zumindest die folgenden Services werden benötigt:
"group"
"passwd"
"shadow"
und sollten markiert werden.
Danach werden die Pakete nslcd und nscd installiert. Die beiden Pakete stellen Dämonen bereit, mittels derer lokale Applikationen (z.B. PAM-Module) die über libnss-ldapd aus dem LDAP-Verzeichnis geholten Informationen entweder direkt oder aus einem Cache abfragen können.
Hinweis:
Ohne nslcd ist kein LDAP-authentifizierter Benutzer-Login möglich. PAM bricht ab mit Fehlermeldung "User not known to the underlying authentication module" auf die Konsole und "login: pam_env(login:session): No such user!?" sowie "login: User not known to the underlying authentication module" im Logfile.
Nach Installation von nslcd
öffnet sich wiederum ein Konfigurationsdialog, mit welchem die zu verwendende LDAP-Server-URI (z. B. ldap://127.0.0.1/, wenn der LDAP-Server auf demselben Rechner läuft) und das LDAP-Suffix (also dc=meinedomain,dc=local) festgelegt werden.
Danach müssen noch die Pakete libpam-ldapd und ldap-auth-config installiert werden.
Letzteres installiert automatisch noch die Pakete auth-client-config und ldap-auth-client mit, sofern diese nicht schon auf dem System vorhanden sind. Anschließend müssen die ldap-auth-Pakete noch konfiguriert werden mittels:
sudo dpkg-reconfigure ldap-auth-config
⚓︎ In dem sich öffnenden Dialog legt man die Konfigurationsoptionen fest, die dann in den Dateien /etc/ldap.conf und /etc/ldap.secret abgelegt werden:
LDAP server Uniform Resource Identifier: ldap://xxxx - hier die LDAP-URI des LDAP-Servers eingeben (z. B. 127.0.0.1, wenn lokal)
Distinguished name of the search base: dc=meinedomain,dc=local - das bei der Installation festgelegte LDAP-Suffix eingeben
LDAP version to use: 3
Make local root Database admin: Yes
Does the LDAP database require login? No
LDAP account for root: cn=admin,dc=meinedomain,dc=local
LDAP root account password: 1234 - hier LDAP-Admin-Passwort eingeben; wird in ldap.secret abgelegt und ist nur root zugänglich
Spätere Änderungen an der Konfiguration sollten wenn möglich ebenfalls nur mit Hilfe von dpkg-reconfigure ldap-auth-config durchgeführt werden, um besser gewappnet zu sein für die weiter oben schon erwähnten zu erwartenden Änderungen bei einem Release-Upgrade.
Nun müssen noch die Konfigurationsdateien für die mit der Authentifizierung betrauten Systemdatenbanken (vorwiegend von PAM verwaltet) und das Name-Service-Switch-Modul (NSS) angepasst werden. Dafür stehen zwei Tools zur Verfügung:
sudo auth-client-config -t nss -p lac_ldap
passt die Datei /etc/nsswitch.conf auf Basis eines in der Profildatenbank im Verzeichnis /etc/auth-client-config/profile.d/ enthaltenen LDAP-Schemas (lac_ldap) an.
Und
sudo pam-auth-update
die PAM-Konfiguration im Verzeichnis /etc/pam.d/. Nach Eingabe des Kommandos erscheint ein Dialog, in dem die zu aktivierenden PAM-Profile ausgewählt werden müssen. Zunächst sollten die Profile
Unix authentication und
LDAP Authentication
ausgewählt werden. Nun sollte das System für die LDAP-Authentifizierung eingerichtet sein.
Test¶
Bevor nun vollständig auf Authentifizierung mittels LDAP umgestiegen wird, sollte das System noch getestet werden. Dazu legt man zunächst einen neuen Benutzer test im LDAP-Verzeichnis an. Hierfür empfiehlt sich die Installation eines weiteren Paketes mit sehr hilfreichen Skripten.
Installation von LDAP-Admin-Skripts¶
ldapscripts
pwgen
Befehl zum Installieren der Pakete:
sudo apt-get install ldapscripts pwgen
Oder mit apturl installieren, Link: apt://ldapscripts,pwgen
Achtung!
In /etc/ldapscripts/ldapscripts.conf wird suggeriert, dass die ldapscripts Parameter wie 'SERVER' automatisch aus einer anderen Konfigurationsdatei lesen können: 'DEBIAN: values from /etc/pam_ldap.conf are used.' Aufgrund eines Bugs im Installationskript unterstützt Ubuntu dies aber nicht. Alle für die ldapscripts benötigten Parameter müssen weiterhin in /etc/ldapscripts/ldapscripts.conf definiert werden.
Dann die Datei /etc/ldapscripts/ldapscripts.conf editieren, Kommentarzeichen löschen und anpassen wie folgt:
SERVER=localhost # falls der LDAP-Server lokal, sonst ldapi/// BINDDN='cn=admin,dc=meinedomain,dc=local' BINDPWDFILE="/etc/ldapscripts/ldapscripts.passwd" SUFFIX='dc=meinedomain,dc=local' GSUFFIX='ou=Groups' USUFFIX='ou=Users' MSUFFIX='ou=Computers' GIDSTART=10000 UIDSTART=10000 MIDSTART=10000 PASSWORDGEN="pwgen"
Anschließend noch die Datei ldapscripts.passwd erstellen für den authentifizierten Admin-Zugang zum LDAP-Verzeichnis:
sudo sh -c "echo -n '1234' > /etc/ldapscripts/ldapscripts.passwd" sudo chmod 400 /etc/ldapscripts/ldapscripts.passwd
Anmerkung: '1234' muss natürlich durch das tatsächliche Passwort des LDAP-Administrators ersetzt werden.
Achtung!
/etc/ldapscripts/ldapscripts.passwd darf keine Zeilenumbrüche enthalten und sollte deshalb ausschließlich mit o.g. echo-Befehl erstellt und modifiziert werden.
Testbenutzer anlegen¶
Anschließend wird der neue Benutzer angelegt mit
sudo ldapaddgroup test sudo ldapadduser test test sudo ldapsetpasswd test
Danach kann überprüft werden, ob test korrekt im LDAP-Verzeichnis angelegt wurde. Unter einem beliebigen nach obiger Migrationsanleitung
von /etc/passwd ins LDAP-Verzeichnis migrierten User-Account lässt man sich die Daten des test-Benutzers ausgeben:
carmen@MeinComputer:~$ ldapsearch -b dc=meinedomain,dc=local uid=test
Ausgabe:
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: carmen SASL SSF: 128 SASL data security layer installed. # extended LDIF # # LDAPv3 # base dc=meinedomain,dc=local with scope subtree # filter: uid=test # requesting: ALL # # test, Users, meinedomain.local dn: uid=test,ou=Users,dc=gas,dc=de objectClass: account objectClass: posixAccount cn: test uid: test uidNumber: 10001 gidNumber: 10001 homeDirectory: /home/test loginShell: /bin/sh gecos: test description: User account # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1
Der Benutzer test ist nur im LDAP-Verzeichnis abgelegt, wovon man sich durch Überprüfen der Datei /etc/passwd überzeugen kann.
Nun mittels
Strg +
Alt +
F3 auf ein Terminal wechseln und einen Login durchführen für den Benutzer test mit dem gerade eben vergebenen Passwort.
Weitere Tests¶
Da OpenLDAP ein doch sehr kompliziertes und recht fehleranfälliges Thema ist, empfehlen sich weitere Tests, die hier aber nur noch kurz aufgezählt werden:
getent groupmuss alle Unix-Gruppen sowie die neue LDAP-Gruppetestausgebengetent passwdgibt alle Unix-Accounts und den Benutzer test ausunter root (z. B. mit
sudo bash) das System über das Skript pam-auth-update auf reine "LDAP Authentication" umstellen und Logins sowiesudo-Kommandos ausführen
Experten-Info:
Liegt der LDAP-Server auf einem anderen PC als der Client und sollte in der Ausgabe getent passwd der Benutzer test, trotz der oben aufgeführten Konfiguration nicht auffindbar sein, ist es möglich das der LDAP-Server die Verbindung ablehnt.
Um dies zu Verifizieren sollte in der ersten Konsole tail -f /var/log/syslog eingegeben werden. In der zweiten Konsole wird nochmals der Befehl getent passwd bestätigt. Erscheint nun in der ersten Konsole die Ausgabe failed to bind to LDAP server ldap://yourLdapServerIP/: Can't contact LDAP server: Transport endpoint is not connected, wird der Client vom Server abgewiesen.
Dieser Fehler tritt auf da LDAP nur auf der virtuellen Loopback (localhost oder 127.0.0.1) Netzwerkkarte auf ein kommende Verbindungen wartet. Dies kommt unter anderem mit einem Sicherheitsgewinn einher, da kein externer Client auf den Datenbestand des Servers zugreifen kann.
Abhilfe schafft folgendes: Es muss auf dem LDAP-Server die Datei /etc/default/slapd bearbeitet werden. Genauer es muss die Zeile
SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
eingefügt werden. Alle anderen Zeilen mit dem Eintrag SLAPD_SERVICES müssen mit einem beginnenden # auskommentiert werden. Daraufhin sollte nochmals der Befehl getent passwd auf dem Client aufgerufen werden. Die nun folgende Ausgabe sollte den Benutzer test enthalten.
Abschließende Arbeiten¶
Wenn man sich genügend von der korrekten Funktion der LDAP-Authentifizerung überzeugt hat, kann man mittels des Befehls deluser die Unix-Accounts der migrierten Benutzer löschen und sich voll auf das LDAP-Verzeichnis verlassen. Ein Parallelbetrieb ist aber genauso möglich. Es sollten beide Authentifizierungsprofile (LDAP-, Unix-Authentification) eingestellt bleiben, da ja nicht alle Benutzer migriert worden sind, was auch wenig sinnvoll wäre.
Wer einen Samba-Server betreibt, kann relativ einfach die migrierten LDAP-Benutzereinträge um Samba-spezifische Attribute erweitern und weitere Accounts (z. B. Computer) hinzufügen, so dass LDAP zur Authentifizierung und als Backend für Samba verwendet werden kann. Dazu existieren zahlreiche Howtos. Nach Abschluss der Arbeiten sollte der Server neu gestartet werden.
Hinweise¶
Zur weiteren Konfiguration und Verwaltung kann man dann z.B. phpLDAPadmin oder luma nutzen.
Links¶
Projektseite 🇬🇧
Das kleine OpenLDAP 1×1 🇩🇪 - Blogbeitrag 12/2008
Dovecot, Exim, OpenLDAP und getmail unter Ubuntu 🇩🇪 Blogeintrag 03/2009
Archiv/Kerberos/LDAP - Kombinationen beider Dienste