ubuntuusers.de

ubuntuusers.deWikiOpenLDAP

OpenLDAP

Hinweis:

Ab Ubuntu 12.04 bitte den Artikel OpenLDAP ab Precise nutzen.

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

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 {en} 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 {en} 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. 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install slapd ldap-utils 

sudo aptitude install 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:

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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install samba-doc 

sudo aptitude install 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install amavis 

sudo aptitude install amavis 

Bis Ubuntu 10.10 bekommt man das Schema ldapns.schema über das Paket:

  • libpam-ldap

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install libpam-ldap 

sudo aptitude install 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install amavisd-new 

sudo aptitude install 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}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1

Den 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}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1

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

Hier 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install slapd ldap-utils php5-ldap db4.2-util 

sudo aptitude install slapd ldap-utils php5-ldap db4.2-util 

Zum Testen wird außerdem - optional - das Paket

  • nmap

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install nmap 

sudo aptitude install 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.

{top}

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.

{top}

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:

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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install smbldap-tools 

sudo aptitude install 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.

{top}

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 

{top}

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:

  1. Selbstsigniertes Zertifikat

  2. Bezug von einer Zertifizierungsstelle (Certification Authority)

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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install gnutls-bin 

sudo aptitude install 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install openssl 

sudo aptitude install 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 {en}.

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

Das 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                                     ....]  

...

{top}

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 {en} 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install libnss-ldapd libpam-ldapd auth-client-config ldap-auth-client ldap-auth-config nslcd nscd 

sudo aptitude install 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

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install ldapscripts pwgen 

sudo aptitude install 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 group muss alle Unix-Gruppen sowie die neue LDAP-Gruppe test ausgeben

  • getent passwd gibt alle Unix-Accounts und den Benutzer test aus

  • unter root (z. B. mit sudo bash) das System über das Skript pam-auth-update auf reine "LDAP Authentication" umstellen und Logins sowie sudo-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.

Diese Revision wurde am 21. November 2014 06:20 von Joerg.Bernau erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Server, Internet