{{{#!vorlage Hinweis Ab [:Precise Pangolin:Ubuntu 12.04] bitte den Artikel [:Archiv/OpenLDAP ab Precise:] nutzen. }}} [[Vorlage(Archiviert)]] [[Vorlage (Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] [:Rechte: Dateirechte ändern] }}} [[Anker(top)]] [[Inhaltsverzeichnis()]] [http://www.openldap.org/ OpenLDAP] {en} stellt das Anwendungsprotokoll [wikipedia: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. {{{#!vorlage 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. [https://lists.ubuntu.com/archives/ubuntu-server/2009-August/003182.html 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. [:Archiv/Kerberos:]). {{{#!vorlage Hinweis Die folgenden Befehle müssen immer als [:sudo:root] ausgeführt werden: }}} == Ubuntu-Pakete installieren == Am Anfang steht natürlich die Installation [1] von OpenLDAP: {{{#!vorlage Paketinstallation slapd ldap-utils }}} Weitere Pakete sind optional und für die Funktionalität von OpenLDAP nicht zwingend erforderlich. {{{#!vorlage Warnung 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 [:Maverick_Meerkat:Ubuntu 10.10] ist `core.schema` ist das einzige Schema, bei der Installation von slapd automatisch in das ''cn=config''-Backend aufgenommen wird): {{{#!vorlage Befehl 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 [:Natty_Narwhal:Ubuntu 11.04] kann man auch noch folgende weitere Schemata hinzufügen: {{{#!vorlage Befehl 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. {{{#!vorlage 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 [:Natty_Narwhal: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: {{{#!vorlage Paketinstallation samba-doc }}} {{{#!vorlage Befehl 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: {{{#!vorlage Paketinstallation amavis }}} Bis [:Maverick_Meerkat:Ubuntu 10.10] bekommt man das Schema `ldapns.schema` über das Paket: {{{#!vorlage Paketinstallation libpam-ldap }}} Bei der Installation des Pakets öffnet sich ein Konfigurationsdialog, der im Kapitel [#ldap_auth_config LDAP Authentication] beschrieben wird. Spätere Änderungen an der LDAP-Authentication-Konfiguration sind durch Aufruf von `dpkg-reconfigure ldap-auth-config` jederzeit möglich. {{{#!vorlage Befehl cp -v /usr/share/doc/libpam-ldap/ldapns.schema /etc/ldap/schema }}} Ab [:Natty_Narwhal:Ubuntu 11.04] muss man auch das Schema `amavis.schema` nachinstallieren. Man bekommt es über das Paket: {{{#!vorlage Paketinstallation amavisd-new }}} direkt in das Verzeichnis '''/etc/ldap/schema''' installiert. 2. Erstellen eines temporären Verzeichnisses für die LDIF-Dateien {{{#!vorlage Befehl mkdir /tmp/ldif_output }}} 3. Konvertieren der Schemata ins LDIF-Format mit Hilfe von '''slapcat''' und Kopieren ins Verzeichnis '''/etc/ldap/schema''': {{{#!vorlage Befehl 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: {{{#!vorlage Befehl #!/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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl slappasswd }}} {{{ New password: Re-enter new password: {SSHA}dx0sCgNBPlx98eRYnun1QBNfrWUR6qM1 }}} Den Hash sollte man sich notieren, da er nachfolgend immer wieder benötigt wird. Ab [:Natty_Narwhal: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 [:Maverick_Meerkat: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: {{{#!vorlage Befehl 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 [:Maverick_Meerkat: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): {{{#!vorlage Befehl 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 [:Jaunty_Jackalope:Ubuntu 9.04] sein und kann das LDAP-Verzeichnis ganz normal [#migration 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: {{{#!vorlage Befehl 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): {{{#!vorlage Befehl ldapsearch -xLLL -b dc=meinedomain,dc=local }}} == Weitere Konfiguration == Im nachfolgenden Kapitel wird nun zunächst die Installation des LDAP-Servers bis [:Jaunty_Jackalope: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: [#migration {Weitere Konfiguration}] = Installation bis Ubuntu 9.04 = == Ubuntu-Pakete installieren == {{{#!vorlage Hinweis Die folgenden Befehle müssen immer als [:sudo:root] ausgeführt werden: }}} Als erstes müssen die entsprechenden Pakete heruntergeladen und installiert werden: {{{#!vorlage Paketinstallation slapd ldap-utils php5-ldap db4.2-util }}} Zum Testen wird außerdem - optional - das Paket {{{#!vorlage Paketinstallation 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 {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. {{{#!vorlage Befehl 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]. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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'' == {{{#!vorlage 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 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 # 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: {{{#!vorlage Befehl /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 {{{#!vorlage Befehl mv slapd.d slapd.d.bck }}} Danach erstellt man ein neues '''slapd.d'''-Verzeichnis und lädt die '''slapd.conf''' {{{#!vorlage Befehl 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]: {{{#!vorlage Befehl chown -R openldap:openldap slapd.d }}} Nun kann der LDAP-Server wieder gestartet werden: {{{#!vorlage Befehl /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. {{{#!vorlage Befehl ldapadd -x -h (-p ) -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: {{{#!vorlage Befehl 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 {top}] [[Anker(migration)]] = 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: {{{#!vorlage Befehl sudo ldapadd -x -h (-p ) -W -D cn=admin,dc=meinedomain,dc=local -f init.ldif }}} 2. Installation und Konfiguration des Pakets {{{#!vorlage Paketinstallation 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 [:sudo:root] ausgeführt werden: {{{#!vorlage Befehl 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 [:sudo: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. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl ./smbldap-migrate-unix-accounts -P passwd.users -S /etc/shadow -v }}} {{{#!vorlage 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. {{{#!vorlage Befehl 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 }}} {{{#!vorlage 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: }}} {{{#!code perl $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 {{{#!vorlage Befehl 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. {{{#!vorlage Warnung 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 {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 # # 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: {{{#!vorlage Befehl 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=,cn=,cn=,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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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) {{{#!vorlage Befehl sudo ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -s NeuesPasswort uid=carmen,ou=Users,dc=meinedomain,dc=local }}} Nach Eingabe von {{{#!vorlage Befehl 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 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 [:sudo: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 [:sudo:root], ohne selbst im LDAP-Verzeichnis abgelegt zu sein, auf dasselbe zugreifen. Die Hinterlegung des Passwortes in Klartext erfolgt über {{{#!vorlage Befehl ldappasswd -x -D cn=admin,dc=meinedomain,dc=local -W -S cn=admin,dc=meinedomain,dc=local }}} [#top {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. {{{#!vorlage Warnung 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 1. Bezug von einer Zertifizierungsstelle (''Certification Authority'') 1. 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: {{{#!vorlage Paketinstallation 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl sudo sh -c "certtool --generate-privkey > cakey.pem" }}} {{{#!vorlage Befehl 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) ==== {{{#!vorlage Befehl 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: {{{#!vorlage 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-des-LDAP-Server-Zertifikats 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. {{{#!vorlage Paketinstallation 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 [http://tldp.org/HOWTO/SSL-Certificates-HOWTO/ 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: {{{#!vorlage Befehl 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. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 []: # 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: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 == {{{#!vorlage Warnung 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: {{{#!vorlage Befehl 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 }}} {{{#!vorlage 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 {{{#!code -----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: {{{#!vorlage Befehl ldapadd -x -D cn=admin,cn=config -W -f /etc/ldap/tls.ldif }}} {{{#!vorlage 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. {{{#!vorlage Befehl 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 }}} {{{#!vorlage 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. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 {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 [wikipedia: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. {{{#!vorlage Warnung Die Konfiguration der LDAP-basierten Authentifizierung in Ubuntu ändert sich zur Zeit von Release zu Release. Sie ist schlecht dokumentiert. Selbst der [https://help.ubuntu.com/11.04/serverguide/C/openldap-server.html#openldap-configuration Ubuntu Server Guide] {en} behandelt das Thema nur sehr oberflächlich. Das hier beschriebene Vorgehen ist aber bis [:Natty_Narwhal: Ubuntu 11.04] getestet. Ob es für frühere Releases anwendbar ist, ist zumindest zweifelhaft. }}} Es werden folgende Pakete zusätzlich benötigt: {{{#!vorlage Paketinstallation libnss-ldapd libpam-ldapd auth-client-config ldap-auth-client ldap-auth-config nslcd nscd }}} {{{#!vorlage Hinweis Das Paket '''libpam-ldapd''' steht erst ab [:Lucid_Lynx:Ubuntu 10.04] zur Verfügung. Für frühere Ubuntu-Versionen muss stattdessen die veraltete '''libpam-ldap'''-Bibliothek installiert werden. Doch auch ab [:Lucid_Lynx: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 ([wikipedia: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. [wikipedia:PAM:]-Module) die über '''libnss-ldapd''' aus dem LDAP-Verzeichnis geholten Informationen entweder direkt oder aus einem Cache abfragen können. {{{#!vorlage Hinweis Ohne '''nslcd''' ist kein LDAP-authentifizierter Benutzer-Login möglich. [wikipedia: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: {{{#!vorlage Befehl sudo dpkg-reconfigure ldap-auth-config }}} [[Anker(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 [:sudo: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 ([wikipedia:NSS:]) angepasst werden. Dafür stehen zwei Tools zur Verfügung: {{{#!vorlage Befehl 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 {{{#!vorlage Befehl 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 === {{{#!vorlage Paketinstallation ldapscripts pwgen }}} {{{#!vorlage Warnung 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: {{{#!vorlage Befehl 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. {{{#!vorlage Warnung '''/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 {{{#!vorlage Befehl 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 [#migration Migrationsanleitung] von '''/etc/passwd''' ins LDAP-Verzeichnis migrierten User-Account lässt man sich die Daten des `test`-Benutzers ausgeben: {{{#!vorlage Befehl 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 [[Vorlage(Tasten, STRG)]] + [[Vorlage(Tasten, ALT)]] + [[Vorlage(Tasten, 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 [:sudo: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 {{{#!vorlage Experten 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 = * [:Archiv/OpenLDAP ab Precise:] * [http://www.openldap.org/ Projektseite] {en} * [wikipedia:OpenLDAP:] * [http://tuxnetworks.blogspot.com/2010/06/howto-ldap-server-on-1004-lucid-lynx.html HOWTO LDAP Server on 10.04 Lucid Lynx] {en} * [http://www.effinger.org/blog/2008/12/14/das-kleine-openldap-1x1/ Das kleine OpenLDAP 1×1] {de} - Blogbeitrag 12/2008 * [http://www.effinger.org/blog/2009/03/22/dovecot-exim-openldap-und-getmail-unter-ubuntu-1-openldap/ Dovecot, Exim, OpenLDAP und getmail unter Ubuntu] {de} Blogeintrag 03/2009 * [http://wiki.ubuntu-forum.de/index.php/OpenLDAP#LDAP_im_Thunderbird_einrichten LDAP im Thunderbird einrichten] {de} * [:Archiv/Kerberos/LDAP:] - Kombinationen beider Dienste #tag: Internet, Server