LDAP als Authentifikationsserver

Transkript

1 Datennetze Prof. Dr.-Ing. Andreas Grebe Studienarbeit LDAP als Authentifikationsserver Thorsten Reichelt; Markus Kurde;

2

3 Inhaltsverzeichnis 1 Einführung Aufgabenstellung Was sind Verzeichnisdienste? Grundlagen Das X.500 Protokoll Aufbau eines X.500 Verzeichnisses LDAP Protokoll Wie sieht ein Eintrag im Verzeichnis aus? Protokolloperationen Voraussetzungen Das Anmelden am Server Die Abmeldung des Benutzers Ein falsches Passwort Result Codes Die Installation unter Debian Konventionen Voraussetzung Benutzer Änderungen an der Systemkonfiguration Installation des LDAP Servers Installation des Paketes slapd Anpassen der Konfigurationsdateien Installation der LDAP-Utils Benutzerdaten migrieren Funktionskontrolle LDAP für die Benutzerauthentifikation Der nss für LDAP und der nscd Editieren der NSS Konfiguration Kleiner Funktionstest Authentifikation mit dem PAM-LDAP Modul LDAP für den SSH Zugang SASL-Libraries Volle LDAPv3 Unterstützung Installation der notwendigen Pakete Konfiguration SASL Benutzer brauchen ein Passwort...43

4 LDAP Authentifikationsserver - Einführung 1 Einführung 1.1 Aufgabenstellung In einem Firmennetzwerk soll die Authentifikation der Benutzer verschiedener Linux - Clients (SuSe) über eine zentrale Stelle (Server) geregelt werden. Es gibt verschiedene Methoden, dies zu realisieren. Wir haben uns für das Lightweight Directory Access Protocol (LDAP) entschieden. Für diesen Zweck soll ein LDAP-Server ( ) eingerichtet werden, auf dem später die Benutzer angelegt und verwaltet werden. In Gegensatz zu anderen Verfahren (Yellow Pages) ist es bei LDAP nicht nötig, die komplette Dateien passwd und shadow über das Netzwerk auf die Clients zu übertragen. Um die Sicherheit zu erhöhen, kann die komplette Kommunikation zwischen Client und Server verschlüsselt werden (TLS). Auf diese Möglichkeit haben wir allerdings verzichtet, da ansonsten der Mitschnitt der Kommunikation nicht sinnvoll / brauchbar gewesen wäre. Die Installation des LDAP-Servers erfolgt unter dem freien Betriebssystem Debian / Linux, in der zur Zeit aktuellsten Distribution Testing / Sarge. Diese Version ist in der Grundinstallation sehr schlank und es wird keine nicht benötigte Software mit installiert. Im Gegensatz zu SuSe gestaltet sich die Konfiguration stellenweise etwas aufwändiger. 1.2 Was sind Verzeichnisdienste? Verzeichnisse sind eine Auflistung von gespeicherten Informationen über Objekte, die in einer bestimmten Reihenfolge angezeigt werden können. So ist z.b. das normale Telefonbuch das beste Beispiel für ein Verzeichnis. In ihm sind die Namen (Objekte) alphabetisch geordnet "abgelegt". Die Details zu jeder Person sind Telefonnummer und Anschrift. Im EDV - Bereich sind Verzeichnisse spezielle Datenbanken, die, sortiert nach festgelegten Typen, sortierte Informationen über Objekte enthalten. So kann diese Datenbank z.b. Informationen über unterschiedliche Drucker enthalten. Die zusätzlichen Informationen zu jedem Drucker könnten dann der Standort, der Hersteller, die Farbfähigkeit, und die Geschwindigkeit sein. Ein Benutzer kann sich dann alle Farbdrucker anzeigen lassen die mindestens fünf Seiten pro Minute ausdrucken können. Man kann mit dem LDAP Verzeichnissdienst aber auch ganz normale Seite 1

5 LDAP Authentifikationsserver - Einführung Adressbücher aufbauen, um schnell die Adresse eines Geschäftspartners einsortieren oder finden zu können. Geht man einen Schritt weiter, so stellt die Verknüpfung mit aktuellen Programmen und der LDAP-Datenbank keine Hürde mehr dar. Ein globaler Zugriff auf die persöhnlichen Adressen ist von überall möglich. Ein Verzeichnis für sich alleine ist also lediglich eine Ansammlung von Informationen, auf die Zugriff gewährleistet wird. Diese Zugriffe auf die Datenbank können der Suche, der Änderung, der Löschung und der Erstellung von Daten dienen. Für diese Operationen benötigt man das "Application Programming Interface" (API). Dieses Kombination aus reiner Datenbank und strukturierter Oberfläche zum anzeigen und bearbeiten von Daten bezeichnet man als Verzeichnisdienst. Das Ziel von Verzeichnisdiensten ist es, Informationen im Netzwerk strukturiert, schnell und einfach verfügbar zu machen. Der Aufbau solcher Verzeichnisdienste wurde 1998 im X.500 Protokoll standardisiert. Bei X.500 handelt es sich um eine Empfehlung von der ITU ("International Telecommunication Union") im Rahmen der X-Serie (Data Networks and Open System Communications). Der Zugriff auf die Informationen erfolgt über einen Client. Dieser kommuniziert mit dem Server über das DAP ("Directory Access Protocol"). Als Protokoll des obersten OSI-Layers, dem Application Layer, ist es auf den vollständigen darunterliegenden Schichtenstapel angewiesen. Seite 2

6 LDAP Authentifikationsserver - Grundlagen 2 Grundlagen 2.1 Das X.500 Protokoll X.500 ist ein Protokoll der X-Serie, welche einen technischen Satz von Empfehlungen bildet, die Geräte und Verfahren standardisieren, die in öffentlichen und privaten Kommunikationsnetzen eingesetzt werden. Das X.500 Protokoll wurde von der "International Organisation for Standardization" (ISO) entwickelt und von dem Internationalen Konsultativ-Komitee für das Telefonund Telegraphenwesen, kurz CCITT, übernommen. Im Jahre 1865 wurde der Nachfolger der CCITT, die International Telecommunication Union (ITU), im Rahmen einer Strukturreform gegründet und die Empfehlungen der CCITT sind seitdem die ITU-T-Standards. Bei X.500 handelt es sich um einen verteilten, hierarchisch aufgebauten Verzeichnisdienst, der den Zugriff auf Informationen über alle Ressourcen eines Computer-Netzes erlaubt. Das X.500 Protokoll besitzt die folgenden Eigenschaften: Seite 3 Dezentrale Wartung Jeder Betreiber ist nur für seinen eigenen lokalen Bereich des Verzeichnisses zuständig. Formal liegen die Informationen auf einem Server, wobei aber die unterschiedlichen Teile der Datenbank nicht zwingend auf einem einzelnen Rechner abgelegt sein müssen. Mächtige Suchfunktionen X.500 bietet umfangreiche Suchoptionen mit denen die Suche innerhalb des Verzeichnisses vereinfacht wird. Der Benutzer kann beliebig komplexe Suchanfragen stellen. Einziger globaler Namensbereich So ähnlich wie der DNS (Domain Name Service) bietet das X.500 Protokoll dem Anwender einen einzelnen homogenen Namensraum. Aber anders als DNS ist X.500 viel flexibler und erweiterbar. Strukturierter Informationsrahmen X.500 definiert einen im Verzeichnis benutzen Informationsrahmen der auch lokale Erweiterungen erlaubt.

7 LDAP Authentifikationsserver - Grundlagen Basiert auf Standards Da X.500 benutzt werden kann, um ein auf Standards basierendes Verzeichnis aufzubauen, können Applikationen, die auf Verzeichnisinformationen angewiesen sind (z.b. ), auf einheitliche Weise auf die Daten zugreifen. Ganz gleich auf welchem System diese laufen oder sich befinden. Alleine auf Grund dieser Eigenschaften wird X.500 heute als Rückgrat für einen globalen White Pages (Telefonbuch) Service, welcher in Europa, Australien, Amerika und bestimmt noch anderen Kontinenten Anwendung findet, benutzt. Darüber hinaus gibt es noch andere X.500 Implementationen die weitere Eigenschaften dem Protokoll hinzufügen. Zu nennen sind da z.b. Bilder im G3FAX Format, oder Farbfotos im JPEG-Format usw. X.500 kann als vollständig bezeichnet werden: Nichts, was nicht in ihm gespeichert werden könnte. Wesentliche Nachteile sind der hohe Implementationsaufwand und der "schwergewichtige" Zugriff. Die Kommunikation zwischen Client und Server erzeugt eine recht hohe Netzlast, die einer allgegenwärtigen Nutzung hinderlich ist. Seite 4

8 LDAP Authentifikationsserver - Grundlagen 2.2 Aufbau eines X.500 Verzeichnisses Das X.500 Verzeichnis ist baumartig strukturiert (Directory Information Tree, DIT) und besitzt als Wurzel ein namenloses Wurzelobjekt "root". Für die einzelnen Einträge im Verzeichnis werden Objektklassen definiert, wobei jeder Eintrag mindestens einer Klasse angehören muss. Innerhalb dieser Objektklassen gibt es verschiedenen Attributtypen, von denen mindestens einer vorhanden sein muss. Das folgende Beispiel soll den Aufbau eines X.500 Verzeichnisses verdeutlichen. ROOT Land c=de c=jp Organisation o=ajinomoto o=ajinomoto Untereinheit ou=versand ou=service ou=versand ou=service cn=ashitaka cn=shinji Person cn=peter cn=rudolf Abbildung 1 Aufbau eines X.500 Verzeichnisses (traditionelle Bezeichnungen) Jeder Eintrag im obigen Beispiel gehört einer bestimmten Klasse an, von welcher der Wert des Hauptattributs angegeben ist. Dieses Hauptattribut nennt man Primary Distinguished Value. So gehört "c=de" der Objektklasse Country an und das Hauptattribut ist "c" für Country und der Wert ist "DE" für Deutschland bzw. "JP" für Japan. Die Objektklasse "o" (Organisation) definiert hier die Firma. "ou" bezeichnet dann die Organizational Unit der Firma, also die Abteilungen."cn" schließlich enthält den Namen des einzelnen Mitarbeiters. Der Verzeichnisbaum ist also durchaus logisch aufgebaut, wobei die Objekte im Baum (Abbildung 1) traditionell bezeichnet sind. Diese traditionelle Bezeichnung spiegelt die geographischen bzw. die organisatorischen Strukturen wieder. Der traditionelle Aufbau war für den geplanten Einsatz (globales Verzeichnis) auch durchaus sinnvoll. Seite 5

9 LDAP Authentifikationsserver - Grundlagen Aber ein anderer Aufbau gewinnt immer mehr an Beliebtheit. Die Abbildung von Verzeichnissen basierend auf Domainnamen. ROOT dc=de dc=jp dc=ajinomoto dc=co dc=ajinomoto ou=people uid=peter uid=rudolf ou=people uid=shinji uid=ashitaka Abbildung 1 Aufbau eines X.500 Verzeichnisses (Internet Bezeichnungen) Alle Einträge in einem Verzeichnis müssen eindeutig sein. Jeder Eintrag benötigt daher einen sogenannten Distinguished Name (DN). Dieser wird gebildet, indem man alle Objekte der Baumes vom Benutzer aus in Richtung der Wurzel durchläuft. Die Abkürzung dc bedeutet Domain Component und uid bedeutet User Identifikation. Ein DN für Peter im traditionellen Baum sähe also so aus: "cn=peter,ou=versand,o=ajinomoto,c=de" und für den Internetbaum ergibt sich der folgende DN: "uid=peter,ou=people,dc=ajinomoto,dc=de" Seite 6

10 LDAP Authentifikationsserver - Grundlagen 2.3 LDAP Protokoll Das DAP fand am Anfang keine große Akzeptanz da es sehr komplex ist und zudem auf Schicht 7 (Applikationsschicht) des OSI Modells arbeitet. Daher ist es auf den vollständigen darunterliegenden Schichtenstapel angewiesen, den es aber in vielen kleineren Umgebungen gar nicht gibt. Um auch in diesen Netzwerken Verzeichnisdienste nutzen zu können musste ein leichtgewichtigeres Protokoll her, eben das Lightweight Directory Access Protocol (LDAP). Im Gegensatz zum DAP setzt das LDAP direkt auf der TCP/IP Schicht auf, was die Implementation in bestehende Netze vereinfacht. Zusätzlich wurden in LDAP einige Operationen des X.500 entfernt, was den Protokollaufbau stark vereinfachte und zu einer geringeren Netzlast, sowie einer schnelleren Kommunikation führte. DAP Anwendungsschicht Anwendungsschicht Darstellungsschicht LDAP Sitzungsschicht Transportschicht Transportschicht Netzwerkschicht Netzwerkschicht Datenverbindungsschicht Datenverbindungsschicht Hardwareschicht Abbildung 2 DAP und LDAP im Schichtenmodell Seite 7 Hardwareschicht

11 LDAP Authentifikationsserver - Grundlagen LDAP wurde 1993 als "X.500 Lightweight Directory Access Protocol" vorgestellt (RFC 1487) und von W. Yeong (Performance Systems International), T. Howes (University of Michigan) und S. Kille (ISODE Consortium) entwickelt. Mittlerweile hat das Protokoll die Version 3 erreicht. Man spricht daher auch von "LDAP v3" (siehe RFC 2251). Die Unterschiede zu LDAP v2 sind im einzelnen: Verweise auf andere Server können an den Client geliefert werden. Dies erlaubt es dem Server die Verbindung zu anderen Servern dem Client zu überlassen und so die Last zu verringern Die meisten Datenelemente können als normale Zeichenketten kodiert werden ( Distinguished Names). SASL Mechanismen werden unterstützt. LDAP kann jetzt auf die Funktionen der SASL (Simple Authentication and Security Layer) zurückgreifen. SASL ist eine Methode, um auf verbindungsorientierten Protokollen eine Authentifizierung aufzusetzen. Zwischen dem Protokoll (LDAP) und der Verbindung wird eine Sicherungsschicht eingefügt. TLS (Transport Layer Security) wird unterstützt. Damit kann die komplette Kommunikation verschlüsselt ablaufen. Attributwerte und DNs wurden durch die Verwendung des ISO Zeichensatzes (Unicode) internationalisiert. Das Protokoll kann erweitert werden. Das Schema wird im Verzeichnis veröffentlicht und kann vom Client genutzt werden. Seite 8

12 LDAP Authentifikationsserver - Grundlagen LDAP an sich war nur das Protokoll welches auf der TCP/IP Schicht aufsetzte. Im Hintergrund lief weiterhin ein X.500 kompatibler Verzeichnisserver, basierend auf dem OSI Modell. Dieser kann mit den Meldungen des LDAPClients aber nichts anfangen. Der LDAP Server dient damit als Gateway. Client TCP/IP LDAP Server X.500 Client OSI X.500 Server Verzeichnis Abbildung 3 LDAP-Gateway Die heutigen LDAP Server können direkt auf das Verzeichnis zugreifen und brauchen keinen X.500 Server mehr. Der hier eingesetzte LDAP-Server (slapd) ist einer der bekanntesten in der Linuxwelt ( Client TCP/IP LDAP Server Verzeichnis Abbildung 4 Standalone LDAP Server 2.4 Wie sieht ein Eintrag im Verzeichnis aus? Alle LDAP Objekte sind standardisiert und so ist es möglich, dass verschiedene LDAP Dienste zueinander kompatibel sind. Die Liste möglicher Typen von Einträgen (Objektklassen) werden inklusiv, der mit diesen verknüpften Attribute, in den Schemata festgelegt. Diese Schemata werden in Dateien gespeichert und müssen dem Server bekannt gemacht werden. Es gibt zwei definierte Schemata, die in allen LDAP Servern vorhanden sein sollten: nis.schema und inetorgperson.schema. Die Schemata können vom Administrator beliebig erweitert und selbst erstellt werden. Auf den genauen Aufbau der Schemadateien wollen wir hier nicht eingehen. Interessierte finden die entsprechenden Dateien im Verzeichnis /etc/ldap/schema/) oder in RFC A Summary of the X.500(96) User Schema for use with LDAPv3 bzw. RFC Registration Procedures for SOIF Template Types. Möchte man dem Verzeichnis einen Eintrag hinzufügen, so muss bekannt sein welche Schemata dem Server bekannt sind. Sollte es zu Unstimmigkeiten bei den genutzen / verfügbaren Schematas kommen, so führt dies beim Hinzufügen bzw. dem Ändern von Daten zu Fehlermeldungen. Die Einträge eines LDAP Servers kann man entweder bequem über spezielle Clientsoftware verwalten, die dann auch mit einer meist kompfortablen Oberfläche aufwarten kann, oder man schreibt die Einträge selber im LDIF Format. (RFC The LDAP Data Interchange Format (LDIF)) Es wird verwendet, um Verzeichnisinformationen zwischen LDAP-Servern auszutauschen oder um Änderungen in eine bestehende Struktur einzufügen. Seite 9

13 LDAP Authentifikationsserver - Grundlagen Als Beispiel für eine Clientsoftware sei hier einmal exemplarisch "phpldapadmin" genannt. Bei phpldapadmin handelt es sich um eine Oberfläche, die auf einem Webserver (vorzugsweise Apache) mit PHP4 aufbaut. Mit phpldapadmin können komfortabel neue Benutzer angelegt, nach Einträgen gesucht und diese editiert werden. Zu beziehen ist die kostenlose OpenSource Software unter Abbildung 5 phpldapadmin Neben phpldapadmin gibt es noch verschiedene Programme für den Linuxund den Windows-Desktop, die dann allerdings auch immer auf den Clients installiert sein müssen. Seite 10

14 LDAP Authentifikationsserver - Grundlagen Die andere angesprochene Methode ist die Erstellung einer LDIF Datei, die dann mit einem Kommando in den LDAP Server übertragen wird. Die Erzeugung einer solchen Datei ist etwas umständlicher, als die Benutzung der grafischen Oberflächen und nicht wirklich komfortabel. Der Benutzer "schlumpf" würde demnach eine LDIF Datei (schlumpf.ldif) benötigen, die folgendermaßen aufgebaut ist: dn:uid=schlumpf,ou=people,dc=dn,dc=fh-koeln,dc=de objectclass: top objectclass: inetorgperson objectclass: posixaccount objectclass: shadowaccount cn: Geiler Schlumpf sn: schlumpf uid: schlumpf uidnumber: 1000 gidnumber: 1000 homedirectory: /home/schlumpf loginshell: /bin/bash gecos: schlumpf,,, description: System User shadowmax: shadowwarning: 7 shadowlastchange: userpassword: {MD5}vGWxoZo4dwaaF+GZLkQcaq== Diese Datei kann man dann später z.b. mit dem Kommando ldapadd -x -W -h localhost -D "cn=admin,dc=dn,dc=fh-koeln,dc=de" -c -f schlumpf.ldif in das Verzeichniss übertragen. Diese Methode bietet sich aber nur dann an, wenn man große Mengen an Daten anlegen will. Dies ist zum Beispiel dann der Fall, wenn man von einem Standard-Linuxsystem mit shadow und group Datei auf LDAP migrieren will. Keinem Admin möchte man wirklich zumuten, über die grafischen Oberflächen hunderte Benutzer anzulegen, wenn die Arbeit über die LDIF Dateien und mit entsprechenden Skripten (siehe Migrationtools, Seite 32) in Sekunden erledigt ist. Nähere Informationen über das LDIF Format kann man im Internet unter finden. Seite 11

15 LDAP Authentifikationsserver - Protokolloperationen 3 Protokolloperationen Um zu verstehen, was bei einer Kommunikation zwischen einem Client und einem LDAP Server abläuft haben wir uns ein einfaches Beispiel aus der Praxis, die Anmeldung eines Benutzers über die Konsole des Clients, ausgesucht. Der stark vereinfachte Versuchsaufbau sieht in unserem Fall folgendermaßen aus: Server Bux5 DN-Netz Client Abbildung 6 Vereinfachter Versuchsaufbau 3.1 Voraussetzungen Für das folgende Beispiel müssen sowohl der Client als auch der Server vollständig hochgefahren sein und über eine fehlerfreie Netzkonfigurationen verfügen. Der Client befindet sich im Runlevel 3 (Multiuserbetrieb ohne X), sonst stört eventuell die Kommunikation diverser KDE/Gnome Software die Auswertung der Protokolle. Auf dem Server wird jetzt als Benutzer 'root' das Programm Ethereal gestartet. Ethereal ist ein Protokoll-Analyse-Werkzeug welches es ermöglicht, jeglichen Verkehr über die NIC (Network Interface Card) mit zuschneiden. Anhand dieser Mitschnitte kann man dann später sehr genau analysieren, welche Daten von den beiden Rechnern ausgetauscht werden. Momentan unterstützt Ethereal mehr als 650 Protokolle. Für Rechner ohne eine grafische Oberfläche steht auch eine Kommandozeilenversion zur Verfügung (tethereal). Ethereal gibt es für Linux-, Microsoft- und Apple Betriebssysteme unter der Adresse Seite 12

16 LDAP Authentifikationsserver - Protokolloperationen 3.2 Das Anmelden am Server Die folgenden Beschreibungen der Kommunikation basieren auf den Strichdiagrammen, die auf den folgenden Seiten abgebildet sind. Jedes gesendete und empfangene Paket besitzt eine eindeutige Nummer, die sowohl hier im Text als auch im Strichdiagramm Verwendung findet. Abgebildeter Vorgang: Auf dem Client meldet sich der Benutzer "schlumpf" auf der Konsole mit dem Passwort "letmein" an. Nach dem Drücken der ENTER - Taste baut der Client eine Verbindung (#5) zum LDAP Server auf. Hierfür werden zuerst die nötigen TCP-Pakete (SYN und ACK) (#6, #7) zwischen dem Client und dem Server ausgetauscht und der Verbindungsaufbau gestartet. Im Laufe der folgenden Transfers werden bei jeder LDAP Kommunikation ACK und PSH - Flags im TCP-Header gesetzt. Steht die Verbindung, initialisiert der Client die LDAP-Authentifikation mit einem Simple Bind Request. (#8) Bind Request: Diese Operation erlaubt den Austausch der Authentifikationsdaten zwischen Client und Server. Bei einem Bind Request werden version: (3) Version des LDAP-Protokolls name: Name des Objects, welches angefordert wird autentification: (simple) Die Authentifiaktionsmethode (simple, sasl,...) angefragt. Nach einem Bind Request wartet der Client auf ein Bind Result. (#10) Sollten zwischen Bind Request und Bind Result weitere zusätzliche Bind Requests vom Client an den Server gestellt werden, so werden diese erst bearbeitet, wenn auf den ersten geantwortet wurde. In unserem Fall werden zusätzlich zum Bind Request und Bind Result TCPPakete mit einem ACK - Flag versendet. Ist der Bind Request erfolgreich verlaufen, so erhält man ein Bind Result mit dem Result-Code: Success. Dann startet die eigentliche Anfrage nach dem anzumeldenden Benutzer. Hierzu schickt der Client einen Search Request. (#12) Seite 13

17 LDAP Authentifikationsserver - Protokolloperationen Abbildung 7 Erster Teil des Anmeldevorganges über die Konsole Seite 14

18 LDAP Authentifikationsserver - Protokolloperationen Search Request: Diese Operation stellt eine Suchanfrage an den Server. Sie kann eine Liste mit komplexen Suchkriterien enthalten. Es kann ein einzelner Eintrag oder auch ein ganzer Objekt-Baum abgefragt werde. Wichtige Parameter sind: baseobject / Base DN: Der Suchpfad, wo gesucht werden soll. scope: (Subtree) Suche in BaseObject und in all seinen Unterordnern. derefaliases / Dereference: (Never): Dieser Eintrag bestimmt, wie mit Aliaseinträgen verfahren werden soll. Nerver, in unserem Beispiel, bedeutet, dass Aliase nicht berücksichtigt werden. Es gibt noch die Methoden derefinsearch, derefinfindingbaseobj und derefalways. sizelimit: (1) Hier wird angeben, wieviele Suchresultate zurückgegeben werden sollen. timelimit: (0) Hier kann übermittelt werden, wie lange der Client auf die Suchantwort warten möchte. In unserem Fall (0) ist kein spezielles Limit gesetzt und somit kann das maximale Zeitlimit genutzt werden. typesonly / Attributes only: (false) Mit der Option false wird hier festgelegt, dass in der Antwort die Attribute und die zugrhörigen Werte übermittelt werden sollen. Andernfalls würden nur die gefundenden Attribute als Ergebniss präsentiert. filter: (...uid=schlumpf) Hier ist der wichtigste Teil. Die Anfrage nach dem anzumeldenen Nutzer. Dies wird mit der uid (UserID) kenntlich gemacht. Es können mehere Filter durch and, or und not verknüpft werden. Das Filter-Flag ist in weitere Optionen unterteilt, mit welchen die Suche noch weiter verfeinert werden kann. filter.greaterorequal: Grössere oder gleiche Resulate können herausgefiltert / sortiert werden. filter.extensiblematch: Mit dieser Option können noch tiefgreifendere Suchregeln definiert werde, welche mit dem normalen Filter nicht möglich sind. Ist die Anfrage des Clients nach dem Benutzernamen (in unserem Beispiel schlumpf ) versandt, so antwortet der Server mit einem Search Entry für die uid=schlumpf. (#13) Seite 15

19 LDAP Authentifikationsserver - Protokolloperationen Search Entry: Hier werden, wie zuvor in der Suchanfrage festgelegt, alle Einträge unterhalb des Objektes, in der uid=schlumpf vorkommt, aufgelistet. objectname: Hier steht der Pfad im LDAP-Verzeichniss, die User-ID und die Gruppe des Eintrages im LDAP-Verzeichniss attributes: Die gefundenen Attribute. Diese sind z.b. uid, loginshell, homedirectory, name. Das Passwort des Nutzers wird hier nicht übertragen! Jeder Eintrag im Suchergebniss stellt einen Eintrag dar, der während der Suche gefunden wurde. Wird ein Eintrag gefunden, so schickt der Server ein Search Result hinterher. (#14) Im weiteren Verlauf versendet der Client einen weiteren Bind Request. (#15) Dieser beinhaltet wieder die Versionsnummer des LDAP-Protokolls, sowie den genauen Objekt-Pfad zum gefunden Eintrag, den DN: uid=schlumpf, ou=people, dc=dn, dc=fh-koeln, dc=de Die Authentifikationsmethode wird wieder auf simple gesetzt, was bedeutet, dass das Passwort unverschlüsselt im Klartext (siehe Abbildung 9) übertragen wird. Zu guter letzt wird das Passwort (UTF-8 kodiert) mitgeschickt. Als Antwort darauf folgt dann das obligatorische Bind Result des Servers mit der Meldung Result Code: success. (#16) Da der Server ein ok zurück geliefert hat, also das Passwort stimmt, wird vom Client ein abschliessendes Bind Request geschickt. (#17) In diesem Fall wird nur die auth. Methode simple übergeben. Der Objekt-Pfad ist leer. Dies sagt dem Server, dass alles in Ordnung ist und der Client authentifiziert ist. Der Server bestätigt ein letzes mal mit einem Bind Result und dem Result Code: success. (#18) Nachdem der erste Schritt getan ist, folgt danach der zweite Teil des Anmeldeprozesses. Der Client sendet einen Search Request, worin unter anderem alle zuvor vom Server genannten Attribute aufgelistet sind. (#19) Die Filteranweisung zeigt genau auf den Nutzer mit der uid=schlumpf. Seite 16

20 LDAP Authentifikationsserver - Protokolloperationen Abbildung 8 Die Passwörter werden im Klartext übertragen Seite 17

21 LDAP Authentifikationsserver - Protokolloperationen In der Scope-Option wird Subtree übermittelt, also soll der gesamte Unterbaum des Nutzers abgefragt werden. Der Server gibt im folgenden Search Entry alle verfügbaren Informationen an den Client zurück (#20), und schliesst diese Meldung wieder mit einem Search Result Result-Code: success ab. (#21) Den beiden letzen Servermeldungen folgen noch zwei TCP Pakete mit ACK zur Bestätigung. Da der Nutzer schlumpf in mehreren Gruppen eingetragen ist, werden für jede Gruppe Bind Request / Search Request - Kombinationen ausgetauscht, bis alle Daten übermittelt wurden und der Nutzer im ClientRechner vollständig angemeldet ist. Dies haben wir aber aus Platzgründen nicht dargestellt. Außerdem enthalten diese Pakete keine neuen Informationen über den Ablauf. 3.3 Die Abmeldung des Benutzers Normalerweise sollte man annehmen, dass nach erfolgreicher Anmeldung des Benutzers die LDAP/TCP Verbindung wieder abgebaut werden würde. Dem ist aber nicht so. Durch einen Langzeittest konnten wir feststellen, dass es keinen ungeplanten Abbau der Verbindung gibt. Erst beim Abmelden des Nutzers (über die Konsole mit dem Befehl 'exit') sendet der Client einen Unbind Request an den Server. Unbind Request: Diese Option schliesst die LDAP-Verbindung ordnungsgemäß ab. Der Name lässt den Schluss zu, das der Unbind Request etwas mit dem Bind Request zu tun hätte, was aber nicht der Fall ist. Nur der Name ist historisch mit gewachsen. Vielmehr kann das Kommando als einfaches Quit angesehen werden. Es werden keine zusätzlichen Attribute gesetzt. Der Abmeldevorgang läuft dann wie folgt ab: Beenden des Nachrichtenaustausches auf der LDAP Schicht Schliessen der SASL Schicht (wenn installiert) Schliessen der TLS Schicht (wenn installiert) Schliessen der Verbindung. Seite 18

22 LDAP Authentifikationsserver - Protokolloperationen Abbildung 9 Zweiter Teil des Anmeldevorganges über die Konsole Seite 19

23 LDAP Authentifikationsserver - Protokolloperationen Weitere LDAP-Operationen, welche aber nicht im normalen Authentifizierungsvorgang enthalten sind: ModifyRequest: Erlaubt Änderungen an den Daten im LDAP Verzeichnis. operation: AddRequest, DelRequest, ModifyDNRequest object: Name des Eintrages des modifiziert werden soll. changes: Liste der Änderungen an dem genannten Object. Als Antwort auf den Request folgt dann vom Server ein ModifyResponse. CompareRequest: Vergleicht zwei Einträge im LDAP. IntermediateResponse: Verhindert das Sammeln von mehreren Serverantworten. Jede Antwort wird umgehend gesendet. Seite 20

24 LDAP Authentifikationsserver - Protokolloperationen 3.4 Ein falsches Passwort Nachdem wir uns jetzt den normalen An- und Abmeldevorgang angesehen haben stellt sich die Frage, was passiert bei der Eingabe eines falschen Passwortes? Welche Meldungen sendet dann der Server dem Client zurück? Betrachtet man sich das Strichdiagramm auf den nächsten beiden Seiten, so wird man feststellen, dass bis zu dem "Bind Request", in dem der Client dem Server das Passwort sendet alles genauso abläuft wie im oben bereits besprochenen Anmeldevorgang. Hier sendet der Client dem Server aber an der Stelle mit der Ablaufnummer #12 nicht das richtige Passwort, sondern ein völlig falsches. Der Server vergleicht das Passwort mit dem im Verzeichnis gespeicherten. Da das verwendete Passwort nicht mit dem im Verzeichnis gespeicherten übereinstimmt, sendet der Server dieses mal kein "Bind Result" mit "ResultCode: success" an den Client zurück. Stattdessen erfolgt an Stelle #13 das Senden eines "ResultCode: Invalid Credentials (0x31)". Damit teilt der Server dem Client mit, dass der Berechtigungsnachweis (Credential) des Benutzers ungültig war. Der Benutzer konnte also nicht authentifiziert werden. Der Client bindet sich noch einmal an den Server (#14 und #15) und fordert dann abschließend für den Benutzer über ein "Search Request" in (#17) zu den bekannten Attributen die verfügbaren Werte an. Danach bestätigt der Client noch einmal auf TCP - Ebene mit drei ACK Meldungen (für #15, #17 und #18) den Empfang der Pakete. Damit ist die Authentifizierung gescheitert und der Client verweigert dem Benutzer die Anmeldung. Auch hier wird die LDAP/TCP Verbindung nicht sofort mit einem "Unbind Request" bzw. einem gesetzten FIN Flag abgebaut! Seite 21

25 LDAP Authentifikationsserver - Protokolloperationen Abbildung 10 Anmeldung mit einem falschen Passwort Seite 22

26 LDAP Authentifikationsserver - Protokolloperationen Abbildung 11 Anmeldung mit einem falschen Passwort Seite 23

27 LDAP Authentifikationsserver - Protokolloperationen 3.5 Result Codes Der Erfolg der Authentifizierung ist nur von dem Wert des "ResultCode" abhängig. War eine Abfrage erfolgreich, so besitzt der ResultCode den Wert 0x00 bzw. 'success'. Ist das Passwort falsch, so ändert sich der Wert in "Invalid Credentials 0x31". Im RFC 2251 sind ca. 80 verschiedene ResultCodes aufgeführt. Zum Beispiel strongauthrequired (8) wenn eine starke Authentifizierungsmethode verlangt wird. (also nicht simpleauth) nosuchattribute (16) wenn das benutze Attribut nicht im Verzeichnis vorhanden ist entryalreadyexists (68) wenn versucht wird einen bereits existierenden Eintrag zu erstellen Seite 24

28 LDAP Authentifikationsserver - Die Installation unter Debian 4 Die Installation unter Debian Die folgenden Seiten beschreiben die Installation und Konfiguration des OpenLDAP Servers unter Debian / Linux. Ursprünglich war angedacht, neben der Authentifikation unter Linux, den LDAP Server auch für die Authentifikation unter Windows (über den Umweg SAMBA3) zu benutzen. Leider standen uns dafür nicht die nötigen "Resourcen" in Form von anderen Gruppen zur Verfügung, da die Zeit für alle knapp war. Daher erschien uns die Beschränkung auf die Linux Clients für sinnvoll. Eine Installationsanleitung, die zusätzlich auch die Installation von Samba3 und CUPS beschreibt, kann über die Seite heruntergeladen werden. Seite 25

29 LDAP Authentifikationsserver - Die Installation unter Debian 4.1 Konventionen In dieser Installtionsanleitung gelten die folgenden Konventionen für Shellbefehle und Dateien. Shellbefehle sind grau hinterlegt und beginnen immer mit einem $ Beispiel: $ vi /etc/passwd Konfigurationsdateien sind gelb hinterlegt, besitzen aber nur oben und unten eine dünne Linie als Abgrenzung: Ich bin eine Konfigurationsdatei! Innerhalb des Fließtextes werden Dateien und Befehle fett geschrieben. Seite 26

30 LDAP Authentifikationsserver - Die Installation unter Debian 4.2 Voraussetzung Voraussetzung ist ein installiertes Debian System mit dem zur Zeit aktuellen Kernel Das System wurde mit $ apt-get dist-upgrade auf den testing Zweig gebracht. Auszug aus der Konfiguration der /etc/apt/sources.list und /etc/apt/apt.conf.d/70debconf // Pre-configure all packages with debconf before they are installed. // If you don't like it, comment it out. DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt true";}; APT::Default-Release "testing"; # Die Standardpakete deb ftp://kalle.csb.ki.se/pub/linux/debian/ stable main deb ftp://ftp.de.debian.org/debian/ stable contrib main deb ftp://debian.uni-essen.de/debian/ stable non-free # Sicherheitspakete deb stable/updates main contrib non-free deb stable/non-us main contrib non-free deb testing/non-us main contrib non-free # Moegliche Updates für Woody deb woody-proposed-updates main contrib non-free deb-src woody-proposed-updates main contrib non-free deb woody-proposed-updates/non-us main contrib non-free deb-src woody-proposed-updates/non-us main contrib non-free deb proposed-updates main contrib non-free # Testing Pakete deb testing/non-us main deb testing/non-us contrib deb testing main deb testing/non-us main contrib non-free deb-src testing/non-us main contrib non-free # Kernel Quellen deb woody main contrib deb-src woody main contrib deb stable/non-us main contrib non-free deb-src stable/non-us main contrib non-free Seite 27

31 LDAP Authentifikationsserver - Die Installation unter Debian 4.3 Benutzer Normalerweise werden neue User auf Debian und anderen Distributionen mit einer UID von 1000 aufwärts angelegt. Es kann aber durchaus sehr sinnvoll sein, wenn man neue LDAP User mit einer ID ab 2000 anlegt. So vermeidet man Kollisionen mit lokalen Benutzern auf den Clients und dem Server selber. Auch sollte man die Homeverzeichnisse der lokalen Benutzer und der LDAP Benutzer trennen wenn die LDAP Accounts hauptsächlich für Clients benutzt werden. All dies macht kleine Änderungen in der Konfiguration des Systems nötig. Auf der folgenden Seite folgt eine kleine Übersicht über die zu ändernden Dateien. Man kann natürlich alles seinen Vorstellungen anpassen. Seite 28

32 LDAP Authentifikationsserver - Die Installation unter Debian 4.4 Änderungen an der Systemkonfiguration In der Datei /etc/adduser.conf ändern wir nur das vorgegebene Homeverzeichnis von /home auf /home/exports. Dies ist nötig, damit später für die LDAP Benutzer automatisch ein Verzeichnis an dieser Stelle erstellt wird. Lokale Benutzer auf dem Server müssen dann mit 'adduser --home <dir>' angelegt werden. Außerdem kann man die neuen Benutzer alle in die Gruppe 'users' aufnehmen und erspart sich so später das manuelle Anlegen von Gruppen in LDAP. # The DHOME variable specifies the directory containing users' home # directories. DHOME=/home/exports # The USERGROUPS variable can be either "yes" or "no". If "yes" each # created user will be given their own group to use as a default, and # their home directories will be g+s. If "no", each created user will # be placed in the group whose gid is USERS_GID (see below). USERGROUPS=no # If USERGROUPS is "no", then USERS_GID should be the GID of the group # `users' (or the equivalent group) on your system. USERS_GID=100 Sollte man für die Administration die Weboberfläche phpldapadmin benutzen sollte man in dessen Config unbedingt die folgenden Werte setzen: $servers[$i]['enable_auto_uid_numbers'] = true; $servers[$i]['auto_uid_number_mechanism'] = 'search'; $servers[$i]['auto_uid_number_search_base'] = 'ou=people,dc=dn,\ dc=fh-koeln,dc=de'; $servers[$i]['auto_uid_number_min'] = 2000; Seite 29

33 LDAP Authentifikationsserver - Die Installation unter Debian 4.5 Installation des LDAP Servers In diesem Kapitel widmen wir uns der Installation des Servers. Im Laufe der Konfiguration müssen bestimmte Angaben zum Netzwerk und dem Server selber gemacht werden. In diesem Dokument verwenden wir die folgenden Angaben: Name des Servers: bux5 Domainname: dn.fh-koeln.de Organisation: heimat 4.6 Installation des Paketes slapd Wir installieren das Paket slapd mit dem folgenden Befehl: $ apt-get install slapd Die Installationsroutine verlangt die Eingabe verschiedener Daten zum Netzwerk und der Organisation. Die obigen Angaben zum Netzwerk im Hinterkopf beantworten wir die einzelnen Fragen folgendermaßen: Enter the domain name dn.fh-koeln.de Enter the name of your organization heimat Password master Allow LDAPv2 protocol yes 4.7 Anpassen der Konfigurationsdateien Jetzt ist der Server zwar installiert, aber die Konfiguration muss natürlich noch ein wenig angepasst werden. Zuerst einmal ist da die Datei / etc/ldap/ldap.conf. Dies ist die Konfiguration des LDAP Clients. Dieser wird benötigt wenn das System den LDAP Server abfragen will. In die Datei müssen wir jetzt folgendes eintragen: BASE URI dc=dn,dc=fh-koeln,dc=de ldap://localhost Seite 30

34 LDAP Authentifikationsserver - Die Installation unter Debian Die Datei /etc/ldap/slapd.conf ist die Konfigurationsdatei des Servers. Das Installationsscript hat hier schon alles im Moment wichtige eingetragen. Trotzdem können wir auch hier noch etwas verbessern. Der LDAP Server erstellt nämlich einen Index seines Inhaltes. Den Inhalt dieses Index können wir mit den folgenden Zeilen durch zusätzliche Einträge erweitern. So werden z.b. Suchoperationen schneller durchgeführt. # Indexing options for database #1 index objectclass,uid,uidnumber,gidnumber index cn,mail,surname,givenname eq eq,subinitial Besonders wichtig an diesen Zeilen ist, das hinter den Kommata kein Leerzeichen stehen darf. Wir können den Index des Servers jetzt neu erstellen lassen. Dies kann man einfach durch folgende Befehle bewerkstelligen: $ /etc/init.d/slapd stop $ slapindex $ /etc/init.d/slapd start Der Server sollte jetzt wieder fehlerfrei starten. 4.8 Installation der LDAP-Utils Um später nicht wichtige Befehle zu vermissen installieren wir jetzt noch die LDAP Utilities mit dem Befehl: $ apt-get install ldap-utils Seite 31

35 LDAP Authentifikationsserver - Die Installation unter Debian 4.9 Benutzerdaten migrieren Möchte man bereits bestehende Benutzer eines Systems in den LDAP Server übernehmen kann man dies entweder manuell machen, oder man benutzt die Migration Tools. Leider scheint es im Debianpaket der Migration Tools einen kleinen Bug zu geben. Dies ist aber kein Problem, denn wir können uns das aktuellste Paket von der folgender Seite herunterladen: Nach dem Entpacken des Archivs benennen wir das entstandene Verzeichnis in migrationtools um und kopieren es in das Verzeichnis /usr/share. Den Besitzer des Verzeichnisses ändern wir rekursiv in root.root. Als nächstes erstellen wir ein Verzeichnis /etc/migrationtools und legen darin einen symbolischen Link auf die Datei migrate_common.ph im / usr/share/migrationtools Verzeichnis. $ ln -s /usr/share/migrationtools/migrate_common.ph migrate_common.ph Jetzt editieren wir diese Datei und passen sie unseren Bedürfnissen an: # Default DNS domain $DEFAULT_MAIL_DOMAIN = "dn.fh-koeln.de"; # Default base $DEFAULT_BASE = "dc=dn,dc=fh-koeln,dc=de"; $DEFAULT_MAIL_HOST = "mail.dn.fh-koeln.de"; $EXTENDED_SCHEMA = 0; (**) (**) Setzt man EXTENDED_SCHEMA auf 1 können die Benutzer später nicht ohne Fehler importiert werden. Will man ein Adressbuch aufbauen, also mit Adresse, Telefonnummer usw. muss man später jeden User noch einmal als CN Eintrag anlegen. Dies liegt wohl an der LDAP Version. Ab 2.1 geht das nicht mehr Das Migrationsscript migrate_passwd.pl setzt als Passwortalgorithmus CRYPT voraus. Hat man bei der Installation MD5 Passwörter gewählt muss man in der Datei alle {crypt} in {MD5} ändern! In der Datei sollten zwei {crypt} Einträge vorhanden sein. Die Konfiguration der Migration Tools ist damit abgeschlossen und wir können endlich die bestehenden Daten importieren. Da wir LDAP in dieser Anleitung nur für die Authentifizierung der Benutzer verwenden reichen uns die Daten aus der /etc/passwd, und der /etc/groups. Seite 32

36 LDAP Authentifikationsserver - Die Installation unter Debian Um die folgenden Befehle auszuführen müssen wir uns im Verzeichnis /usr/share/migrationtools befinden. $./migrate_base.pl > base.ldif $./migrate_group.pl /etc/group > group.ldif $./migrate_passwd.pl /etc/passwd >passwd.ldif Das Script migrate_base.pl erzeugt die Basisstruktur des LDAP Verzeichnisses. Die beiden anderen erzeugen die ldif Dateien mit den Benutzern aus der passwd und mit den Gruppen aus der Datei /etc/groups. Die drei erzeugten Dateien müssen jetzt noch in das LDAP Verzeichnis übernommen werden. Dazu dienen die folgenden drei Befehle. $ ldapadd -x -W -h localhost -D "cn=admin,dc=dn,dc=fh-koeln,dc=de" -c -f base.ldif $ ldapadd -x -W -h localhost -D "cn=admin,dc=dn,dc=fh-koeln,dc=de" -c -f group.ldif $ ldapadd -x -W -h localhost -D "cn=admin,dc=dn,dc=fh-koeln,dc=de" -c -f passwd.ldif Bei jedem ldapadd wird nach einem Passwort gefragt. Hier muss das Passwort der Installation angegeben werden Funktionskontrolle Für den folgenden Test müssen die Einträge in der Datei /etc/ldap/ldap.conf stimmen. Kommt es bei der Ausführung zu einem Fehler sollte man sich die Datei einmal etwas genauer ansehen. $ ldapsearch -b "ou=people,dc=dn,dc=fh-koeln,dc=de" -LLL -D \ "cn=admin,dc=dn,dc=fh-koeln,dc=de" -H "ldap:// :389/" -W -x Auf dem Bildschirm sollten jetzt alle Einträge aus People zurückgeliefert werden. In People stehen alle Benutzer des Systems, die aus der /etc/passwd importiert wurden. Gibt man hinter dem -x noch "(uid=loginnamedesbenutzers)" (mit Anführungszeichen) an erhält man nur den Eintrag des entsprechenden Benutzers. Ein einfaches ldapsearch -x liefert alle Einträge zurück, die ohne Authentifizierung gelesen werden können. So fehlen bei diesem Kommando z.b. alle gespeicherten Passwörter. Ein weiterer Test ist die Abfrage des Servers von einem Mailprogramm aus. In Thunderbird lässt sich unser LDAP Server z.b. wunderbar als Adressbuch integrieren, was beim ersten Versuch auch direkt funktioniert hat. Seite 33

37 LDAP Authentifikationsserver - Die Installation unter Debian 4.11 LDAP für die Benutzerauthentifikation Wir benutzen LDAP als Authentifikationsserver für die Benutzer. Damit Debian weiß wo es nach den Benutzern und Passwörtern suchen muss, benötigen wir noch zwei Pakete Der nss für LDAP und der nscd Der Name Switching Service dient dazu die Abfragen nach Passwörtern, Gruppen usw. an die verschiedenen Dienste des Systems weiterzuleiten. So kann z.b. zuerst in der passwd nach Passwörtern gesucht werden, dann in einem LDAP Verzeichnis und zum Schluss ein NIS Dienst befragt werden. Das hier installierte Paket fügt die LDAP Unterstützung ein. Der Name Service Cache Daemon speichert die Ergebnisse für eine gewisse Zeit damit bei wiederholter Anfrage die Systemlast nicht zu groß wird. Für die Installation der beiden Pakete führen wir folgende Befehle aus. $ apt-get install nscd $ apt-get install libnss-ldap Die Installation erfordert wieder die Beantwortung einiger Fragen. Hier die Antworten: LDAP server host address : Distinguished name of the search base : dc=dn,dc=fh-koeln,dc=de LDAP version to use : 3 Database requires login : No Make configuration readable/writeable by owner only : Yes Das Paket muss nachher noch manuell konfiguriert werden. Eine Beispielkonfiguration findet man unter /usr/share/doc/libnssldap/examples/nsswitch.ldap. Seite 34

38 LDAP Authentifikationsserver - Die Installation unter Debian 4.13 Editieren der NSS Konfiguration Als nächstes editieren wir die Datei /etc/libnss-ldap.conf, schreiben das Adminpasswort in die Datei /etc/ldap.secret und setzen die Rechte dieser Datei auf 600. DebConf setzt in die libnss-ldap.conf leider nicht den Parameter rotbinddn. (Das Paket libpam-ldap würde dies machen) Ohne dies hat NSS aber keinen Lesezugriff auf die Passwörter der User. Folgende Änderungen müssen in der Datei vorgenommen werden damit der NSS Zugriff auf die Daten erhält: host base dc=dn,dc=fh-koeln,dc=de ldap_version 3 # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) rootbinddn cn=admin,dc=dn,dc=fh-koeln,dc=de Den Rest der Datei fassen wir erst einmal nicht an. Später kann man etwas weiter unten in der Datei noch Optionen für die Verschlüsselung (TLS usw.) konfigurieren. Seite 35

39 LDAP Authentifikationsserver - Die Installation unter Debian Als nächstes muss die Datei /etc/nsswitch.conf ändern. Wir könnten jetzt zwar die Beispieldatei benutzen die nach der Installation im /usr/share/doc/ Verzeichnis liegt, aber diese ist viel zu Umfangreich da wir LDAP ja nur für die Benutzerauthentifikation benutzen wollen und nicht für alle Dienste des Systems. Die alte /etc/nsswitch.conf Datei: passwd: group: shadow: compat compat compat hosts: networks: files dns files protocols: services: ethers: rpc: db db db db netgroup: nis files files files files Die neue Datei: passwd: group: shadow: files ldap files ldap files ldap hosts: networks: files dns ldap files ldap protocols: services: ethers: rpc: db db db db netgroup: nis files files files files Wie man sehen kann wird jetzt zuerst in den Dateien (files) nach den Benutzerdaten gesucht und danach erst im LDAP Verzeichnis (ldap). Seite 36

40 LDAP Authentifikationsserver - Die Installation unter Debian 4.14 Kleiner Funktionstest Um zu kontrollieren ob der NSS richtig läuft kann man per 'deluser <USERNAME>' einen Benutzer aus dem System und damit aus der passwd herauslöschen. Jetzt kann man mit dem Befehl $ getent passwd grep <GELÖSCHTERUSERNAME> kontrollieren, ob der Benutzer in LDAP noch existiert. Ist dies der Fall müsste eine Ausgabe auf dem Bildschirm erfolgen die in etwa so aussieht: $ getent shadow grep shinji shinji:x:12497::99999:7:::0 Als weiteren Test legt man jetzt einfach eine leere Datei an $ touch /tmp/testdatei $ chown 1001 /tmp/testdatei // 1001 ist die ID des eben gelöschten Users $ ls -l /tmp/testdatei Es sollte jetzt in etwa folgendes ausgegeben werden: -rw-r--r-- 1 shinji root 0 Jun 10 23:51 /tmp/testdatei Sollte anstatt shinji (GELÖSCHTERUSERNAME) nur eine 1001 dort stehen läuft irgendetwas noch nicht richtig. Seite 37

41 LDAP Authentifikationsserver - Die Installation unter Debian 4.15 Authentifikation mit dem PAM-LDAP Modul Das Modul libpam-ldap ist eigentlich nicht nötig für die Authentifizierung, denn dies kann genauso gut mit pam_unix gemacht werden. Trotzdem ist es nötig um mit dem normalen passwd die LDAP Einträge zu aktualisieren und quasi on the fly beim ersten Anmelden die Home-Verzeichnisse neuer Benutzer erstellen zu lassen. Wir ändern nur die Datei /etc/pam.d/passwd nachdem wir das Paket "libpam-ldap" installiert haben: $ apt-get install libpam-ldap Die Fragen bei der Installation beantworten wir nacheinander mit: LDAP Server host : Distinguished Base Name : LDAP version : Make local root Database admin : Database requires logging in : Root login account : Local crypt to use : dc=dn,dc=fh-koeln,dc=de 3 Ja Nein cn=admin,dc=dn,dc=fh-koeln,dc=de crypt Die Datei /etc/pam.d/passwd sollte jetzt folgenden Inhalt bekommen: password password required optional pam_ldap.so ignore_unknown_user md5 pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass #@include common-password //Wenn man das drin lässt geht es irgendwie nicht. Warum? Das md5 bedeutet, das alle neuen oder geänderten Passwörter in MD5 verschlüsselt werden. Die Datei /etc/pam.d/common-session sollte folgenden Inhalt bekommen: session session session session required required required optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 pam_limits.so pam_unix.so pam_ldap.so Das Modul pam_mkhomedir.so legt für einen neuen User beim ersten Anmelden über SSH oder die Konsole ein neues Homeverzeichnis an. Der Inhalt des Verzeichnisses /etc/skel dient dabei als Vorlage und wird in das neue Userverzeichnis kopiert. Seite 38

42 LDAP Authentifikationsserver - Die Installation unter Debian Sollte es sich bei den Clients z.b. nur um SuSE Clients handeln ist es eventuell sinnvoll wenn man von einem der SuSE Clients den Inhalt des dortigen /etc/skel Verzeichnisses in ein /etc/skel_suse Verzeichnis kopiert und dieses dann für das pam_mkhomedir.so Modul angibt. Jetzt muss man noch kontrollieren, ob die Abhängigkeiten richtig aufgelöst wurden. Dies kann man unter Debian einfach mit $ ldd /lib/security/pam_ldap.so kontrollieren. Gibt der Befehl irgendwo not found aus, stimmt etwas nicht. Seite 39

43 LDAP Authentifikationsserver - Die Installation unter Debian 4.16 LDAP für den SSH Zugang Normalerweise sollte SSH auch ohne weitere Konfiguration laufen wenn die Standard PAM-Authentifikation für LDAP konfiguriert wurde. Trotzdem kann man den SSH Server für die direkte Benutzung von LDAP konfigurieren. Dazu müssen wir die Datei /etc/pam.d/ssh konfigurieren. Folgende Zeilen müssen in der angegebenen Reihenfolge in der Datei stehen. Und zwar VOR common-... # Disallow non-root logins when /etc/nologin exists. auth required pam_nologin.so # Eingefügt für LDAP auth sufficient auth required pam_ldap.so pam_unix.so use_first_pass # Read environment variables from /etc/environment and # /etc/security/pam_env.conf. auth required pam_env.so # [1] [...] # Standard Un*x authorization. # Eingefügt für LDAP account sufficient account required <== NICHT AUTHENTIFICATION!!! pam_ldap.so pam_unix.so common-account [...] Jetzt muss der SSH Server mit folgendem Befehl neu gestartet werden. $ /etc/init.d/ssh restart Man sollte sich jetzt von einem anderen Rechner über SSH auf dem Server anmelden können. Seite 40

44 LDAP Authentifikationsserver - Die Installation unter Debian 4.17 SASL-Libraries Volle LDAPv3 Unterstützung Obwohl die SASL Libraries nicht notwendig sind, um einen LDAP Server zu betreiben wird dieser nur durch eben die Libraries LDAPv3 kompatibel. Es gibt für Debian die folgenden SASL Libraries: digestmd5 digestmd5-plain digestmd5-des gssapi-mit gssapi-heimdal krb4-mit Der häufigste Grund für die Verwendung von LDAP mit SASL ist die Kerberos Authentifizierung und die Integration in andere SASL fähige Software wie etwas Sendmail oder den Cyrus IMAPD Server. Eine andere Möglichkeit wäre zum Beispiel, den normalen Benutzern eine Abfrage des Servers (für Adressbücher usw.) ohne Authentifizierung zu erlauben, dem Administrator aber eine Authentifizierung über SASL vorzuschreiben Installation der notwendigen Pakete Die Installation und Einrichtung scheint etwas kompliziert zu sein. Als erstes installieren wir einmal die SASL Pakete: $ apt-get install sasl2-bin libsasl2-modules 4.19 Konfiguration Danach editieren wir dir Konfigurationsdatei /etc/default/saslauthd START=yes MECHANISMS="pam" Durch das START=yes wird der SASL Server automatisch gestartet. Der SASL Daemon sollte sich ohne Probleme starten lassen. $ /etc/init.d/saslauthd start Starting SASL Authentication Daemon: saslauthd. Seite 41