Aufbau eines Metaverzeichnisses

Transkript

1 Fachhochschule Aachen Abteilung Jülich Aufbau eines Metaverzeichnisses Bachelorarbeit vorgelegt von: Fachbereich: Studiengang: Jaouad Doghmi Medizintechnik und Technomathematik Scientific Programming Matrikelnummer: Erstgutachter: Zweitgutachter: Prof. Dr. rer. nat. Volker Sander Josef Heinen Jülich, den 13. Oktober 2008

2

3 Die vorliegende Bachelorarbeit wurde in Zusammenarbeit mit dem Forschungszentrum Jülich GmbH, Institut für Festkörperforschung (IFF), angefertigt. Diese Bachelorarbeit wurde betreut von: Erstgutachter: Zweitgutachter: Prof. Dr. rer. nat. Volker Sander (Fachhochschule Aachen) Josef Heinen (Forschungszentrum Jülich) Diese Arbeit wurde von mir selbständig angefertigt und verfasst. Es sind keine anderen als die angegebenen Quellen und Hilfsmittel benutzt worden. Unterschrift

4

5 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung III 1.1 Problembeschreibung III 1.2 Zielsetzung III 1.3 Was ist ein Verzeichnisdienst IV Active Directory V Open Directory VIII Network Information Service IX 2 Einleitung Problembeschreibung Zielsetzung Was ist ein Verzeichnisdienst Active Directory Open Directory Network Information Service LDAP und OpenLDAP Einführung Aufbau eines LDAP-Verzeichnisses LDAP-Server Installation von OpenLDAP Konfiguration und Aufsetzen von OpenLDAP Erster Import: LDAP-Datenbank initialisieren Benutzerverwaltung Benutzeranmeldung Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete ldapsearch ldapmodify ldapdelete I

6 Inhaltsverzeichnis Webinterface - phpldapadmin Kerberos Einführung Funktionsprinzip Konfiguration und Start Kerberisierter LDAP-dienst Frameworks Motivation Installation Lösungsansatz/Konzepte Linux-Schnittstelle Authentifizierungs- und Adressbuchdaten in die Datenbank überführen LDAP-Server mit Datenbankdaten füllen Windows-Schnittstelle Macintosh-Schnittstelle Anwendungsbeispiele 53 8 Kritische Betrachtung und Ausblick 57 Abbildungsverzeichnis 58 A AnhangA B AnhangB i iii II

7 1 Einleitung 1.1 Problembeschreibung Die gemeinsame Einrichtung Netzwerke und Numerik betreibt im Institut für Festkörperforschung (IFF) im Forschungszentrum Jülich ein heterogenes Netzwerk mit über 1000 Rechnern mit den Betriebssystemen Linux, Windows, Mac OS X und Digital Unix. Für diese Systeme werden zentrale Fileserver-, Mail-, Drucker- und Benutzerverwaltungsdienste angeboten. Der Zugriff auf Programm-, Mess- und Simulationsdaten erfolgt aus der Sicht des Benutzers transparent. Da aber in den verschiedenen Systemen unterschiedliche Technologien wie Active Directory Server (Microsoft), OpenDirectory (Macintosch) und Network Information Service (Linux) eingesetzt werden, kann es zu Inkonsistenzen in den Benutzerinformationen kommen. Diese oben benannten Technologien werden als Verzeichnisdienste bezeichnet. 1.2 Zielsetzung Dieser Umstand legt die Einführung eines Metaverzeichnisses auf der Basis einer Datenbank nahe, in der die gesamte Information zentral vorgehalten und mit den darunterliegenden Systemen abgeglichen werden kann. Durch diese Struktur werden - im Gegensatz zu am Markt verfügbaren Lösungen - insbesondere Abhängigkeiten von einem einzelnen System vermieden. Ziel dieser Arbeit ist der Entwurf der zu Grunde liegenden Datenbank sowie die Implementierung der nötigen Schnittstellen, damit die verschiedenen Systeme (Unix, Windows, Macintosh) über ihre nativen Verzeichnisdienste auf diese Daten III

8 1 Einleitung zugreifen können. Hierbei werden Authentifizierungs- und Adressbuchinformationen bereitgestellt. Der Zugriff auf die Verzeichnisinformationen erfolgt über Standardmäßige Internetkommunikationsprotokolle für TCP/IP-Netzwerke. Diese Protokolle vereinfachen mit möglichst geringem Aufwand die Kommunikation zwischen den verschiedenen Verzeichnisdiensten (Interoperabilität) und definieren Operationen, die zum Abfragen und Ändern von Verzeichnisinformationen verwendet werden. Es werden Programme entwickelt, die Verzeichnisdienstinformationen in die Datenbank (MYSQL-DatenbanK) und umgekehrt die Datenbankinformationen in den Verzeichnisdiensten überführen. Als erster Schritt und bevor man mit der Konzeption anfängt, ist es zunächst notwendig, die Verzeichnisdienste der drei Welten Linux, Windows und Macintoch vorzustellen, die in diese Arbeit eingesetzt werden. 1.3 Was ist ein Verzeichnisdienst Ein Verzeichnisdienst ist eine im Netzwerk verteilte hierarchische Datenbank. Es gibt dennoch mehrere grundlegende Unterschiede zwischen relationalen Datenbanken und Verzeichnisdiensten. Letztere wurden haupsächlich für das Auffinden von Daten optimiert, da Leserzugriffe wesentlich häufiger durchgeführt werden müessen, als Leserzugriffe. Im Gegensatz dazu sind Datenbanken meist schreib- /leseoptimiert. Datenbanken laufen meist auf einem einzelnen Server, dagegen können Verzeichnisdienste über mehrere Server verteilt sein. Das heißt es können Teile der Verzeichnisstruktur auf unterschiedlichen Servern liegen oder einfach nur Kopien des kompletten Verzeichnisses. Verzeichnisdienste sind in der Regel objektorientiert, unterstützen keine Transaktionen und es gibt auch keine Relationen. Ebenso gibt es auch keine aufwendige (Programmier-)Sprache wie SQL bei relationalen Datenbanken. Grundsätzlich ist ein Verzeichnisdienst unabhängig vom zugrundeliegenden Betriebssystem. So wird von allen Betriebssystemherstellern ein entsprechender Dienst zur Verfügung gestellt (Active Directory von Microsoft, Open Directory von Macintosh, NIS von Linux usw.). Der Verzeichnisdienst stellt eine zentrale Informationsquelle in einer Organisation (Forschungszentrum Jülich) dar. IV

9 1.3 Was ist ein Verzeichnisdienst Innerhalb dieser Informationsquelle werden Informationen über die im Netzwerk vorhandenen z.b. Computer / Drucker sowie Benutzer und Gruppenkennzeichen verwaltet und Informationen den angemeldeten Benutzern zur Verfügung gestellt. Benutzer können in diesem Verzeichnisdienst nach beliebigen Attributen eines Objektes suchen. So ist es z.b. Möglich nach allen Druckern zu suchen die über spezielle Eigenschaften (beidseitiger Druck, Farboption...) verfügen Active Directory Active Directory ist der Verzeichnisdienst von Microsoft Windows 2000/ Windows Server Die in Active Directory gespeicherten Daten, zb. Informationen über Benutzer, Gruppen, Computer und Drucker, werden in Form von Objekten organisiert. Ein Objekt ist ein individueller, benannter Attributsatz, der eine bestimmte Netzwerkressource repräsentiert. Als Objektattribute werden die Eigenschaften der Objekte bezeichnet. Die Attribute eines Benutzerkontos umfassen beispielsweise den Vor-, Nach- und Anmeldenamen des Benutzers, während die Attribute eines Computerobjektes den Computernamen und eine Beschreibung enthalten können. Jedes Objekt ist in einem Schema definiert. Das Schema ist eine Definitionsliste, die festlegt, welche Art von Objekten und welche Art von Informationen zu einem Active Directory-Objekt gespeichert werden können. Mehr zu dem Aufbau der Active Directory-Komponenten wird in Detail im abschnitt 3.2 (Aufbau eines LDAP-Verzeichnisses) beschrieben, da Active Directory auf einem Standardprotokoll das sogenannte LDAP basiert. Zusätzlich bietet Active Directory folgende Eigenschaften: Zentraler Datenspeicher: Sämtliche Daten werden in einem verteilten Datenspeicher abgelegt, wodurch der Benutzer auf einfache Weise von einem beliebigen Standort auf die Daten zugreifen kann. Ein einzelner, verteilter Datenspeicher erfordert weniger Verwaltung und muss nicht dupliziert werden. Darüber hinaus werden Verfügbarkeit und Strukturierung verbessert werden. Skalierbarkeit: Active Directory ermöglicht aufgrund der Plazierung von Domänencontrollern (dc) eine Skalierung des Verzeichnisses in Abstimmung mit Geschäfts- und Netzwerkanforderungen. V

10 1 Einleitung Erweiterungsfähigkeit: Die Struktur (Schema) in Active Directory kann erweitert werden, um angepasste Informationstypen zuzulassen. Verwaltungsfähigkeit: Active Directory basiert auf hierarchischen Organisationsstrukturen, die das Auffinden con Netzwerkressourcen erleichtert. DNS-Unterstützung: Active Directory verwendet das Domain Name System (DNS). DNS ist ein standardmaäßiger Internetdienst, der Gruppen von Computern in Dom nen hierarchisch strukturiert. Über DNS lässt sich eine Active Domänhierarchie internetweit definieren. Sie kann jedeoch auch getrennt und privat sein. Replikation von Informationen: Beim Ausfall eines Knotens innerhalb des Verzeichnissbaumes bleibt weiterhin gewährleistet, dasss ein Zugriff auf den Datenbestand auf einen anderen Server erfolgen kann. damit ist auch eine Lastverteilung gewährleistet. Ähnlich wie die Partitionnierung einer Festplatte wird auch ein teilbereich der Daten aufgeteilt und einfach auf einen anderen Server ausgelagert. Richtlinienbasierte Verwaltung: In Active Directory werden Richtlinien zur Definition der erlaubten Aktionen und Einstellungen (ACL Access Control List) für Benutzer innerhalb eines Standorts, einer Domäne oder Organisationseinheit eingesetzt. Sichere Authentifizierung und Autorisierung: Authentifizierung- und Autorisierungdienste bieten Schutz füer die Daten, da Geschäftsaufgaben über das Internet durchgefürt weden. Active Directory unterstützt verschiedene Authentifizierungsprotokolle z.b. das Kerberos 5-Protokoll.(mehr zu diesem Thema in Kapitel 4 ) Untersützung von LDAP: Active Directory basiert auf Standardprotokollen für den Verzeichniszugriff. Hierzu zählt vor allem LDAP 1 ( LDAP wird in Kapitel 2 ausführlich vorgestellt ). Da das LDAP-Protokoll für den Verzeichnisdienstzugriff ein Protokoll nach Industriestandard ist, können mit Ihm Programme entwickelt werden (Wie auch in dieser Arbeit 1 Leightweight Directory Access Protocol VI

11 1.3 Was ist ein Verzeichnisdienst zum Teil der Fall ist), welche die gemeinsame Nutzung von Active Directory- Informationen mit anderen LDAP-fähigen Verzeichnisdiensten ermöglichen. Anders gesagt verwenden Active Directory-Clients LDAP zur Kommunikation mit Computern, auf denen Active Directory ausgeführt wird, wenn sie sich beim Netzwerk anmelden oder nach freigegebenen Ressourcen suchen. Ein Auszug aus der Active Directory Daten im IFF 2 sieht wie folgt aus:. dn: CN=60400,CN=Users,DC=iffAD,DC=kfa-juelich,DC=de objectclass: top objectclass: group cn: member: CN=Jaouad Doghmi,OU=Benutzer,OU=Netzwerke und Numerik,DC=iffAD,DC=kfa -juelich,dc=de wobei dn für Distinguished Name steht. Jedes Objekt in Active Directory verfügt über einen definierten Namen (dn) mit dem das Objekt eindeutig identifiziert wird. Dieser Name enthält ausreichende Informationen, um das Objekt aus dem Verzeichnis abzurufen. Der dn umfasst den Namen der Domäne, in der das Objekt gespeichert wird, sowie den vollständigen Pfad in der Hierarchie, die zu diesem Objekt führt. der oben genannte dn beispielsweise identifiziert die Kostenstelle in der Domäne iffad.kfa-juelich.de. Diese Domäne beschreibt den Rechner auf den Active Directory ausgefürt wird. Im diesem DN-Eintrag werden die drei LDAP-Abkürzungen CN, DC und OU für die Namenattribute eingesetzt.cn (Common Name) steht für den allgemeinen Namen, DC (Domain Component) verweist auf den Namen der Domänenkomponnente und OU bezeichnet den Namen der Organisationseinheit. Weiterhin wird die Objekteklasse group benutzt um eine Gruppe von Benutzern bzw. Mitgliedern (member) zu definieren. Die Objekteklasse top wird als eine abstracte Objekteklasse bezeichnet und stellt im eigentlichen Sinne keine Objekte oder Attribute zur Verfügung, sie dient nur dazu, dass andere Objektklassen von ihr abgeleitet werden. Dieses Thema Wird wie schon erwähnt schritt für Schritt im na chsten Kapitel 3.2 beschrieben. 2 Institut für Festkörperforschung identifiziert eindeutig die Abteilung Netzwerke und Numerik VII

12 1 Einleitung Open Directory Open Directory ist der Verzeichnisdienst von Mac OS X, verwendet analog zu Active Directory LDAP, um Verzeichnisdienste für Umgebungen mit gemischten Plattformen bereitzustellen. Weiterhin bietet Open Directory eine zuverlässige Netzwerkidentifikation mit Unterstützung für die Gesamtauthentifizierung der Kerberos-Technologie. Kerberos ist ein verteilter Authentifizierungsdienst (Netzwerkprotokoll), Das sichere und einheitliche Authentifizierung in einem ungesicherten TCP/IP-Netzwerk bietet. Mehr zu Kerberos im Kapitel 4. Da Open Directory auf LDAP (siehe 3.2) basiert und die selben oben bennanten Eigenschaften von Active Directory besitzt (siehe auch 2.3.1) wird hier auf eine detaillierte Beschreibung verzichtet. Die Daten aus dem Open Directory-verzeichnis können mit dem folgenden Befehl auf einem Mac-Rechner abgefragt werden: dscl. -read /Users/doghmi Hierbei ist ein Auszug aus der Ausgabe dieses Befehls: dsattrtypenative:_writers_hint: doghmi dsattrtypenative:_writers_jpegphoto: doghmi dsattrtypenative:_writers_linkedidentity: doghmi dsattrtypenative:_writers_passwd: doghmi dsattrtypenative:_writers_picture: doghmi dsattrtypenative:_writers_realname: doghmi dsattrtypenative:_writers_usercertificate: doghmi AppleMetaNodeLocation: /Local/Default AuthenticationAuthority: ;ShadowHash; AuthenticationHint: GeneratedUID: D5C7B991-40F0-46CF-91D3-186C F NFSHomeDirectory: /Users/doghmi Password: ******** Picture: /Library/User Pictures/Sports/Baseball.tif PrimaryGroupID: 20 RealName: Jaouad Doghmi RecordName: doghmi RecordType: dsrectypestandard:users VIII

13 1.3 Was ist ein Verzeichnisdienst UniqueID: 502 UserShell: /bin/bash Die Attribute RealName,Password, RecordName, UserShell und NFSHomeDirectory beispielsweise entsprechen jeweils CN, userpassword, loginshell, loginshell und homedirectory in Active Directory. Spẗer im Lösungsansatz wird eine Datenbanktabelle erstell, deren Attribute genauso heißen wie diese Schlüsselw rter. Die Open Directory Daten werden dann entsprechend in die Datenbanktabelle überführt Network Information Service NIS - Network Information Service ist ein UNIX Verzeichnisdienst und hat die Aufgabe den Zugriff auf gemeinsame Ressourcen in einem Netzwerk zu regulieren. Dabei ist es unabdingbar auf allen Systemen gleiche User- und Group IDs zu haben, da der Zugriff durch Dritte sonst nicht ausgeschlossen werden kann. Hierzu werden die Konfigurationsdateien /etc/passwd, /etc/shadow und /etc/group, welche Informationen wie Benutzername, Gruppenzugehörigkeit, Passwort und die verwendete Shell beinhalten, vom NIS-Server verwaltet und dem Netzwerk bereitgestellt. Die Benutzer-Authentifizierung ist somit von jedem beliebigen NIS- Client möglich. Außerdem können weitere Konfigurationsdateien wie /etc/hosts oder /etc/services zum NIS-Server hinzugefügt werden, um DNS Informationen und Netzwerkdienste zentral zu verwalten. Die oben genannten Konfigurationsdateien werden auch als Master-Dateien bezeichnet und liegen im ASCII Format vor. Die Suche nach bestimmten Datensätzen in diesen Dateien wäre zuerst ineffizient. Aus diesem Grunde werden Sie als Maps abgebildet und im DBM-Format abgespeichert. Zwecks Lastreduzierung und zur Erhöhung der Ausfallsicherheit des Systems, können die Maps des Master NIS-Servers auf mehrere Slave NIS-Server verteilt werden. IX

14 1 Einleitung Die Benutzer Konfigurationsdateien Benutzerdatei: /etc/passwd Ein Auszug aus der Datei könnte wie folgt aussehen: doghmi:x:1234:20:j.doghmi:/home/doghmi:/bin/bash Die verschiedenen Attribute werden durch Doppelpunkte getrennt. Das erste Attribut gibt den Usernamen an. An der zweiten Stelle steht ein x, welches anstelle des schiffrierten Passwortes gesetzt wird, welches bei alten Systemen an dieser Stelle stand, bei neueren Systemen aus Sicherheitsgründen jedoch in die Datei /etc/shadow ausgelagert wird. Es folgen anschließend die Attribute UID, GID, Beschreibung des Benutzerkontos, Absoluter Pfad des Home Verzeichnisses und die zu verwendende Shell. Passwortdatei: /etc/shadow In dieser Datei werden die schiffrierten Passwörter der Benutzerkonten, sowie Zeitangaben bzgl. des Kennworts, wie das Ablaufdatum und der Warnungszeitraum vor Ablauf des Kennworts notiert. Gruppendatei: /etc/group In dieser Datei können User weitereren Gruppen zusätzlich zu ihrer primären Gruppe, welche in der Datei /etc/passwd definiert ist, zugeordnet werden. X

15 2 Einleitung Bevor es an die Praxis geht, gibt hier eine Einführung in die Hintergründe dieser Arbeit. 2.1 Problembeschreibung Die gemeinsame Einrichtung Netzwerke und Numerik betreibt im Institut für Festkörperforschung (IFF) im Forschungszentrum Jülich ein Netzwerk mit über 1000 Rechnern mit den Betriebssystemen Linux, Windows, Mac OS X und Tru64 Unix. Für diese Systeme werden zentrale File-, Mail-, Drucker- und Webserver mit verschiedenen Benutzerverwaltungsdiensten angeboten. Der Zugriff auf Programm-, Mess- und Simulationsdaten erfolgt aus der Sicht des Benutzers transparent. Da aber in den verschiedenen Systemen von Hause aus unterschiedliche Technologien wie Active Directory Server (Microsoft), OpenDirectory (Macintosh), LDAP(Linux) und Network Information Service (Unix) eingesetzt werden, kann es zu Inkonsistenzen in den Benutzerinformationen kommen. Diese oben benannten Technologien werden als Verzeichnisdienste bezeichnet. 2.2 Zielsetzung Dieser Umstand legt die Einführung eines Metaverzeichnisses auf der Basis einer Datenbank nahe, in der die gesamte Information zentral vorgehalten und mit den 1

16 2 Einleitung darunterliegenden Systemen abgeglichen werden kann. Durch eine solche Struktur werden - im Gegensatz zu am Markt verfügbaren Lösungen - insbesondere Abhängigkeiten von einem einzelnen System vermieden. Ziel dieser Arbeit ist der Entwurf der zu Grunde liegenden Datenbank sowie die Implementierung der nötigen Schnittstellen, damit die verschiedenen Systeme (Unix, Windows, Macintosh) über ihre nativen Verzeichnisdienste auf diese Daten zugreifen können. Hierbei werden Authentifizierungs- und Adressbuchinformationen bereitgestellt. Der Zugriff auf die Verzeichnisinformationen erfolgt über standardmäßige Internetkommunikationsprotokolle für TCP/IP-Netzwerke. Diese Protokolle vereinfachen mit möglichst geringem Aufwand die Kommunikation zwischen den verschiedenen Verzeichnisdiensten (Interoperabilität) und definieren Operationen, die zum Abfragen und Ändern von Verzeichnisinformationen verwendet werden. Es werden Programme entwickelt, die Verzeichnisdienstinformationen in die Datenbank (MYSQL-Datenbank) und umgekehrt die Datenbankinformationen in die Verzeichnisdienste überführen. Als erster Schritt und bevor man mit der Konzeption anfängt, ist es zunächst notwendig, die Verzeichnisdienste der drei Welten Linux, Windows und Macintosh vorzustellen, die in dieser Arbeit eingesetzt werden. 2.3 Was ist ein Verzeichnisdienst Ein Verzeichnisdienst ist eine im Netzwerk verteilte hierarchische Datenbank. Es gibt mehrere grundlegende Unterschiede zwischen relationalen Datenbanken und Verzeichnisdiensten. Letztere wurden hauptsächlich für das Auffinden von Daten optimiert, da Leserzugriffe wesentlich häufiger durchgeführt werden müssen, als Lesezugriffe. Im Gegensatz dazu sind Datenbanken meist schreib-/leseoptimiert. Datenbanken laufen meist auf einem einzelnen Server, dagegen können Verzeichnisdienste über mehrere Server verteilt sein. Das heißt, es können Teile der Verzeichnisstruktur oder auch Kopien des gesamten Verzeichnisses auf unterschiedlichen Servern liegen. Verzeichnisdienste sind in der Regel objektorientiert, unterstützen keine Transaktionen und es gibt auch keine Relationen. Ebenso gibt es 2

17 2.3 Was ist ein Verzeichnisdienst auch keine aufwendige (Programmier-)Sprache wie SQL bei relationalen Datenbanken. Grundsätzlich ist ein Verzeichnisdienst unabhängig vom zugrundeliegenden Betriebssystem. So wird von allen Betriebssystemherstellern ein entsprechender Dienst zur Verfügung gestellt (Active Directory von Microsoft, Open Directory von Macintosh, NIS von Linux usw.). Der Verzeichnisdienst stellt eine zentrale Informationsquelle in einer Organisation (z.b. im Forschungszentrum Jülich) dar. Innerhalb dieser Informationsquelle werden beispielsweise Informationen über die im Netzwerk vorhandenen Computer / Drucker sowie Benutzer und Gruppenkennzeichen verwaltet und den angemeldeten Benutzern Informationen zur Verfügung gestellt. Benutzer können in diesem Verzeichnisdienst nach beliebigen Attributen eines Objektes suchen. So ist es z.b. möglich nach allen Druckern zu suchen, die über spezielle Eigenschaften (beidseitiger Druck, Farboption...) verfügen Active Directory Active Directory ist der Verzeichnisdienst von Microsoft Windows 2000/ Windows Server Die in Active Directory gespeicherten Daten, Informationen über Benutzer, Gruppen, Computer und Drucker, werden in Form von Objekten organisiert. Ein Objekt ist ein individueller, benannter Attributsatz, der eine bestimmte Ressource repräsentiert. Dies kann ein Benutzer, ein Computer, ein Drucker oder andere Objekte sein. Die Eigenschaften der Objekte werden als Objektattribute bezeichnet. Die Attribute eines Benutzerkontos umfassen beispielsweise den Vor-, Nach- und Anmeldenamen des Benutzers, während die Attribute eines Computerobjektes u.a. den Computernamen und eine Beschreibung enthalten können. Jedes Objekt ist in einem Schema definiert. Das Schema ist eine Definitionsliste, die festlegt, welche Art von Objekten und welche Art von Informationen zu einem Active Directory-Objekt gespeichert werden können. Der Aufbau der Active Directory-Komponenten wird im Detail im Abschnitt 3.2 (Aufbau eines LDAP-Verzeichnisses) beschrieben, da Active Directory auf einem Standardprotokoll das sogenannte LDAP basiert. Zusätzlich bietet Active Directory folgende Eigenschaften: 3

18 2 Einleitung Zentraler Datenspeicher: Sämtliche Daten werden in einem verteilten Datenspeicher abgelegt, wodurch der Benutzer auf einfache Weise von einem beliebigen Standort auf die Daten zugreifen kann. Ein einzelner, verteilter Datenspeicher erfordert weniger Verwaltung und muss nicht dupliziert werden. Darüber hinaus werden Verfügbarkeit und Strukturierung verbessert werden. Skalierbarkeit: Active Directory ermöglicht aufgrund der Plazierung von Domänencontrollern 4 eine Skalierung des Verzeichnisses in Abstimmung mit Geschäfts- und Netzwerkanforderungen. Erweiterungsfähigkeit: Die Struktur (Schema) in Active Directory kann erweitert werden, um angepasste Informationstypen zuzulassen. Verwaltungsfähigkeit: Active Directory basiert auf hierarchischen Organisationsstrukturen, die das Management dieser Ressourcen erleichtert. DNS-Unterstützung: Active Directory verwendet das Domain Name System (DNS). DNS ist ein standardmäßiger Internetdienst, der Gruppen von Computern in Domänen hierarchisch strukturiert. Mit DNS werden auch Hostnamen IP-Adressen (z.b ) zugeordnet. Über DNS lässt sich eine Active Domänhierarchie internetweit definieren. Ein AD (Active Directory) kann auch außerhalb des öffentlichen Namensraumes existieren. Replikation von Informationen: Beim Ausfall eines Knotens innerhalb des Verzeichnissbaumes bleibt weiterhin gewährleistet, dasss ein Zugriff auf Active Directory Objekte auf einen anderen Server erfolgen kann. damit ist auch eine Lastverteilung gewährleistet. Richtlinienbasierte Verwaltung: In Active Directory werden Richtlinien zur Definition der erlaubten Aktionen und Einstellungen (ACL Access Control List) für Benutzer und Gruppen innerhalb eines Standorts, einer Domäne oder Organisationseinheit eingesetzt. Sichere Authentifizierung und Autorisierung: Authentifizierungs- und Autorisierungsdienste bieten Schutz füer die Daten, da Geschäftsaufgaben 4 Ein Domäncontroller beschreibt den Rechner auf den Active Directory ausgeführt wird 4

19 2.3 Was ist ein Verzeichnisdienst über das Internet durchgeführt weden. Active Directory unterstützt verschiedene Authentifizierungsprotokolle z.b. das Kerberos 5-Protokoll.(mehr zu diesem Thema in Kapitel 4 ) Untersützung von LDAP: Active Directory basiert auf Standardprotokollen für den Verzeichniszugriff. Hierzu zählt vor allem LDAP 5 ( LDAP wird in Kapitel 2 ausführlich vorgestellt ). Da das LDAP-Protokoll für den Verzeichnisdienstzugriff ein Protokoll nach Industriestandard ist (RFC ), können mit ihm Programme entwickelt werden (wie auch in dieser Arbeit zum Teil der Fall ist), welche die gemeinsame Nutzung von Active Directory-Informationen mit anderen LDAP-fähigen Verzeichnisdiensten ermöglichen. Anders gesagt verwenden Active Directory-Clients LDAP zur Kommunikation mit Domaincontrollern, wenn sie sich beim Netzwerk anmelden oder nach freigegebenen Ressourcen suchen. Ein Benutzerobjekt aus den Active Directory Daten im Institut für Festkörperforschung (IFF) sieht wie folgt aus: dn: CN=60400,CN=Users,DC=iffAD,DC=kfa-juelich,DC=de objectclass: top objectclass: group cn: member: CN=Jaouad Doghmi,OU=Benutzer,OU=Netzwerke und Numerik,DC=iffAD,DC=kfa -juelich,dc=de wobei dn für Distinguished Name steht. Jedes Objekt in Active Directory verfügt über einen definierten Namen (dn), mit dem das Objekt eindeutig identifiziert wird. Dieser Name enthält ausreichende Informationen, um das Objekt aus dem Verzeichnis abzurufen. Der dn umfasst den Namen der Domäne, in der das Objekt gespeichert wird, sowie den vollständigen Pfad in der Hierarchie, die zu diesem Objekt führt. Der oben genannte dn beispielsweise identifiziert das Objekt für die Kostenstelle in der Domäne iffad.kfa-juelich.de. Diese Domäne beschreibt den Rechner, auf dem Active Directory ausgefürt wird. Im diesem DN-Eintrag werden die drei LDAP-Abkürzungen CN, DC und OU 5 Lightweight Directory Access Protocol 6 RFC Requests for Comments sind eine Reihe von technischen und organisatorischen Dokumenten zum Internet identifiziert eindeutig die Abteilung Netzwerke und Numerik 5

20 2 Einleitung für die Namenattribute eingesetzt. CN (Common Name) steht für den allgemeinen Namen, DC (Domain Component) verweist auf den Namen der Domänenkomponente und OU bezeichnet den Namen der Organisationseinheit. Weiterhin wird die Objektklasse group benutzt, um eine Gruppe von Benutzern bzw. Mitgliedern (member) zu definieren. Die Objektklasse top wird als eine abstrakte Objektklasse bezeichnet und stellt im eigentlichen Sinne keine Objekte oder Attribute zur Verfügung, sie dient nur dazu, dass andere Objektklassen von ihr abgeleitet werden. Dieses Thema wird wie schon erwähnt Schritt für Schritt im na chsten Kapitel 3.2 beschrieben. (siehe auch Literatur?) Open Directory Open Directory ist der Verzeichnisdienst von Mac OS X und verwendet analog zu Active Directory LDAP, um Verzeichnisdienste für Umgebungen mit gemischten Plattformen bereitzustellen. Weiterhin bietet Open Directory eine zuverlässige Netzwerkidentifikation mit Unterstützung für die Gesamtauthentifizierung der Kerberos-Technologie. Kerberos ist ein verteilter Authentifizierungsdienst (Netzwerkprotokoll), das sichere und einheitliche Authentifizierung in einem ungesicherten TCP/IP-Netzwerk bietet. Mehr zu Kerberos im Kapitel 4. Da Open Directory auf LDAP (siehe 3.2) basiert und die selben oben bennanten Eigenschaften von Active Directory besitzt (siehe auch 2.3.1) wird hier auf eine detaillierte Beschreibung verzichtet. Die Daten aus dem Open Directory-Verzeichnis können mit dem folgenden Befehl auf einem Mac-Rechner abgefragt werden: doghmi@iffmac:~% dscl. -read /Users/doghmi Hier ist ein Auszug aus der Ausgabe dieses Befehls: dsattrtypenative:_writers_hint: doghmi dsattrtypenative:_writers_jpegphoto: doghmi dsattrtypenative:_writers_linkedidentity: doghmi dsattrtypenative:_writers_passwd: doghmi dsattrtypenative:_writers_picture: doghmi dsattrtypenative:_writers_realname: doghmi dsattrtypenative:_writers_usercertificate: doghmi 6

21 2.3 Was ist ein Verzeichnisdienst AppleMetaNodeLocation: /Local/Default AuthenticationAuthority: ;ShadowHash; AuthenticationHint: GeneratedUID: D5C7B991-40F0-46CF-91D3-186C F NFSHomeDirectory: /Users/doghmi Password: ******** Picture: /Library/User Pictures/Sports/Baseball.tif PrimaryGroupID: 20 RealName: Jaouad Doghmi RecordName: doghmi RecordType: dsrectypestandard:users UniqueID: 502 UserShell: /bin/bash Die Attribute RealName,Password, RecordName, UserShell und NFSHomeDirectory entsprechen beispielsweise jeweils CN, userpassword, loginshell, loginshell und homedirectory in Active Directory. Später im Lösungsansatz wird eine Datenbanktabelle erstell, deren Attribute genauso heißen wie diese Schlüsselwörter. Die Open Directory Daten werden dann entsprechend in die Datenbanktabelle überführt Network Information Service NIS - Network Information Service ist ein UNIX Verzeichnisdienst und hat die Aufgabe, den Zugriff auf gemeinsame Ressourcen in einem Netzwerk zu regulieren. Dabei ist es unabdingbar auf allen Systemen gleiche User- und Group IDs zu haben, da der Zugriff durch Dritte sonst nicht ausgeschlossen werden kann. Hierzu werden die Konfigurationsdateien /etc/passwd, /etc/shadow und /etc/group, welche Informationen wie Benutzername, Gruppenzugehörigkeit, Passwort und die verwendete Shell beinhalten, vom NIS-Server verwaltet und dem Netzwerk bereitgestellt. Die Benutzer-Authentifizierung ist somit von jedem beliebigen NIS- Client möglich. Außerdem können weitere Konfigurationsdateien wie /etc/hosts oder /etc/services zum NIS-Server hinzugefügt werden, um DNS Informationen und Netzwerkdienste zentral zu verwalten. 7

22 2 Einleitung Die oben genannten Konfigurationsdateien werden auch als Master-Dateien bezeichnet und liegen im ASCII Format vor. Die Suche nach bestimmten Datensätzen in diesen Dateien wäre ineffizient. Aus diesem Grunde werden Sie als Maps abgebildet und im DBM-Format abgespeichert. Zwecks Lastreduzierung und zur Erhöhung der Ausfallsicherheit des Systems können die Maps des Master NIS-Servers auf mehrere Slave NIS-Server verteilt werden. Die Benutzer Konfigurationsdateien sind: Benutzerdatei: /etc/passwd Ein Auszug aus der Datei könnte wie folgt aussehen: doghmi:x:1234:20:j.doghmi:/home/doghmi:/bin/bash Die verschiedenen Attribute werden durch Doppelpunkte getrennt. Das erste Attribut gibt den Usernamen an. An der zweiten Stelle steht ein x, welches anstelle des schiffrierten Passwortes gesetzt wird, welches bei alten Systemen an dieser Stelle stand, bei neueren Systemen aus Sicherheitsgründen jedoch in die Datei /etc/shadow ausgelagert wird. Es folgen anschließend die Attribute UID, GID, Beschreibung des Benutzerkontos, Absoluter Pfad des Home Verzeichnisses und die zu verwendende Shell. Passwortdatei: /etc/shadow In dieser Datei werden die chiffrierten Passwörter der Benutzerkonten, sowie Zeitangaben bzgl. des Kennworts (wie Ablaufdatum und Warnungszeitraum vor Ablauf des Kennworts) notiert. Gruppendatei: /etc/group In dieser Datei können User weiteren Gruppen zusätzlich zu ihrer primären Gruppe, welche in der Datei /etc/passwd definiert ist, zugeordnet werden. 8

23 3 LDAP und OpenLDAP In diesem Kapitel werden einige wichtige Grundlagen zusammengestellt, die für das weitere Verständnis der Funktionsweise von Verzeichnissen und Verzeichnissdiensten vorauszusetzen sind. Begonnen wird mit dem Aufbau des LDAP- Verzeichnis und anschliessend werden die wichtigen Operationen vorgestellt, die von einem konkreten Verzeichnisdienst (OpenLDAP) angeboten werden. 3.1 Einführung LDAP ist die Abkürzung für Lightweight Directory Access Protocol und ist ein Anwendungsprotokoll, das es ermöglicht, Informationen eines Verzeichnisdienstes, über das TCP/IP-Netzwerk, abzufragen und zu modifizieren. LDAP ist ein offener Standard, der auch in der zukünftigen Softwareentwicklung von großer Bedeutung sein wird. Programme werden in der Lage sein, LDAP- Datenbanken zu benutzen, um Informationen zu erlangen und zu hinterlegen. 3.2 Aufbau eines LDAP-Verzeichnisses Das Klassenmerkmal von Verzeichnisdiensten ist ihre Baumstruktur (siehe Abbildung 2.1). Der Baum wird als Directory Information Tree (DIT) bezeichnet. Es gibt immer einen Ausgangpunkt (oft Wurzel (root) genannt) von dem aus alle anderen Knoten im Baum erreichbar sind. Eine Wurzel ist der einzige Knoten in einem Baum welcher keinen Vorgänger hat. Datenstrukturen, die innerhalb eines LDAP-Verzeichnisses abgelegt werden heißen Entry und beschreiben eindeutig ein Objekt. Im Gegensatz zu einem 9

24 3 LDAP und OpenLDAP natürlichen Baum hat jede Verzweigung (DN= Distinguished Name ) im LDAP- Verzeichnis mindestens ein einzigartiges Attribut, durch welches sie sich von anderen Verzweigungen unterscheidet. Der folgende dn-eintrag: dn: uid=doghmi, ou=netzwerke und Numerik, o=iff, o=fz-juelich repräsentiert den Benutzer doghmi in der Organisationseinheit (organisationalunit) Netzwerke und Numerik in der Organisation IFF im Forschungszentrum Jülich. Abbildung 3.1: LDAP-Baumstruktur DNs werden vom Blatt zur Wurzel gelesen. Jeder Eintrag (engl. Entry) in einem LDAP-Directory wird durch seinen dn identifiziert, das eindeutig ein Objekt beschreibt, also eine konkrete Instanz einer Objektklasse. Eine Objektklasse ist eine verallgemeinerte Beschreibung für die Objekte. Jede Objektklasse ist in einem sogenannten LDAP-Schema definiert und verfügt über eine Liste der zwingend vorgeschriebenen (MUST) und der optionalen (MAY) Attribute. Jedes Objekt kann eines oder mehrere Attribute haben, wie der folgende Eintrag zeigt: 10

25 3.2 Aufbau eines LDAP-Verzeichnisses dn: uid=doghmi,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de cn: Jaouad Doghmi objectclass: top objectclass: inetorgperson objectclass: posixaccount objectclass: shadowaccount loginshell: /usr/local/bin/tcsh userpassword: verschlüsseltes Passwort uidnumber: gidnumber: 20 sn: Doghmi homedirectory: /usr/users/iff_ge/doghmi mail: givenname: Jaouad uid: doghmi Die Objektklasse inetorgperson definiert für den Benutzer doghmi Internet-Attribute, so wie z.b. die Mail-Adresse, Telefonnummer usw., während die Objektklasse posixaccount Unix-Attribute definiert (z.b. uidnumber, gidnumber usw). sn, cn und dc stehen jeweils für den Nachnamen (surname), den kompleten Namen (common name) und die Domainkomponente (domain component) Die Schema-dateien sind unter /etc/openldap/schema zu finden. Die Objektklasse posixaccount ist z.b. in der Schema-datei nis.schema wie folgt definiert: objectclass ( NAME posixaccount DESC Abstraction of an account with POSIX attributes SUP top AUXILIARY MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) Analog dazu ist die Objektklasse inetorgperson in inetorgperson.schema wie folgt definiert objectclass ( NAME inetorgperson DESC RFC2798: Internet Organizational Person 11

26 3 LDAP und OpenLDAP ) SUP organizationalperson STRUCTURAL MAY ( audio $ businesscategory $ carlicense $ departmentnumber $ displayname $ employeenumber $ employeetype $ givenname $ homephone $ homepostaladdress $ initials $ jpegphoto $ labeleduri $ mail $ manager $ mobile $ o $ pager $ photo $ roomnumber $ secretary $ uid $ usercertificate $ x500uniqueidentifier $ preferredlanguage $ usersmimecertificate $ userpkcs12 ) 3.3 LDAP-Server Es gibt heutzutage eine Reihe von LDAP-Servern auf dem Markt, von denen die meisten unter Linux benutzt werden können (z.b. Fedora Directory Server). Für diese Arbeit wird OpenLDAP verwendet. OpenLDAP ist eine Implementation des LDAP als freie Software und ist Bestandteil der meisten aktuellen Linux- Distributionen. Es läuft auch unter Mac OS X und verschiedenen Windows- Versionen. 3.4 Installation von OpenLDAP Wie bereits erwähnt ist OpenLDAP ein Bestandteil der meisten Linux Distributionen. Unter Fedora werden die benötigten Packete mit dem Paketmanager yum wie folgt installiert: [root@iffldap ~]# yum install -y openldap-servers openldap-clients 3.5 Konfiguration und Aufsetzen von OpenLDAP Nach der Installation der Pakete müssen folgende Konfigurationsdateien editiert und an das System angepasst werden: 12

27 3.5 Konfiguration und Aufsetzen von OpenLDAP /etc/openldap/slapd.conf : Diese Datei ist die wichtigste Konfigurationsdatei des LDAP-Servers und ist der zentrale Ort, an dem sich alle elementaren Einstellungen des LDAP- Servers befinden. Nun zu den vier Direktiven der slapd.conf, die für ein minimales Setup benötigt werden und entsprechend gesetzt werden müssen: Die database-direktive bestimmt, welche Datenbank für den LDAP-Server dient. Als Datenbank wird üblicherweise bdb (Berkeley Database) benutzt: database bdb Die suffix-direktive dient der Definition des höchsten Punktes Base-DN, das sogennante TLD (Top Level Domain), im DIT 8, von dem alle Verzweigungen ausgehen: suffix "o=fz-juelich,dc=fz-juelich,dc=de" Die rootdn-direktive dient der Definition des eindeutigen Eintrag DN für einen Benutzer, dem von den Parametern der Zugangskontrolle oder Benutzerverwaltung keine Beschränkungen für die Verwaltung des LDAP- Verzeichnisses auferlegt sind. Der Benutzer rootdn ist sozusagen Root für das LDAP-Verzeichnis. Hierbei wird nicht ein SystemAccount verwendet, sondern ein separater Account mit Rolle Root (OrganizationalRole): rootdn "cn=root,o=fz-juelich,dc=fz-juelich,dc=de" Die rootpw-direktive dient der Definition des Passworts für den Adminstrator des LDAP-Server rootdn. rootpw {SSHA}jFfry2WS/nAQbCOZCyyclfJV0YMqv5Tz Um ein verschlüsseltes Passwort zu erzeugen, wird der folgende Befehl ausgeführt: [root@iffldap ~]# slappasswd 8 Directory Information Tree 13

28 3 LDAP und OpenLDAP slappasswd bzw. /usr/sbin/slappasswd ist ein Programm, das Passwörter mit verschiedenen Verschlüsselungsverfahren generiert, unter anderem CRYPT, MD5, SHA und SSHA. Mit der Option -h kann man das bevorzugte Verschlüsselungsverfahren wählen. Gibt man nicht an, mit welcher Methode das Passwort generiert wird, wird das Passwort standardmässig mit dem SSHA-verfahren generiert. Man wird dann aufgefordert, ein Passwort einzugeben und durch eine zweite Eingabe zu bestätigen. Danach gibt das Programm das verschlüsselte Passwort am Terminal aus. Als nächstes kopiert man das neu erzeugte verschlüsselte Passwort in die Datei /etc/openldap/slapd.conf in die rootpw- Zeile. Zusätzlich kann man den anonymen Zugriff mit Hilfe der access-directive auf den Server verbieten. Per Default darf nur der rootdn schreibend zugreifen. Durch die folgende access-direktive dürfen nur die Benutzer mit IFF IP-Adressen (acht Bereiche von 0 bis 7) lesend auf die LDAP-Datenbank zugreifen. Die externen Benutzer dürfen weder schreiben noch lesen: access to * by self write by peername.regex="^ip=134\.94\.16[0-7]\..+" read by * none Sucht man in einem umfangreichen LDAP-Verzeichnis (DIT) nach bestimmten Objekten (je nach Suchkriterium), dann liegt per Default die Obergrenze der Anzahl der gefundenen Einträge bei 500. Dieser Wert kann über den Parmeter sizelimit geändert werden. sizelimit unlimited /etc/openldap/ldap.conf : Diese Datei ist die zweitwichtigste Datei des LDAP-Servers und dient zur Konfiguration von systemweiten Einstellungen für Clients. Hierbei müssen die parameter HOST und BASE gesetzt werden: HOST iffldap.iff.kfa-juelich.de BASE BASE o=fz-juelich,dc=fz-juelich,dc=de 14

29 3.6 Erster Import: LDAP-Datenbank initialisieren HOST definiert den Rechner, auf dem LDAP läuft. BASE definiert die Suchbasis, ab der der Client suchen darf. /etc/hosts.allow : Es müssen lokale Verbindungen über den TCP-Wrapper entgegengenommen werden. Hierzu werden folgende Zeilen in der Datei /etc/hosts.allow eingefügt: ALL: localhost ALL: Danach muss der Netzwerk Service wie folgt neugestartet werden: [root@iff018 ~]# service network restart Abschließend wird noch die Datenbankkonfigurationsdatei kopiert und den LDAP Service gestartet. [root@iffldap ~]# cp -p /etc/openldap/db_config.example\ /var/lib/ldap/db_config [root@iffldap ~]# /etc/init.d/ldap start Nach Änderung oder Erweiterung der Konfigurationsdateien muss der LD- AP-Service immer neu gestartet werden. 3.6 Erster Import: LDAP-Datenbank initialisieren OpenLDAP unterstützt den Import von Daten über das LDAP Data Interchange Format (LDIF). Jeder neue Datensatz beginnt in diesem Format mit dem distinguished name (dn), also dem absoluten Pfad innerhalb des LDAP Baumes. Im Anschluss daran können beliebige - im Schema vorhandene - Attribute und Werte importiert werden. Hierzu legen wir eine Datei base.ldif an: dn: o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: fz-juelich 15

30 3 LDAP und OpenLDAP description: Forschungszentrum Juelich dn: o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: IFF description: Institut fuer Festkoerperforschung dn: ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organizationalunit ou: People description: Alle Mitarbeiter vom IFF Diese Datei wird dann wie folgt in die LDAP-Datenbank importiert: ~]# ldapadd -x \ -D "cn=root,o=fz-juelich,dc=fz-juelich,dc=de" -W -f base.ldif OpenLDAP stellt eine Reihe von nützlichen Befehlen zur Verfügung. Diese werden in den nächsten Abschnitten genauer unter die Lupe genommen. 3.7 Benutzerverwaltung Nach der Initialisierung der LDAP-Datenbank, können wir bereits existierende bzw. neue UNIX-Accounts nach LDAP migrieren. Es sollten zuerst die default Einstellungen für die Übernahme bereits existierender Benutzerkonten geändert werden. Hierzu wird die Datei /usr/share/openldap/migration/migrate_common.ph editiert: # Default DNS domain $DEFAULT_MAIL_DOMAIN = "fz-juelich.de"; # Default base $DEFAULT_BASE = "o=fz-juelich, dc=fz-juelich, dc=de"; 16

31 3.7 Benutzerverwaltung Anschließend wird einen neuen UNIX-User angelegt. ~]# useradd mustermann ~]# passwd mustermann Den neu angelegten UNIX-User werden nun nach LDAP migriert. (Es können selbstverständlich auch bereits existierende UNIX-Accounts nach LD- AP migriert werden) Hierzu muss die Datei passwd.mustermann erzeugt werden, die anschließend zu einer mustermann.ldif konvertiert: ~]# grep mustermann /etc/passwd > /etc/openldap/passwd.mustermann ~]# /usr/share/openldap/migration/migrate_passwd.pl \ passwd.mustermann > mustermann.ldif Die nun erzeugte mustermann.ldif Datei kann man noch editieren. Ein neue Objektklasse namens inetorgperson wird hinzugefügt und dafür die Klasse account entfernt, da diese von inetorgperson abgeleitet ist. Anschließend ergänzen wir die Angaben durch cn: {vollständiger Name}, sn: {Nachname} und mail: { adresse}. Die so erzeugte Datei könnte folgendermaßen aussehen: dn: uid=mustermann,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de uid: mustermann cn: Max Mustermann sn: Mustermann mail: m.mustermann@fz-juelich.de objectclass: inetorgperson objectclass: posixaccount objectclass: top objectclass: shadowaccount userpassword: {crypt}verschlüsseltes Passwort shadowlastchange: shadowmax: shadowwarning: 7 loginshell: /bin/bash uidnumber:

32 3 LDAP und OpenLDAP gidnumber: 500 homedirectory: /home/mustermann Der Eintrag muss nun wieder in die LDAP-Datenbank importiert werden: ~]# ldapadd -x \ -D "cn=root,o=fz-juelich,dc=fz-juelich,dc=de" -W -f mustermann.ldif 3.8 Benutzeranmeldung Um sich als Client am Server anmelden zu können, müssen noch die Konfigurationsdateien /etc/ldap.conf und /etc/nsswitch.conf beim Client angepasst werden. /etc/ldap.conf host base iffldap.iff.kfa-juelich.de "o=fz-juelich,dc=fz-juelich,dc=de" /etc/nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap Die Konfiguration des Clients ist hiermit abgeschlossen. Es wird nun zuerst geprüft, ob ein User lokal (in /etc/passwd) existiert, ansonsten wird der LDAP Verzeichnisserver für die Benutzeranmeldung benutzt. Mit den Befehlen getent passwd mustermann und id mustermann lässt sich überprüfen, ob alles funktioniert: -bash-3.1# getent passwd doghmi doghmi:x:1234:20:jaouad Doghmi:/usr/users/iff_ge/doghmi:/usr/local/bin/tcsh -bash-3.1# id doghmi uid=1234(doghmi) gid=20(games) groups=20(games) 18

33 3.9 Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete 3.9 Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete OpenLDAP bietet nützliche Programme an, die zum Suchen, Modifizieren und Löschen von Einträgen dienen. ldapadd, ldapsearch, ldapmodify und ldapdelete haben gegenüber grafischen Tools den Vorteil, dass sie einfach in Konfigurationsskripten oder Startskripten unter Linux eingefügt werden können und somit in diesen Skripten auf eine LDAP Datenbank zugegriffen werden kann ldapsearch Nach dem erfolgreichen ersten Import von Ldif-Dateien bzw. Einträgen, können wir das Ergebnis mittels ldapsearch überprüfen, oder graphische Werkzeuge (z.b. phpldapadmin siehe Abschnitt ) verwenden: [root@iffldap ~]# ldapsearch -x Die Ausgabe des obigen Befehls sieht dann wie folgt aus: # # LDAPv3 # base <> with scope subtree # filter: (objectclass=*) # requesting: ALL # # fz-juelich, fz-juelich.de dn: o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: fz-juelich description: Forschungszentrum Juelich # iff, fz-juelich, fz-juelich.de 19

34 3 LDAP und OpenLDAP dn: o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: IFF description: Institut fuer Festkoerperforschung # people, iff, fz-juelich, fz-juelich.de dn: ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organizationalunit ou: People description: Alle Mitarbeiter vom IFF # search result search: 2 result: 0 Success # numresponses: 4 # numentries: 3 Alternativ dazu kann man auch den Parameter objectclass=* benutzen, um alle im DIT befindlichen Objekte anzuzeigen. Durch den ergänzenden Parameter -LLL werden gezielt nur die Einträge (z.b. ohne Kommentare ) ausgegeben. [root@iffldap ~]# ldapsearch -x -LLL objectclass=* dn: o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: fz-juelich description: Forschungszentrum Juelich dn: o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organization o: IFF 20

35 3.9 Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete description: Institut fuer Festkoerperforschung dn: ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organizationalunit ou: People description: Alle Mitarbeiter vom IFF Möchte man gezielt nach einem bestimmten Objekt oder Attribut im DIT suchen, kann man das explizit in der Befehlszeile angeben. Im folgenden Beispiel wird nach der Mail adresse von Mustermann gesucht. ~]# ldapsearch -x -LLL sn=mustermann mail dn: uid=mustermann,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de mail: Es besteht die Möglichkeit, die Suche auf bestimmte Bereiche und Objekte des DIT einzuschränken (Suchfilter). Hierfür steht die Option -s zur Verfügung. Diese kann die Werte base, one und sub annehmen: sub: Es wird nur innerhalb der base-dn gesucht und nicht unterhalb. Der folgende Befehl liefert nichts zurück, obwohl der Benutzer Mustermann im DIT exisitiert (aber nicht in der base-dn): ~]# ldapsearch -x -LLL sn=mustermann -s base one: Es wird innerhalb der base-dn und nur eine Ebene unterhalb der basedn gesucht. sub: Es wird im kompletten Baum gesucht. Diese Option gilt per Default, wenn nichts angegeben wird. Anderseits stehen auch Filterverknüpfungen zur Verfügung. Damit sind logische UND-,ODER und NICHT-Verknüpfungen gemeint: UND-Verknüpfung: ( & (filter1) (filter2)... (filtern) ) Der folgende Befehl findet alle User-Objekte im DIT, die die bash-shell als loginshell haben. [root@iffldap ~]# ldapsearch -x -LLL "(& (uid=*) (loginshell=/bin/bash))" 21

36 3 LDAP und OpenLDAP ODER-Verknüpfung: ( (filter1) (filter2)... (filtern) ) Der folgende Befehl findet alle DN-Einträge, deren sn-attribut doghmi oder mustermann ist: [root@iffldap ~]# ldapsearch -x -LLL "( (sn=doghmi) (sn=mustermann) )" NICHT-Verknüpfung: (! (filter) ) Der folgende Befehl findet alle DN-Einträge, deren sn-attribut nicht doghmi ist: [root@iffldap ~]# ldapsearch -x -LLL "(! (sn=doghmi) )" Mehrere Informationen über ldapsearch findet man in der Manpage mit man ldapsearch ldapmodify Möchte man z.b. eine kurze Beschreibung description für den Benutzer doghmi im DIT einfügen, dann wird zunächst sein dn-eintrag in eine Datei gespeichert: [root@iffldap ~]# ldapsearch -x -LLL uid=doghmi > user.ldif mit der folgenden Beschreibung ergänzt: description: Mitarbeiter in der Abteilung Netzwerke und Numerik und dann wieder in den DIT eingefügt: [root@iffldap ~]# ldapmodify -x \ -W -D "uid=doghmi,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de" -f user.ldif Mehrere Informationen über ldapmodify findet man in der Manpage mit man ldapmodify. 22

37 3.9 Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete ldapdelete Dieses Programm dient zum Löschen vorhandener DN-Einträge: ~]# ldapmodify -x -D "cn=root,o=fz-juelich,dc=fz-juelich,dc=de" \ -W "uid=mustermann,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de" Der obige Befehl löscht den Eintrag mustermann vom DIT. Der zu löschende DN- Eintrag soll komplett hinter der Option -W angegeben werden. Mehrere Informationen über ldapdelete findet man in der Manpage mit man ldapdelete Webinterface - phpldapadmin Der OpenLDAP-Server kann auch über ein Webinterface verwaltet werden. Hierzu wurde phpldapadmin installiert. Dies setzte vorraus, dass ein Apache Server mit PHP5 (+ LDAP Unterstützung) installiert ist. Eine aktuelle Version von phpldapadmin kann man von herunterladen und in das html- Verzeichnis von apache (z.b.: /var/www/html/) entpacken. Anschließend wird eine Konfigurationsdatei im Unterverzeichnis config erstellt: [root@iffldap config]# cp -p config.php.example config.php welche im Anschluss noch editiert werden muss. Zusätzlich werden nachfolgende Änderungen vorgenommen: $servers = array( name => IFFLDAP - Linux Open LDAP, host => iffldap.iff.kfa-juelich.de, base => o=fz-juelich,dc=fz-juelich,dc=de, dn => cn=root,o=fz-juelich,dc=fz-juelich,dc=de )); $ldapservers->setvalue($i, server, name, $servers[ name ]); $ldapservers->setvalue($i, server, host,$servers[ host ]); $ldapservers->setvalue($i, server, base,$servers[ base ]); 23

38 3 LDAP und OpenLDAP $ldapservers->setvalue($i, server, auth_type, session ); $ldapservers->setvalue($i, login, dn, $servers[ dn ]); 24

39 3.9 Wichtige LDAP-Programme: ldapsearch, ldapmodify, ldapdelete Das phpldapadmin-webinterface sieht dann wie folgt aus: Abbildung 3.2: Webinterface phpldapadmin 25

40 4 Kerberos 4 Kerberos Authentifizierungdienste bieten Schutz für Daten, wenn vertrauliche Tätigkeiten (z.b. Bankgeschäfte ) über das Internet durchgeführt werden. In diesem Kapitel wird ein von vielen Verzeichnissdiensten unterstütztes Authentifizierungprotokoll namens Kerberos vorgestellt. 4.1 Einführung Kerberos ist ein Authentifizierungsdienst, der sichere und einheitliche ticket-basierte Authentifizierung in einem ungesicherten TCP/IP-Netzwerk auf sicheren Hostrechnern bietet. Die Authentifizierung übernimmt eine vertrauenswürdige dritte Partei. Diese dritte Partei ist ein besonders geschützter Kerberos-5-Netzwerkdienst. Kerberos unterstützt Single Sign On, das heißt ein Benutzer muss sich nur ein mal anmelden, und kann alle Netzwerkdienste nutzen, ohne ein weiteres Mal ein Passwort eingeben zu müssen. Der Kerberos sollte aus Sicherheitsgründen nur auf einem Server laufen, auf dem keine weiteren Dienste installiert sind, da diese Intrusions-Möglichkeiten bieten können. Das Ziel ist, Kerberos als primären Authentifizierungsdienst einzurichten. Danach wird verschlüsselt auf die LDAP-Daten zugegriffen (auch kerberisierter Zugriff genannt). Der eigentliche Kerberos-Server wird als KDC (Key Distribution Center) bezeichnet und besteht aus zwei Teilen, dem TGS (Ticket Granting Server) und dem AS (Authentification Server). Dieser nimmt die erste Ticketanfrage des Clients entgegen und erstellt das TGT (Ticket Granting Ticket). Der TGS (Ticket Granting Server) stellt dem Client nach Vorlage des TGT die SGT Service Granting Tickets für den vom Client angeforderten Service z.b. LD- AP aus (siehe auch die Abbildung 4.1). Zwei weitere wichtige Begriffe in der Kerberos-Terminologie sind Principal und 26

41 4.1 Einführung Realm. Ein Principal kann ein Benutzer, ein Host oder ein Dienst sein. Die eindeutigen Principals werden in in der Kerberos-Datenbank verwaltet und besitzen folgende Struktur: Der erste Teil "mustermann" (auch primary genannt) definiert den Benutzer-, Host- oder Dienstnamen, der zweite Teil "admin" (auch instance genannt) die Rolle von mustermann und der dritte Teil den sogenannten Realm (bedeutet übersetzt Bereich). Realm entspricht in der Regel dem Domänennamen in Großbuchstaben. Jeder Realm besitzt einen eigenen AS und TGS. Abbildung 4.1: Vereinfachte Darstellung einer Kerberos-Authentifizierung? Mehr zum Thema Kerberos siehe Literatur?. 27

42 4.2 Funktionsprinzip Aufbau eines Metaverzeichnisses 4 Kerberos Die prinzipielle Funktionsweise der Authentifizierung eines Principal (Benutzer, Host oder Dienst) lässt sich wie folgt beschreiben: Der Principal gibt seinen Benutzernamen zur Authentifizierung ein, der über das Netzwerk zum Kerberos- Server KDC geht. Der Principal und sein Passwort sind dem Authentification Server AS bekannt (potentielles Sicherheitsproblem). Dieser generiert einen SessionKey 9, der nur während der aktuellen Sitzung (Session) gültig ist und erstellt ein Ticket, das für den TGS bestimmt ist. Dieses Ticket wird ebenfalls mit einem Session Key verschlüsselt, der nur der TGS und der AS bekannt ist. Danach wird das Ticket (mit dem Session Key) mit einem Schlüssel codiert, der von Benutzer- bzw. Principalpasswort abgeleitet ist und vom AS zurück an den Principal gesendet. Danach gibt der Principal sein Passwort ein, das in einen Schlüssel konvertiert wird, der das vom AS an den Principal gesendete Packet decodiert. Nach der Decodierung des Packets werden Schlüssel und Passwort aus dem RAM gelöscht (Angreifer haben dann keine Möglichkeit, die Passwörter auszulesen). Der Principal besitzt nun ein TGT Ticket. Um den kerberesierten LD- AP-Dienst zu nutzen, generiert der LDAP-Client einen sogenannten Authenticator, der die Identität des LDAP-Dienstes überprüft und fragt den TGS, unter Vorlage des TGT, nach einem Ticket SGT (Service Granting Ticket) für den gewünschten LDAP-Dienst. Der LDAP-Client legt das vom TGT erstellte SGT zusammen mit dem Authenticator dem LDAP-Server vor. Daraufhin erhält der LDAP-Client die Ermächtigung, den LDAP-Dienst zu nutzen. (siehe auch Abbildung 4.1). 9 Temporärer Schlüssel zur Verschlüsselung der Kommunikation zwischen Server (TGS) und Client (Principal) 28

43 4.3 Konfiguration und Start 4.3 Konfiguration und Start Kerberos ist ein Teil des LDAP-Packets, also muss man nicht zusätzlich Kerberos installieren. Als nächsten Schritt müssen die Konfigurationsdateien ("*.conf") editiert und angepasst werden: "krb5.conf": Die Datei "/etc/krb5.conf" beeinhaltet Informationen über den Kerberos-Realm, in dem sich der Client befindet. Neben Informationen über den Namen (und die damit verbundenene IP-Adresse), findet man noch Daten über die Verschlüsselungsarten und Ticketlebenszeiten: #Auszug von krb5.conf: iffldap.iff.kfa-juelich.de = { kdc = iffldap.iff.kfa-juelich.de:88 admin_server = iffldap.iff.kfa-juelich.de:749 default_domain = iffldap.iff.kfa-juelich.de } [domain_realm].iffldap.iff.kfa-juelich.de = iffldap.iff.kfa-juelich.de iffldap.iff.kfa-juelich.de = iffldap.iff.kfa-juelich.de [appdefaults] pam = { } debug = false ticket_lifetime = renew_lifetime = forwardable = true krb4_convert = false "/var/kerberos/krb5kdc/kdc.conf": In dieser Datei steht alles, was der Dienst KDC wissen muss, um seine Daten abzulegen und diese auch wieder zu finden. Auch hier werden wieder Informationen abgelegt, die die Ticketlebenszeit bestimmen: #kdc.conf [kdcdefaults] kdc_ports = 750,88 [realms] 29

44 4 Kerberos } #ATHENA.MIT.EDU = { iffdap.iff.kfa-juelich.de = { database_name = /usr/local/var/krb5kdc/principal admin_keytab = FILE:/var/kerberos/krb5kdc/kadm5.keytab acl_file = /usr/local/var/krb5kdc/kadm5.acl key_stash_file = /usr/local/var/krb5kdc/.k5.iffldap.iff.kfa-juelich.de kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s Als nächstes muss die Kerberos-Datenbank für den Realm "IFFLDAP.IFF.KFA-JUELICH.DE" initialisiert werden. Dort sind die Secret Keys (Master key: Passworteingabe des Principal) in verschlüsselter Form, die zugehörigen Principals und zusätzliche Informationen abgelegt. Der KDC wird diese Daten benutzen, um später Tickets auszustellen und die Identität zu prüfen: [root@iffldap ~]/usr/kerberos/sbin/kdb5_util create \ -r IFFLDAP.IFF.KFA-JUELICH.DE -s Die Ausgabe dieses Befehls sieht dann wie folgt aus: Initializing database /usr/local/var/krb5kdc/principal \ for realm IFFLDAP.IFF.KFA-JUELICH.DE, master key name K/M@IFFLDAP.IFF.KFA-JUELICH.DE You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: *********** Re-enter KDC database master key to verify: *********** Grundlegende ACLs werden dann in der Datei /var/kerberos/krb5kdc/kadm5.acl eingefügt. Die Principals mit der Rolle admin haben uneingeschränkte Zugriffsrechte: */admin@iffldap.iff.kfa-juelich.de * Um den Kerberos-Server zu verwalten, werden kadmin.local und kadmin verwendet. kadmin.local greift direkt auf die KDC-Datenbank zu und benötigt keine Authentifizierung (die zum diesem Zeitpunkt gar nicht in Funktion ist). kadmin 30

45 4.3 Konfiguration und Start wird dagegen für die netzwerkweite Verwaltung benutzt und benötigt daher eine Authentifizierung. kadmin.local wird dann aufgerufen und der principal root/admin wird mit dem Befehl addprinc angelegt: ~]kadmin.local -q "addprinc root/admin" WARNING: no policy specified for defaulting to no policy Enter password for principal Re-enter password for principal Principal created. Am Ende der Ausgabe wird die Verfügbarkeit des Principal root/admin in der Kerberos-Datenbank bestätigt. Die Liste der verfügbaren Befehle lässt sich mit dem Zeichen? anzeigen. Die bereits existierenden Accounts lassen sich mit dem Befehl getprincs, list_principals, listprincs oder get_principals auflisten. Nun existiert ein Principal namens Nachdem Kadmin gestartet wurde, kann sich der Benutzer root mit dem hier verwendeten Passwort als Kerberos-Administrator bei Kadmin authentifizieren. Nun muss den Kadmin-Dienst ein Keytab-File extrahiert werden, damit dieser nicht bei jedem Start nach einer Authentisierung fragen muss. Ein Keytab-File speichert das Passwort in verschlüsselter Form ab: ~]kadmin.local -q "ktadd -k \ /var/kerberos/krb5kdc/kadm5.keytab root/admin" [root@iffldap ~]kadmin.local -q "ktadd -k \ /var/kerberos/krb5kdc/kadm5.keytab root/changepw" Die Keytab-Datei wird in der "kdc.conf" Datei im Attribut admin_keytab beschrieben. Die angegebenen Principals kadmin/admin und kadmin/changepw werden beim Anlegen der Kerberos-Datenbank erstellt. Die Ausgabe des ersten Befehls sieht dann wie folgt aus: Authenticating as principal root/admin@iffldap.iff.kfa-juelich.de with\above password. Entry for principal root/admin with kvno 2, encryption type Triple DES cbc\ mode with HMAC/sha1 added to keytab WRFILE:\ /var/kerberos/krb5kdc/kadm5.keytab. Entry for principal root/admin with kvno 2, encryption type DES cbc mode \ with CRC-32 added to keytab WRFILE:/var/kerberos/krb5kdc/kadm5.keytab. 31

46 4 Kerberos Zusätzlich kann man mit dem Programm ktutil prüfen, ob die kvno-nummer (Key version number) gleich sind ( hier ist kvno=4) [root@iff018 ~]# ktutil ktutil: rkt /var/kerberos/krb5kdc/kadm5.keytab ktutil: list slot KVNO Principal kadmin/admin@iffldap.iff.kfa-juelich.de 2 4 kadmin/admin@iffldap.iff.kfa-juelich.de 3 4 kadmin/changepw@iffldap.iff.kfa-juelich.de 4 4 kadmin/changepw@iffldap.iff.kfa-juelich.de Nun sind alle Konfigurationen erledigt und es kann begonnen werden, die Dienste krb5kdc und kadmin zu starten: [root@iffldap ~]/etc/init.d/krb5kdc start [root@iffldap ~]/etc/init.d/kadmin start 4.4 Kerberisierter LDAP-dienst Um verschlüsselt eine Verbindung mit dem LDAP-Dienst nutzen zu können, wird das sogenannte SASLMech GSSAPI verwendet. Das Kürzel GSSAPI steht für Generic Security Services Application Programming Interface und stellt ein API zur Verfügung, das zur Client-Server Authentifizierung verwendet wird. Es werden zunächst Principals für den Host, auf den LDAP läuft (iffldap.iff.kfa-juelich.de), und den LDAP-Dienst (ldap/iffldap.iff.kfa-juelich.de) angelegt: [root@iffldap ~]# kadmin.local -q "addprinc -randkey iffldap.iff.kfa-juelich\.de" Authenticating as principal root/admin@iffldap.iff.kfa-juelich.de with \ password. WARNING: no policy specified for iffldap.iff.kfa-juelich.de@iffldap.iff.\ KFA-JUELICH.DE; defaulting to no policy Principal "iffldap.iff.kfa-juelich.de@iffldap.iff.kfa-juelich.de" created. [root@iffldap ~]# kadmin.local -q "addprinc -randkey ldap/iffldap.iff.kfa-\ juelich.de" 32

47 4.4 Kerberisierter LDAP-dienst Authenticating as principal with\ password. WARNING: no policy specified for IFF.KFA-JUELICH.DE; defaulting to no policy Principal created. Als nächstes wird ein Keytab-file für den Host iffldap.iff.kfa-juelich.de im kadmin- Interface mit dem Befehl ktadd erstellt: ktadd iffldap.iff.kfa-juelich.de Danach wird ein neuer Principal ohne admin- Rechte für den Benutzer doghmi mit dem Befehl addprinc doghmi angelegt. Mit kinit erhält der Principal doghmi sein erstes Ticket: ~]# kinit doghmi Password for Als nächstes muss noch die PAM-Konfiguration angepasst werden: "/etc/pam.d/system-auth": auth sufficient pam_krb5.so use_first_pass forwardable password sufficient pam_krb5.so use_authto account sufficient pam_krb5.so session optional pam_krb5.so "/etc/security/pam_winbind.conf": krb5_auth = yes krb5_ccache_type = FILE Möchte sich der Benutzer doghmi am System einlogen, so wird nach dem Kerberos- Passwort (Passwort vom Principal doghmi@iff018.iff.kfa-juelich.de ) gefragt. Als letzter Schritt sollte die verschüsselte Kommunikation über SASLMech GS- SAPI erfolgen. Bei der Konfiguration sind jedoch Probleme aufgetreten weswegen dieser Schritt auf einem spätern Zeitpunkt verschoben wurde. Nach näherer Betrachtung der IT-Fachleute des IFF steht eine Entscheidung über der Einsatz von Kerberos (aus Sicherheitserwägungen) noch aus. (siehe Kapitel 8). 33

48 5 Frameworks 5 Frameworks In diesem Kapitel wird die Umgebung vorgestellt, die zur Realisation dieser Arbeit gewählt worden ist. Anschließend werden die Installationschritte der einzelnen Komponenten dieser Umgebung gezeigt. 5.1 Motivation Um die Kommunikation zwischen den unterschiedlichen Technologien bzw. Verzeichnisdiensten zu erleichtern, sollte eine Software-Infrastruktur geschaffen werden, die den kombinierten Einsatz von Programmen ermöglicht. Diese Programme sollten einwandfrei mit den verschiedenen Betriebsystemen Linux, Windows und Mac OS X interagieren. Aus diesem Grund wird im Rahmen dieser Arbeit Python eingesetzt. Die Wahl für Python mit LDAP- und MySQL-Plugins ist aus der Anforderung entstanden, eine Umgebung aufzubauen, die auf allen Plattformen ( Linux, Windows, Mac OS X ) zum Einsatz kommen kann. Zu diesem Zweck wurde auf den Linux und Mac OS Systemen (im /usr/local-bereich) aktuelle Python-Interpreter (Version 2.5.2) aus dem Source Code compiliert und installiert. Diese wurden um die Module MySQL-python (Version 1.2.2) für den Zugriff auf MySQL-Datenbanken und python-ldap (Version 2.3.4) für die LDAP- Funktionalität erweitert. Voraussetzung ist lediglich eine Entwicklungsumgebung fuer MySQL, die aber bei Linux Teil der Distributionen ist und bei Mac OS X wiederum aus dem Source Code compiliert werden konnte. Für Windows wurde diese Prozedur zwar noch nicht durchgeführt, ist aber analog dazu und mittelfristig im IFF auch geplant. Zu den Auswahlkriterien für Python zählt natürlich auch, dass schon in anderen Projekten (im IFF) Python ein probater Lösungsansatz war und sich bestens bewährt hat. 34

49 5.2 Installation 5.2 Installation Python steht als Packet Python tgz unter zum Herunterladen bereit: wget Nach dem Download und dem Entpacken dieser Datei cat Python tgz gunzip tar xf - werden folgende Schritte unternommen, um Python in "/usr/local" zu installieren: cd Python /configure --prefix=/usr/local make make install Analog dazu werden jeweils die LDAP- und MySQL-Packete installiert: wget cat python-ldap tar.gz gunzip tar xf - /usr/local/bin/python setup.py build /usr/local/bin/python setup.py install und wget cat MySQL-python tar.gz gunzip tar xf - /usr/local/bin/python setup.py build /usr/local/bin/python setup.py install Wie diese Module eingesetzt werden, wird ausführlicher im nächsten Kapitel gezeigt. 35

50 6 Lösungsansatz/Konzepte 6 Lösungsansatz/Konzepte Um Abhängigkeiten von einem einzelnen System zu vermeiden, wird die gesamte Information zentral in einer Datenbank vorgehalten und mit den darunterliegenden Systemen abgeglichen. Hierfür werden Werkzeuge in Form von Python- Skripten implementiert, die von den verschiedenen Betriebssystemen Linux, Windows und Macintoch jeweils NIS 10 -, Active Directory- und Open Directory Daten abrufen und dann in entsprechende MySQL-Datenbanktabellen einfügen. Zusätzlich werden andere Schnittstellen implementiert, die die frisch eingefügten Datenbankdaten in die Verzeichnissdienste OpenLDAP, Active Directory und Open Directory überführen. Im ersten Schritt werden die Datenbanktabellen erstellt und zwar so, dass deren Attribute den Namen der LDAP-Nomenklatur entsprechen, da LDAP als Industriestandard gilt. Anstelle der Attribute name und password für Nachname und Passwort werden die LDAP-Bezeichnungen sn (surname) und userpassword verwendet. Als folgendes möchte ich die drei Schnittstellen für Linux, Windows und Macintosch Umgebungen vorstellen: 6.1 Linux-Schnittstelle Authentifizierungs- und Adressbuchdaten in die Datenbank überführen In dieser Schnittstelle werden mehrere Datenbanktabellen erstellt, die NIS-Daten und andere zur Verfügung gestellten IFF 11 -Adressbuchinformationen enthalten. 10 Network Information Service 11 Institut für Festkörperforschung 36

51 6.1 Linux-Schnittstelle Hierbei ist zu beachten, dass die gewählten Bezeichnungen für die Attribute dem LDAP-Standard entsprechen: Die Tabelle posixaccount : Zunächst wird eine Datenbanktabelle mit dem Namen posixaccount erstellt, in der die NIS-Daten eingefügt werden (siehe Abbildung 6.1.1). Hierbei sind uid (Benutzername), sn (Nachname), cn (vollständiger Name), givenname (vorname), homedirectory (Home-Verzeichnis), uidnumber (uid-nummer), gidnumber (gid-nummer), loginshell (Die benutzte Shell) und userpassword (Passwort) die wichtigsten Attribute. accountnumber ist eine Zählvariable, die später als Schlüssel dienen wird. Abbildung 6.1: Struktur der Tabelle posixaccount Die NIS-Daten werden dann mit dem Python-Skript "posixaccount.py" aus der NIS-Datenbank abgerufen und schließlich in die Datenbank (MySQL- Datenbank) eingefügt. Hierbei wurden hauptsächlich die Python-Module pwd und MySQLdb verwendet: #!/usr/local/bin/python import MySQLdb,pwd,string,sys 37

52 6 Lösungsansatz/Konzepte nis_list = pwd.getpwall() Die Funktion getpwall() gibt eine Liste aller gültiger Benutzernamen zurück, wie sie in "/etc/passwd" stehen. Hierbei sind die Passworte chiffriert enthalten (Kein x-zeichen). Der Eintrag vom Benutzer doghmi sieht z.b. wie folgt aus: ( doghmi, $1$/48aWEn0$wY9aYZygk4gRxmqORCWxV/, 1234, 20, \ J.Doghmi, /home/doghmi, /bin/bash ) Wobei: uid= doghmi sn= Doghmi uidnumber=1234 gidnumber=20 loginshell= /bin/bash homedirectory= /home/doghmi Diese Attribute werden, wenn nötig, im Python-Skript extrahiert. sn wurde beispielsweise aus J.Doghmi wie folgt extrahiert: sn = string.split( J.Doghmi,. )[1] Die Funktion split() aus dem Modul string zerlegt die Zeichenkette "J.Doghmi" in zwei Teile und gibt sie in eine Liste [ J, Doghmi ] zurück. Das zweite Element dieser Liste ist dann sn. Da auch andere Adressbuchinformationen (Datenbanktabellen) bereitstehen, können die restlichen Einträge cn (vollständiger Name) und givenname (vorname) aus anderen vorhandenen Tabellen entnommen werden, wie in einem späteren Beispiel zu sehen ist. Als nächster Schritt werden dann die Daten in der Datenbank eingefügt. Um von Python auf eine MySQL-Datenbank zuzugreifen, muss als erstes eine Verbindung zur Datenbank mit der Funktion connect() aufgebaut werden: db = MySQLdb.connect(host="iffwww", user="doghmi", passwd="xxxx", db="iff") Dabei müssen einige Parameter mitgegeben werden: host: repräsentiert den MySQL-Server. user: repräsentiert den Benutzer, der auf die Datenbank zugreift. passwd: repräsentiert das Benutzerpasswort. 38

53 6.1 Linux-Schnittstelle db: repräsentiert den Namen der Datenbank (IFF). Anschließend muss ein Cursor auf die Datenbank geöffnet werden, um Abfragen oder Änderungen an der Datenbank durchführen zu können: cursor = db.cursor() Mit diesem Cursor werden über die Methode execute die Daten mit einer insert-anweisung in der Tabelle posixaccount eingefügt: cursor.execute("insert into posixaccount (uid,sn,cn,givenname,homedirectory,uidnumber,gidnumber,loginshell,userpassword) values (\ %s\,\ %s\,\ %s\,\ %s\,\ %s\,%d,%d,\ %s\,\ %s\ ) " % (uid,sn,\ cn,givenname,homedirectory,uidnumber,gidnumber,loginshell,userpassword) ) Danach wird der Cursor geschlossen und die Änderungen in der Datenbank mit der Funktion commit() übernommen: cursor.close() db.commit() Die Tabelle posixgrouptable: In dieser Tabelle (siehe Abbildung 6.1.1) wird für jede Posix-Gruppe der Gruppenname (cn), das Passwort (grouppassword) und die eindeutige Gruppenummer eingefügt (gidnumber). Das Attribut groupenum ist hierbei eine Zählvariable (primärer Schlüssel). Das Python-Skript, das diese Aufgabe übernimmt heißt posixgroup.py". Hierbei wurde das Modul grp importiert, das die Funktion getgrall() zur Verfügung stellt: group_list = grp.getgrall() getgrall() liefert eine Liste bzw. eine Liste von Tupeln zurück, die den Gruppennamen, das GruppenPasswort, die Gruppennummer und die uids der zugehörigen Mitglieder enthalten. Zu jeder Gruppe gibt es ein Tupel der Art: ( IT, secret, 156, [ doghmi, uid2, uid3 ]) In der Gruppe IT mit der Gruppennummer 156 arbeiten beispielsweise die Benutzer mit de uids doghmi, uid2 und uid3. Analog wie bei der Tabelle 39

54 6 Lösungsansatz/Konzepte Abbildung 6.2: Struktur der Tabelle posixgrouptable posixaccount wird eine Verbindung mit der MySQL-Datenbank aufgebaut und die Informationen entsprechend eingefügt. 40

55 6.1 Linux-Schnittstelle Die Tabelle posixgroups: Diese Tabelle (siehe Abbildung 6.1.1) besitzt nur die zwei Attribute groupenum und accountnumber. Letztere sind primäre Schlüssel, die jeweils jeden Benutzernamen (von der Tabelle posixaccount) und jede Gruppe (von der Tabelle posixgrouptable) eindeutig identifizieren. Die Tabelle sollte wie folgt aussehen: (122L, 328L) (122L, 164L) (122L, 171L) (123L, 212L) (123L, 512L) Vor jeder Gruppennummer groupenum wird eine accountnumber notiert. Beide Parameter können mehrmals auftreten, da jede Gruppe mehrere Benutzer enthalten kann und jeder Benutzer mehrere Gruppen gehören kann. Als erster Schritt werden im Programm "posixgroups.py" sogenannte Dictionarys (bedeutet übersetzt Wörterbuch) gebildet: group_list = grp.getgrall() for item in group_list: dict[item[2]]=item[3] Das dictionary dict könnte wie folgt aussehen: dict = {156: [ doghmi, uid2, uid3 ], 200:[uid4,uid5]} Hierbei dient 156 (gidnumber) als Schlüssel für die Liste [ doghmi, uid2, uid3 ]. Jede gidnumber wird durch ihre zugehörige Gruppennummer groupenum ersetzt. Die groupenum werden der Tabelle posixgrouptable entnommen: cursor.execute("select groupenum from posixgrouptable where gidnumber = \ %s\ " % key ) Analog dazu werden alle uids einer Liste mit der zugehörigen accountnumber von der Tabelle posixaccount ersetzt. Als letzter Schritt wird jede Gruppennummer groupenum mit der zugehörigen accountnumber in die Tabelle posixgroups eingefügt: 41

56 6 Lösungsansatz/Konzepte cursor.execute("insert into posixgroups (groupenum,accountnumber) values(%d,%d)" % (groupenum,accountnumber)) Abbildung 6.3: Struktur der Tabelle posixgroups Die Tabelle posixsamaccount: In dieser Tabelle (siehe Abbildung 6.1.1) werden für jeden Benutzer (zusätzlich zu anderen posix-daten) seine zugehörigen Samba-Daten eingefügt. Samba ist eine freie Software, die typische Funktionen wie Datei- und Druckdienste eines Windows-Servers auf Unix-Systemen nachbildet. Die Daten der Tabelle posixsamaccount (z.b. sambalmpassword, sambantpassword, sambaacctflags) stehen in der Datei "smbpasswd.txt" zur Verfügung. Diese hat eine ähnliche Struktur wie die Datei "/etc/passwd". Hier ist ein Auszug aus "smbpasswd.txt" für den Benutzer doghmi: doghmi:1234:194e407cec4144a9aad3b435b533see:2a878bf69632ca02f2452de35\ 4A8E68D:[U ]:LCT-47D9360A: Die Samba- und Posixdaten werden dann mit dem Skript "posixsamaccount.py" in der posixsamaccount-tabelle eingefügt. Nach dem öffnen des Skriptes "posixsamaccount.py" werden die Daten zeilenweise abgearbeitet, um die gewünschten Informationen zu extrahieren. fd = file("smbpasswd.txt") # Datei oeffnen while True: line = fd.readline() # Zeilenweise einlesen Danach wird analaog zur Tabelle "posixaccount" eine Verbindung mit der MySQL-Datenbank aufgebaut und die Informationen entsprechend eingefügt. Andere Tabellen: Nach dem gleichen Prinzip wurden sechs andere Tabellen erstellt und durch Python-Skripte mit Daten gefüllt. Diese sind teilweise oder komplett anderen Tabellen anderer Datenbanken (nicht der Datenbank IFF) entnommen 42

57 6.1 Linux-Schnittstelle Abbildung 6.4: Struktur der Tabelle posixsamaccount worden. Dabei entsprechen die Bezeichnungen der Attribute dem LDAP- Standard. Die sechs Tabellen sind: departmenttable: beschreibt (siehe Abbildung 6.1.1) die verschiedenen Abteilungen im IFF und die zugehörigen Kostenstellen. die Kostenstelle repräsentiert z.b. die Abteilung Netzwerke und Numerik Abbildung 6.5: Struktur der Tabelle departmenttable 43

58 6 Lösungsansatz/Konzepte member und memberbussiness: beschreiben (siehe die Abbildung im Anhang A) Adressbuchdaten (mail, Title usw.) der Mitarbeiter des IFF. houseidentifiertable und location: beschreiben (siehe die Abbildung im Anhang A) die Gebäuden und Räume im IFF. organizationalrole: beschreibt (siehe die Abbildung im Anhang A) die Mitarbeiterrollen im IFF LDAP-Server mit Datenbankdaten füllen In dieser Schnittstelle werden die im vorigen Abschnitt in die Datenbank überführten Authentifizierungs- und Adressbuchdaten (Benutzerdaten) auf dem LDAP-Server eingefügt. Diese Aufgabe übernimmt das Python-Skript "LdapServer_Insert.py". Hierbei wird das wichtige Python-Modul ldap benutzt: import ldap, MySQLdb,string import ldap.modlist as modlist Das LDAP-Protokoll ist sitzungsorientiert. Das bedeutet, daß, bevor Daten ausgetauscht werden können, zuerst eine sogenannte Session (Sitzung) initailisiert werden muss. Das erfolgt in drei Schritten: Binding: Die Anmeldung des Client am Server. Dies kann mit oder ohne Authentifizierung geschehen. Message-Exchange: Der eigentliche Austausch von Informationen bzw. Nachrichten (Clientseite: request, Serverseite: Response). Dieser Austausch erfolgt durch : bind, unbind, search, add, modify, delete, compare, abandon (Abbruch der Anfrage) usw. Unbind: Normale Beendigung der Verbindung mit dem LDAP-Server Wie oben beschrieben wird zunächst eine Sitzung mit dem LDAP-Server initialisiert und eine authentifizierte Anmeldung des Clients root (root ist der Name des LDAP-Adminstrators) erfolgen: 44

59 6.1 Linux-Schnittstelle l = ldap.initialize( ldap://iffldap.iff.kfa-juelich.de ) l.simple_bind_s("cn=root,o=fz-juelich,dc=fz-juelich,dc=de","secret") Das Ziel dieser Schnittstelle besteht darin, alle Abteilungen des IFF unter dem bereits existierenden dn "o=iff,o=fz-juelich,dc=fz-juelich,dc=de" (siehe Abschnitt 3.6) einzufügen. Hierbei wird eine Unterorganisation namens "departments" (ou=departments) direkt unter "o=iff" erstellt werden. Für "departments" werden zunächst Objektklassen und Attribute definiert. Mit dem LDAP-Modul modlist wird es möglich, die dn-einträge im LDIF 12 -Format einzufügen. dn= "ou=departments,o=iff,o=fz-juelich,dc=fz-juelich,dc=de" attrs = {} attrs[ objectclass ] = [ top, organizationalunit ] attrs[ ou ]= departments ldif = modlist.addmodlist(attrs) Schließlich wird der dn-eintrag von "departments" wie folgt eingefügt: l.add_s(dn,ldif) Die Abteilungen und die Kostenstellen des IFF werden in einem dictionary (Wörterbuch) gespeichert, da die Koststellen eindeutig die Abteilungen identifizieren. Die Kostenstelle identifiziert eindeutig die Abteilung Netzwerke und Numerik : costcenter = { : Leitung und Allgemeines, : Netzwerke und Numerik, : Konstruktion und Werkstatt,...} Das Ziel ist, alle Kostenstellenstellen in der folgenden DN-Form auf dem LDAP- Server zu bringen: 12 LDAP Data Interchange Format 45

60 6 Lösungsansatz/Konzepte dn: ou=60400,ou=departments,o=iff,o=fz-juelich,dc=fz-juelich,dc=de objectclass: top objectclass: organizationalunit ou: description: Netzwerke und Numerik Hierfür wir das dictionary costcenter mit einer Schleife durchgelaufen um schließlich die Einträge in der gewünschten Form einzufügen: for key in costcenter.keys(): dn= "ou=" + key + ",ou=departments,o=iff,o=fz-juelich,dc=fz-juelich,dc=de" attrs[ ou ]= key attrs[ description ] = costcenter[key] ldif = modlist.addmodlist(attrs) l.add_s(dn,ldif) Als nächtes werden Benutzerdaten von der Datenbank auf den LDAP-Server überführt. Hierfür wird jeder Benutzer einmal direkt unter der entprechenden Abteilung bzw. Kostenstelle und ein zweites Mal unter dem bereits existierenden "ou=people" Eintrag (siehe Abschnitt 3.6) eingefügt. Unter dem DN-Eintrag "ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de"werden alle Benutzer eingefügt, unabhägig davon, zu welcher Kostenstelle sie gehören. Der DN-Eintrag vom Benutzer doghmi sollte dann wie folgt aussehen: dn: uid=doghmi,ou=60400,ou=departments,o=iff,o=fz-juelich,dc=fz-juelich,dc=de dn: uid=doghmi,ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de In beiden Fälle mit den Attributen: cn: Jaouad Doghmi objectclass: top objectclass: inetorgperson objectclass: posixaccount objectclass: shadowaccount loginshell: /usr/local/bin/tcsh userpassword:: TGEfplEyeCC3Mm8tXi5seElzUzZrUUd5Z1JmVmo3VmpROM== uidnumber: gidnumber: 20 46

61 6.1 Linux-Schnittstelle sn: Doghmi homedirectory: /usr/users/iff_ge/doghmi mail: givenname: Jaouad uid: doghmi Um dieses Ergebnis zu erreichen, wird zunächst eine Verbindung mit der Datenbank (MySQL-Datenbank) aufgebaut und dann werden die gewünschten Benutzerdaten mit einer SQL-Abfrage selektiert: cursor.execute("select pa.uid, Ac.name, Ac.vorname, Ac. , pa.uidnumber, pa.gidnumber, pa.loginshell, pa.homedirectory, pa.userpassword, Ac.kst from posixaccount pa, Accounts Ac where convert(pa.uid using utf8) = convert(ac.login using utf8)") Da in der Tabelle posixaccount einige Benutzerdaten nicht vorhanden sind, werden diese von der Tabelle accounts entnommen (kst steht für Kostenstelle). Das Ergebnis einer Abfrage muß man sich mittels eines Cursors besorgen: while 1 : row = cursor.fetchone() if row == None: break Mit der Funktion fetchone() bekommt man eine Tabellenzeile als Tupel. Über die Position im Tupel kann man dann auf einzelne Werte zugreifen: else: (uid, name, vorname, , uidnumber, gidnumber, loginshell, homedirectory, userpassword, kst)=row Im nächsten Schritt werden die nötigen DN-Einträge definiert: dn1= "uid=" + uid + ",ou=" + str(kst) + ",ou=departments,o=iff,o=fz-juelich,\ dc=fz-juelich,dc=de" dn2= "uid=" + uid + ",ou=people,o=iff,o=fz-juelich,dc=fz-juelich,dc=de" 47

62 6 Lösungsansatz/Konzepte Die Funktion str() wandelt Zahlen in eine Zeichenkette. Danach werden wieder die folgenden Attribute definiert attrs[ uid ]= uid attrs[ sn ]= name attrs[ givenname ] = vorname attrs[ cn ]=(vorname + + name) attrs[ mail ]= attrs[ uidnumber ]=str(uidnumber) attrs[ gidnumber ]=str(gidnumber) attrs[ loginshell ]=loginshell attrs[ homedirectory ]=homedirectory attrs[ userpassword ]= userpassword und die Einträge im entsprechenden Format eingefügt: ldif = modlist.addmodlist(attrs) l.add_s(dn1,ldif) l.add_s(dn2,ldif) Die Verbindung mit dem LDAP-Server wird abschließend beendet. l.unbind_s() 48

63 6.2 Windows-Schnittstelle 6.2 Windows-Schnittstelle Da Active Directory das LDAP-Protokoll benutzt (siehe Kapitel 1 Abschnitt 2.3.1), wird hier ein Python-Skript AD_Insert.py geschrieben, um auf den Active Directory-Datenbestand (nur Benutzerdaten) zuzugreifen und diesen in die Datenbank einzufügen. Hierbei werden Unterschiede der Adressbuchdaten in der Datenbank (Mysql-Server) und Active Directory bestimmt und korrigiert. Als erster Schritt wurde eine Tabelle namens ActiveDirectoryAccount erstellt, in der die gesamte Information eingefügt wird. Da diese Tabelle zu gross ist, wird sie hier nicht graphisch wie bei den vorigen Tabellen dargestellt. Die einzelnen Attribute kann man sich aber mit der folgenden SQL-Abfrage describe ActiveDirectoryAccount im Anhang B ansehen. Ananlog wie bei "LdapServer_Insert.py" wird eine Sitzung (Session) mit dem Domän Controller bzw. dem Active Directory-Server aufgebaut und es erfolgt eine authentifizierte Anmeldung: l = ldap.initialize( ldap://iffad.iffwin.kfa-juelich.de ) l = ldap.open("iffad.iffwin.kfa-juelich.de") l.simple_bind(username,password) Außerdem wird eine DN-Basis festgelegt, ab der die Suche nach Benutzerdaten anfangen soll: basedn = "dc=iffwin,dc=kfa-juelich,dc=de" Damit die Einträge selektiv (und nicht alle möglichen Ergebnisse aus dem DIT 13 ) ausgelesen werden, werden Suchfilter (siehe Kapitel 2 Abschnitt 3.9.1) eingesetzt, die die Suche auf Benutzer bzw. Benutzerdaten einschränken: searchscope = ldap.scope_subtree retrieveattributes = None searchfilter = "(&(objectclass=person)(objectcategory=user))" Hierbei werden alle Einträge gesucht, die die Objektklasse "person" importieren und zur Objectcategory "user" gehören. 13 Data Information Tree 49

64 6 Lösungsansatz/Konzepte Danach kann die Suche beginnen: ldap_result_id = l.search(basedn, searchscope,searchfilter,retrieveattributes) Jeder gefundene Benutzereintrag wird in eine Liste namens result_data mit allen zugehörigen Attribute und Objektklassen zuruückgegeben. Diese Liste wird wiederum in die Gesamtliste result_set eingefügt : result_set=[] while 1: try: result_type,result_data = l.result(ldap_result_id,0) if( result_data == [] ): break else: if result_type == ldap.res_search_entry: #Eintraege in der Liste result_set speichern result_set.append(result_data) Ein Auszug aus der Liste result_data für den Benutzer "doghmi" sieht wie folgt aus: [( CN=Jaouad Doghmi,OU=Benutzer,OU=Netzwerke und Numerik,DC=iffw2k, DC=kfa-juelich,DC=de, { primarygroupid : [ 513 ], cn : [ Jaouad Doghmi ], objectclass : [ top, person, organizationalperson, user ], memberof : [ CN=60400,CN=Users,DC=iffw2k,DC=kfa-juelich,DC=de ], accountexpires : [ ], displayname : [ Jaouad Doghmi ], physicaldeliveryofficename : [ ], name :[ Jaouad Doghmi ], sn : [ Doghmi ], givenname : [ Jaouad ] } )] Als nächster Schritt werden die Active Directory Informationen weiter per Scripting extrahiert und einige Attribute wie Name, Raumnummer, Gebäudenummer und Telefonnummer mit den Informationen in der Datenbank verglichen. Die Unterschiede werden in den folgenden Dateien gespeichert: 50

65 6.3 Macintosh-Schnittstelle "User_not_Found.txt": enthält Namen der Benutzer (Active Directory), die nicht in der Datenbank ( Tabelle: member) existieren. "House_Error.txt": enthält Namen der Benutzer, bei denen unterschiedliche Gebäudeangaben aufgetreten sind. "Room_Error.txt": enthält Namen der Benutzer, bei denen unterschiedliche Raumnummernangaben aufgetreten sind. "Tel_Error.txt": Benutzer, die unterschiedliche Telefonnummern in der Datenbank (DB) und in der ActiveDirectory (AD) haben. Nach dem Korrigieren der Angaben können die Active Directory-Benutzerdaten mit einer einfachen SQL-Anweisung (insert) in die Tabelle "ActiveDirectoryAccount" eingefügt werden. 6.3 Macintosh-Schnittstelle Analog zu den anderen Schnittstellen wird zunächst eine Tabelle namens macaccount (siehe Abbildung 6.3) erstellt. Die Bezeichnung dieser Tabelle sind von den Attributsnamen im Open Directory abgeleitet (siehe Kapitel 1 Abschnitt 2.3.2). Die Python-Skripts (inklusive die Module MySQLdb und ldap), die für Linux geschrieben und dort auch getestet worden sind, sollten auch unter Mac OS X laufen, da Open Directory auf LDAP basiert (siehe Kapitel 1 Abschnitt 2.3.2) und die benutzten Werkzeuge systemunabhängig sind (siehe Kapitel 5). Die Tests konnten nur nicht mit einem entsprechenden Server vorgenommen werden, weil der zugehörige Rechner im Produktionsbetrieb ist. Demnächst sollen diese Skripte in einer virtualisierten Serverumgebung getestet werden. 51

66 6 Lösungsansatz/Konzepte Abbildung 6.6: Struktur der Tabelle macaccount 52

67 7 Anwendungsbeispiele Der LDAP-Verzeichnisdienst kann sowohl auf Mac OS X als auch auf Linux Systemen genutzt werden. Die Adressbuch-Anwendung auf Mac OS X bietet hier die Möglichkeit, einen oder mehrere Verzeichnisdienste anzubinden (siehe Abbildung 7) Abbildung 7.1: Anbindung des LDAP-Verzeichnisdienstes Es ist nur die Hostname des LDAP-Servers sowie der entsprechende Suchbereich einmalig zu konfigurieren (siehe Abbildung 7): 53

68 7 Anwendungsbeispiele Abbildung 7.2: Konfiguration von Adressbuch Damit ist es dann bei allen Anwendungen unter Mac OS X (Mail, Kalender, Adressbuch, etc.) möglich, auf diese Daten zuzugreifen. Der Umgang mit Adressen oder sonstigen Kontaktdaten wird dadurch erheblich vereinfacht (siehe Abbildung 7). 54

69 Abbildung 7.3: Verwaltung von Kontaktdaten Analog dazu, kann auch das LDAP-Verzeichnis im verbreiteten Mailprogramm Thunderbird genutzt werden (siehe Abbildung 7). 55

70 7 Anwendungsbeispiele Abbildung 7.4: LDAP-Verzeichnis und Thunderbird 56