Studienarbeit. Adrian Reber. IT/SW 7, Hochschule für Technik - Fachhochschule Esslingen. <adrian@fht-esslingen.de>

Transkript

1 Studienarbeit Untersuchung über mögliche Vereinheitlichung und Vereinfachung der Benutzerverwaltung im Rechenzentrum der Hochschule für Technik - Fachhochschule Esslingen mit Linux, Solaris 2.6, Solaris 8, WindowsNT und Windows Juni 2001 Betreuer: Professor Herbert Wiese <Herbert.Wiese@fht-esslingen.de> Betreuer: Martin Schmid <Martin.Schmid@fht-esslingen.de> Adrian Reber IT/SW 7, Hochschule für Technik - Fachhochschule Esslingen <adrian@fht-esslingen.de>

2 Copyright 2001 Adrian Reber.Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

3 Zusammenfassung Dieses Dokument entstand im Rahmen meiner Studienarbeit im 7. Semester. In diesem Dokument wird die Untersuchung und der Entwurf eines Authentifikationssystems unter Verwendung von LDAP Directory Services unter verschiedenen Betriebssystemen behandelt. Ziel ist es, den Verwaltungsprozess innerhalb eines Netzwerkes zu optimieren. Bedanken möchte ich mich bei Professor Herbert Wiese und Martin Schmid für die Unterstützung bei der Erstellung dieses Dokumentes. Dieses Dokument wurde mit L A TEX 2εgesetzt.

4 INHALTSVERZEICHNIS Inhaltsverzeichnis Inhaltsverzeichnis 2 Abbildungsverzeichnis 4 Literaturverzeichnis 5 1 Auslöser 6 2 Grundlagen Einarbeitung in Directory Services Begriffe Aufbau eines Directories Einsatzbeispiele von Directory Services Zusammenfassung Einarbeitung in LDAP LDAP Operationen Ablauf einer Operation LDAP API Mögliche Lösungsansätze Pure LDAP Lösung Pure WindowsNT Lösung Kombination von LDAP und WindowsNT

5 INHALTSVERZEICHNIS 4 Installation Pure LDAP Lösung Solaris Linux Kombination von LDAP und WindowsNT Samba-TNG als PDC (Primary Domain Controller) Samba-TNG als PDC (Primary Domain Controller) mit OpenLDAP-Backend Ergebnis Allgemein LDAP SAMBA Betriebssystemspezifisch Solaris Linux Windows NT/ Ausblick - Was ist noch möglich GNU Free Documentation License Applicability and Definitions Verbatim Copying Copying in Quantity Modifications Combining Documents Collections of Documents Aggregation With Independent Works Translation Termination Future Revisions of This License

6 ABBILDUNGSVERZEICHNIS Abbildungsverzeichnis 2.1 Aufbau einer LDAP Anbindung Beispiel eines Directory Baumes (Traditionelle Namensgebung) Beispiel eines Directory Baumes (Internet Namensgebung) Einfache Baumstruktur

7 LITERATURVERZEICHNIS Literaturverzeichnis [1] [2] [3] doc.html [4] [5] [6] [7] [8] [9] [10] ldap.html [11] [12] [13] [14] adrian/studienarbeit.pdf 5

8 KAPITEL 1. AUSLÖSER Kapitel 1 Auslöser Dieses Dokument entstand im Rahmen der Studienarbeit LDAP mit Linux, Solaris und WindowsNT. Auslöser hierfür war das vorhandene Authentifikationssystem im Rechenzentrum 1 der Hochschule für Technik - Fachhochschule Esslingen. Die vorhandene Konfiguration baut auf zwei Systemen auf. Einmal die WindowsNT-Welt und das andere ist die Unix-Welt mit Linux und Solaris als Hauptvertreter. WindowsNT benutzt sein eigenes Authentifikationssystem und alle Unices sind mittels NIS so verbunden, dass der Benutzer auf allen Unixplattformen das gleiche Passwort hat. Trotzdem gibt es für den Benutzer immer noch zwei Passwörter. Wie dies für den Benutzer unangenehm ist, so ist es auch doppelter Aufwand für die Verwaltung der Benutzer. Jeder Benutzer muss auf beiden Systemen eingerichtet und gepflegt werden. Deshalb war es schon lange der Wunsch des Rechenzentrums, eine einheitliche Authentikationsmethode einzuführen. Dieses Dokument beschreibt verschiedene Lösungsansätze und versucht, davon jeweils das Beste herauszuarbeiten

9 KAPITEL 2. GRUNDLAGEN Kapitel 2 Grundlagen 2.1 Einarbeitung in Directory Services Begriffe Directory Service Ein Directory Service stellt eine zentralisierte Datenbank für Informationen über z.b. die Benutzer in einem großen Unternehmen dar. Hierbei werden oft Namen, Telefonnummern, -Adressen, aber auch Fotos, Public Keys und Passwörter gespeichert, um sie unternehmensweit den Applikationen zur Verfügung stellen zu können. Hierdurch soll eine einfachere Verwaltung dieser Daten über Systemgrenzen hinweg stattfinden. Dies wird besonders deutlich, wenn man Netze mit mehreren tausend Usern an unterschiedlichen Standorten verwalten möchte bzw. wenn man von verschiedenen Betriebssystemen und/oder verschiedenen Applikationen an einer gemeinsamen Datenbasis authentifizieren möchte. Directories finden schon seit langer Zeit Verwendung, sind aber meist produktbezogen wie z.b. bei Lotus Notes oder den Novell Directory Services des Novell Betriebssystems. Hierdurch wurde die Verwendung des Directories auf eine geschlossene Gruppe eingeengt. Es wurde schon früh ein offener Standard für Directories entworfen. Dieser OSI X.500 Standard definiert einen Directory Service und enthält folgende Bestandteile: 7

10 2.1. EINARBEITUNG IN DIRECTORY SERVICES Informations Modell legt die Form und die Art der Information innerhalb des Directories fest. Namensraum wird benötigt um die Informationen zu referenzieren und zu organisieren. Funktionalmodell legt fest welche Operationen mit den Informationen durchgeführt werden können. Authentifikations Framework wird benötigt um die Information und den Zugriff darauf zu sichern. Verteiltes Operations Modell legt fest wie die Informationen verteilt werden und wie die Operationen dazu ausgeführt werden. Directory Zugriffs Protokoll (DAP) legt fest wie der Zugriff auf das Directory von einem Client aus abläuft. Dieser Standard hat sich bisher aber nur schwer durchgesetzt, da er sehr umfangreich zu implementieren ist und einen komplexen Aufbau hat. Dies zieht Probleme im Einsatz mit dem Internet nach sich, wo z.b nur begrenzte Bandbreiten vorhanden sind. An dieser Stelle setzt der LDAP Entwurf an. LDAP Das Lightweight Directory Access Protocol stellt im Kern ein Zugriffsprotokoll für Directory Services dar, welches auf die Verwendung im Internet optimiert ist. Es ist im RFC 1777 Dokument definiert. Zunächst war LDAP als schnelles Zugriffsprotokoll für X.500 Directory Services gedacht, wurde aber in den letzten Jahren zu einer stand-alone Lösung mit eigenen Directory Servern weiterentwickelt. Die Vorzüge von LDAP liegen zunächst in der Einfachheit des Protokolls, was einen Geschwindigkeitsvorteil bei der Datenübertragung zur Folge hat. Vor allem in verteilten Umgebungen, welche über das Internet miteinander verbunden sind, ist dies äußerst wichtig. Des 8

11 2.1. EINARBEITUNG IN DIRECTORY SERVICES Abbildung 2.1: Aufbau einer LDAP Anbindung weiteren existiert eine standardisierte API dafür, so dass für die Verwendung von LDAP keine eigenen Implementierungen notwendig sind, sondern eigene Software relativ leicht LDAP-befähigt werden kann. Die Abbildung 2.1 zeigt den Aufbau einer LDAP-Anbindung. API Application Programming Interfaces stellen einen abstrakten Zugriff auf bestimmte Funktionalitäten dar, im Fall LDAP auf die Funktionen zum Zugriff auf das Directory. Eine standardisierte API vereinfacht die Implementierung der Funktionen in eigenen Programmen, da man sich über tieferliegende Schichten keine Gedanken machen muss und sozusagen einfach gegen die API programmiert Aufbau eines Directories Ein Directory wird in Form eines Wurzelbaums verwaltet. Die Verzeichnisstruktur abstrahiert den Aufbau der von ihr dargestellten Organisation. Hierdurch wird es möglich, auch komplexe Strukturen einer Firma, die selbst über Ländergrenzen hinwegreichen, innerhalb eines Directories abzubilden und zu verwalten. Bisher wurden noch keine Standards für den strukturellen Aufbau eines Directories festgelegt, aber im Internet existieren einige Richtlinien für den Aufbau der einzelnen Einträge des Baumes. Abbildung 2.2 auf Seite 10 zeigt ein Beispiel eines Directory Baumes einer Firma. Dieser Direc- 9

12 2.1. EINARBEITUNG IN DIRECTORY SERVICES Abbildung 2.2: Beispiel eines Directory Baumes (Traditionelle Namensgebung) tory Baum benutzt noch den traditionellen LDAP-Namensraum. Abbildung 2.3 auf Seite 11 zeigt ein Beispiel, das als LDAP-Namensraum die Internet Domänennamen benutzt. Kern des Directory Modells sind die Einträge, welche durch die Knoten dargestellt werden. Jeder Eintrag enthält Attribute, welche jeweils einen Typ und einen oder mehrere Werte haben. Durch den Typ des Attributs wird die Syntax für den Wert festgelegt. Die Einträge werden in der Baumstruktur entsprechend ihrer Position durch einen sogenannten Distinguished Name (DN) benannt. Ein DN kann zum Beispiel folgendermaßen aufgebaut sein: 10

13 2.1. EINARBEITUNG IN DIRECTORY SERVICES Abbildung 2.3: Beispiel eines Directory Baumes (Internet Namensgebung) ou=people, o=fht-esslingen, c=de Jeder Teilstring der DN ist ein sog. relative DN (RDN). Es besteht die Möglichkeit Alias-Einträge anzulegen, welche dann auf andere Einträge zeigen. Die Einträge werden in Klassen eingeteilt, die festlegen welche Attribute vorhanden sein müssen und welche möglich sind. Dies kann je nach Konfiguration des Directory Servers strikt oder offen gehandhabt werden, sprich es dürfen auch Attribute vorhanden sein die nicht definiert sind, bzw. es dürfen Attribute fehlen welche als benötigt definiert sind. Bei offener Handhabung kann es allerdings auch geschehen, dass Einträge innerhalb des Directories unbrauchbar werden, indem z.b. alle Attribute eines Eintrags gelöscht werden. Um zu erkennen zu welcher Klasse ein Eintrag gehört und welche Attribute daher unbedingt vorhanden sein müssen bzw. welche erlaubt sind existiert ein spezielles objectclass Attribut. Dieses enthält den Namen der Klasse, welche dann innerhalb der Serverkonfiguration existieren muss (z.b. 11

14 2.1. EINARBEITUNG IN DIRECTORY SERVICES person, organisation usw.). Für die Klassen haben sich einige Standards eingebürgert, welche jedoch nur als Richtschnur gelten. Dieser Eintrag beschreibt die Klasse person, welche eine beliebige Person innerhalb einer Firma repräsentiert. objectclass person requires objectclass, sn, cn allows description, seealso, telephonenumber, userpassword In diesem Fall müssen bei einem Eintrag dieses Typs unbedingt die Attribute objectclass, sn und cn vorhanden sein. Weiterhin sind die Attribute description, seealso, telephonenumber und userpassword möglich. Weitere Informationen zu den Attributen findet sich im RFC Einsatzbeispiele von Directory Services Netscape Communicator Adressbuch Der Netscape Communicator ist eine integrierte Client Applikation für Web und zugriff. Er bietet die Möglichkeit, auf einen Directory Service als Adressbuch zuzugreifen. Hierdurch wird es möglich, unternehmensweit ein globales Adressbuch für alle Mitarbeiter zu führen, welches zentral über den Directory Service gepflegt wird. Lotus Notes Lotus Notes stellt eine Workgroup Lösung zum Modellieren von internen Geschäftsprozessen sowie als Kommunikationsclient dar. Hierbei wird ein 12

15 2.1. EINARBEITUNG IN DIRECTORY SERVICES Directory Service verwendet um die Benutzerverwaltung des Notessystems zu realisieren. Die Directory Services werden auf Applikationsebene verwendet, sind aber auch nur innerhalb der LotusNotes Applikation zugänglich. Novell Netware Bei Novell Netware handelt es sich um ein Netzwerkbetriebssystem, welches mittels eigener Directory Services die zentralisierte Verwaltung der Benutzerdatenbank für die im Netz befindlichen Server realisiert. Hierbei finden die Directory Services Verwendung auf der Betriebssystemebene, sind allerdings für Applikationen nicht oder nur schwer zugänglich, da die Spezifikationen des Directory nicht offengelegt sind. Active Directory Mit dem Active Directory hat Microsoft nun auch bei seinen NT Betriebssystemen einen Directory Service zur Benutzerverwaltung eingeführt. Tatsächlich stellt das Active Directory noch weit mehr als eine reine Benutzerverwaltung dar, da die gesamte bisherige Domänenstruktur Directorybasiert aufgebaut wurde. So bekommt man aus dem Active Directory nicht nur Benutzerinformationen, sondern auch Daten über Rechner wie z.b. Hostname, IP-Adressen und noch einige Verwaltungsinformationen mehr. Erfreulicherweise wurde das Active Directory unter Verwendung des LDAP Standards implementiert, so dass sowohl der Zugriff vom Betriebssystem als auch von der Applikationsebene problemlos möglich sein sollte. Microsoft scheint damit unter anderem einen allgemein zugänglichen Authentifizierungsdienst für Anwendungen zu schaffen. Wobei Microsoft es wieder einmal schafft einen Standard zu benutzen, aber in einer so unübersichtlichen Weise, dass es schwer sein wird mit nicht-microsoftprodukten damit zu arbeiten. 13

16 2.1. EINARBEITUNG IN DIRECTORY SERVICES Zusammenfassung Directory Services mit offenen Standards scheinen für die zukünftige Entwicklung eine wichtige Schlüsseltechnologie zu werden, da Zugriff auf applikationsübergreifende Daten damit relativ problemlos möglich ist. Der größte Bedarf wird sich wohl in der Administration großer, inhomogener Netze finden. Allerdings sind noch viele weitere Szenarien denkbar. 14

17 2.2. EINARBEITUNG IN LDAP 2.2 Einarbeitung in LDAP LDAP Operationen Bind Operation Mit der Bind Operation wird eine Verbindung zwischem dem Client und dem Server initiert. An dieser Stelle findet auch die Authentifikation des Clients statt. Die Bind Operation muss als erste Operation bei einer Sitzung ausgeführt werden. Es gibt 2 Möglichkeiten der Bind Operation: Anonymous Bind Der anonyme Bind wird schneller ausgeführt und berechtigt meist nur zum Lesen bestimmter Attribute. Wichtig für Client Anwendungen, die häufige Leseoperationen auf das Directory durchführen. Bind mit DN In diesem Fall wird ein DN übergeben mit der die Verbindung authentifiziert wird. In diesem Fall muss auch ein Passwort übergeben werden. Unbind Operation Die Unbind Operation bewirkt genau das Gegenteil von der Bind Operation und beendet eine Verbindung mit dem Server. Search Operation Mit der Search Operation kann der Client das Directory ab einer bestimmten Stelle des Baumes durchsuchen. Diese Stelle wird als sogenannter Base DN übergeben. Als Suchstring können Attribute übergeben werden. Details zur Suche finden sich im RFC Modify Operation Mit der Modify Operation kann ein Eintrag im Directory Baum geändert werden. Hierbei muss bei der Bind Operation ein entsprechend berechtigter 15

18 2.2. EINARBEITUNG IN LDAP DN angegeben werden. Die Modify Operation erwartet das zu modifizierende Objekt als DN und eine Anzahl von Modifikationen, welche daran vorgenommen werden sollen. Add Operation Mit der Add Operation kann ein Eintrag an einer beliebigen Stelle des Baumes hinzugefügt werden, sofern die entsprechenden Berechtigungen vorhanden sind. Es muss das neu zu erzeugende Objekt als DN und eine Anzahl von Attributen angegeben werden. Delete Operation Mit der Delete Operation kann ein Objekteintrag aus dem Directory entfernt werden. Hierzu muss die DN des Objekts übergeben werden. Compare Operation Mit der Compare Operation wird ein Attribut eines Eintrags mit einem Wert verglichen werden. Dies ist z.b. bei Passworten wichtig. Es muss die DN des Eintrags und das zu vergleichende Attribut angegeben werden Ablauf einer Operation Eine Operation wird vom Client an den Server übermittelt und in eine Warteschlange gestellt. Der Server beantwortet die Anfrage dann mit einem LDAP Result. Hierbei können bei den meisten Operationen TimeOut Werte angegeben werden, um das anfragende Programm nicht zu lange zu blockieren LDAP API Die LDAP API stellt eine definierte Schnittstelle zur Schicht der LDAP Operationen dar. Die API ist weitgehend standardisiert, so dass man sie in Form 16

19 2.2. EINARBEITUNG IN LDAP von Bibliotheken in seine Programme einbinden kann. Es existieren für verschiedene Compilersprachen entsprechende Bibliotheken, bzw. entsprechende Module für Skriptsprachen wie Perl oder PHP. Einen Überblick über die Anzahl der API Funktionen und ihre Aufgaben gibt die manpage des OpenLDAP-Projektes zu ihrer Implementation einer C-Bibliothek: ldap open(3) open a connection to an LDAP server ldap init(3) initialize the LDAP library without opening a connection to a server ldap result(3) wait for the result from an asynchronous operation ldap abandon(3) abandon (abort) an asynchronous operation ldap add(3) asynchronously add an entry ldap add s(3) synchronously add an entry ldap bind(3) asynchronously bind to the directory ldap bind s(3) synchronously bind to the directory ldap simple bind(3) asynchronously bind to the directory using simple authentication ldap simple bind s(3) synchronously bind to the directory using simple authentication ldap kerberos bind s(3) synchronously bind to the directory using kerberos authentication ldap kerberos bind1(3) asynchronously bind to the LDAP server using kerberos authentication 17

20 2.2. EINARBEITUNG IN LDAP ldap kerberos bind1 s(3) synchronously bind to the LDAP server using kerberos authentication ldap kerberos bind2(3) asynchronously bind to the DSA using kerberos authentication ldap kerberos bind2 s(3) synchronously bind to the DSA using kerberos authentication ldap unbind(3) synchronously unbind from the LDAP server and close the connection ldap unbind s(3) equivalent to ldap unbind(3) ldap memfree (3) dispose of memory allocated by LDAP routines. ldap enable cache(3) enable LDAP client caching ldap disable cache(3) disable LDAP client caching ldap destroy cache(3) disable LDAP client caching and destroy cache contents ldap flush cache(3) flush LDAP client cache ldap uncache entry(3) uncache requests pertaining to an entry ldap uncache request(3) uncache a request ldap set cache options(3) set cache options ldap compare(3) asynchronous compare to a directory entry ldap compare s(3) synchronous compare to a directory entry ldap delete(3) asynchronously delete an entry ldap delete s(3) synchronously delete an entry ldap init templates(3) initialize display template routines from a file 18

21 2.2. EINARBEITUNG IN LDAP ldap init templates buf(3) initialize display template routines from a buffer ldap free templates(3) free display template routine memory ldap first disptmpl(3) get first display template ldap next disptmpl(3) get next display template ldap oc2template(3) return template appropriate for objectclass ldap name2template(3) return named template ldap tmplattrs(3) return attributes needed by template ldap first tmplrow(3) return first row of displayable items in a template ldap next tmplrow(3) return next row of displayable items in a template ldap first tmplcol(3) return first column of displayable items in a template ldap next tmplcol(3) return next column of displayable items in a template ldap entry2text(3) display an entry as text using a display template ldap entry2text search(3) search for and display an entry as text using a display template ldap vals2text(3) display values as text ldap entry2html(3) display an entry as HTML (HyperText Markup Language) using a display template ldap entry2html search(3) search for and display an entry as HTML using a display template ldap vals2html(3) display values as HTML 19

22 2.2. EINARBEITUNG IN LDAP ldap perror(3 ) print an LDAP error indication to standard error ld errno(3) LDAP error indication ldap result2error(3) extract LDAP error indication from LDAP result ldap errlist(3) list of ldap errors and their meanings ldap err2string(3) convert LDAP error indication to a string ldap first attribute(3) return first attribute name in an entry ldap next attribute(3) return next attribute name in an entry ldap first entry(3) return first entry in a chain of search results ldap next entry(3) return next entry in a chain of search results ldap count entries(3) return number of entries in a search result ldap friendly name(3) map from unfriendly to friendly names ldap free friendlymap(3) free resources used by ldap friendly(3) ldap get dn(3) extract the DN from an entry ldap explode dn(3) convert a DN into its component parts ldap explode rdn(3) convert a RDN into its component parts ldap dn2ufn(3) convert a DN into user friendly form ldap get values(3) return an attribute s values ldap get values len(3) return an attribute values with lengths ldap value free(3) free memory allocated by ldap get values(3) ldap value free len(3) free memory allocated by ldap get values len(3) ldap count values(3) return number of values 20

23 2.2. EINARBEITUNG IN LDAP ldap count values len(3) return number of values ldap init getfilter(3) initialize getfilter routines from a file ldap init getfilter buf(3) initialize getfilter routines from a buffer ldap getfilter free(3) free resources allocated by ldap init getfilter(3) ldap getfirstfilter(3) return first search filter ldap getnextfilter(3) return next search filter ldap build filter(3) construct an LDAP search filter from a pattern ldap setfilteraffixes(3) set prefix and suffix for search filters ldap modify(3) asynchronously modify an entry ldap modify s(3) synchronously modify an entry ldap mods free(3) free array of pointers to mod structures used by ldap modify(3) ldap modrdn2(3) asynchronously modify the RDN of an entry ldap modrdn2 s(3) synchronously modify the RDN of an entry ldap modrdn(3) depreciated - use ldap modrdn2(3) ldap modrdn s(3) depreciated - use ldap modrdn2 s(3) ldap msgfree(3) free results allocated by ldap result(3) ldap msgtype(3) return the message type of a message from ldap result(3) ldap msgid(3) return the message id of a message from ldap result(3) ldap search(3) asynchronously search the directory ldap search s(3) synchronously search the directory 21

24 2.2. EINARBEITUNG IN LDAP ldap search st(3) synchronously search the directory with timeout ldap ufn search s(3) user friendly search the directory ldap ufn search c(3) user friendly search the directory with cancel ldap ufn search ct(3) user friendly search the directory with cancel and timeout ldap ufn setfilter(3) set filter file used by ldap ufn(3) routines ldap ufn setprefix(3) set prefix used by ldap ufn(3) routines ldap ufn timeout(3) set timeout used by ldap ufn(3) routines ldap is ldap url(3) check a URL string to see if it is an LDAP URL ldap url parse(3) break up an LDAP URL string into its components ldap url search(3) asynchronously search using an LDAP URL ldap url search s(3) synchronously search using an LDAP URL ldap url search st(3) synchronously search using an LDAP URL and a timeout ldap init searchprefs(3) initialize searchprefs routines from a file ldap init searchprefs buf(3) initialize searchprefs routines from a buffer ldap free searchprefs(3) free memory allocated by searchprefs routines ldap first searchobj(3) return first searchpref object ldap next searchobj(3) return next searchpref object ldap sort entries(3) sort a list of search results ldap sort values(3) sort a list of attribute values ldap sort strcasecmp(3) case insensitive string comparison 22

25 KAPITEL 3. MÖGLICHE LÖSUNGSANSÄTZE Kapitel 3 Mögliche Lösungsansätze 3.1 Pure LDAP Lösung Eine mögliche Lösung wäre der Einsatz eines LDAP-Servers, der die Aufgaben der vorhandenen Authentifikationsserver übernimmt. In dem enstehenden Diretory-Baum könnte man dann aber auch noch zusätzliche Informationen speichern. Nicht nur Benutzername, Passwort und Homeverzeichnis, sondern auch Daten wie die Telefonnummer und -Adresse der Person. Die Anbindung der Clients würde per PAM 1 erfolgen. Weitere Möglichkeit wäre außerdem noch Daten zu den Computern (fstab, hosts, services,... ) im Directory zu speichern. 3.2 Pure WindowsNT Lösung Ein anderer möglicher Ansatz wäre, die ganze Authentifizierung auf Windows aufzubauen. Über PAM könnten sich auch hier alle Unix-Clients an der vorhandenen NT Domäne authentifizieren. Auf diese Lösung soll hier nicht weiter eingegangen werden, da viele zentralen Dienste unter einem der beiden Unices (Solaris oder Linux) laufen. Viele dieser zentralen Dienste lassen sich nicht ohne weiteres auf dieses neue Schema umstellen. Außerdem 1 Pluggable Authentication Module 23

26 3.3. KOMBINATION VON LDAP UND WINDOWSNT möchte sich niemand freiwillig in eine so große Abhängigkeit von Microsoft und deren Produkte geben. Vor allem nicht, wenn es sich um so zentrale Dienste handelt. Weiteres Problem ist, dass WindowsNT nicht mehr lange offiziell von Microsoft unterstüzt wird und Windows 2000 noch sehr fehlerbehaftet ist. 3.3 Kombination von LDAP und WindowsNT Nachdem die beiden vorherigen Lösungsansätze jeweils an einem bestimmten Punkt nicht mehr weiterführten, wäre es doch eine gute Idee das Beste aus beiden Untersuchungen zu vereinen. Oder anders gesagt: Nicht jedes Betriebssystem mit Gewalt zu einer bestimmten Authentifizierungsmethode zwingen, sondern jedem Betriebssystem seine Lieblingsmethode zur Verfügung stellen. Oder zumindest eine Methode anbieten, die ohne Aufwand und unnötige Verrenkungen benutzt werden kann. Als die mögliche goldene Lösung für alle Probleme soll Samba-TNG 2 betrachtet werden. Samba-TNG ist das Ergebnis aus einer Abspaltung einiger Leute von dem Haupt-Samba-Code-Baum. Diese Leute sind der Meinung, dass Samba endlich auch als Primärer Domänen Kontroller fungieren soll, und haben deshalb ein eigenes Projekt gegründet. Das Ergebnis dieses Projektes soll dann auch später vielleicht wieder in den Haupt-Samba-Code- Baum einfließen. 2 Samba The Next Generation

27 KAPITEL 4. INSTALLATION Kapitel 4 Installation 4.1 Pure LDAP Lösung Die Installation unterteilt sich in die Installation und Konfiguration der Software auf den drei Zielplattformen Solaris, Linux und Windows Solaris 2.6 Die LDAP Implementation die benutzt wurde ist die von OpenLDAP 1. Aktuelle Version ist Damit OpenLDAP vollständig LDAPv3 kompatibel ist benötigt es SASL 2. SASL ist eine Methode um Authentifikationsmöglichkeiten einem verbindungsbasierten Protokoll zur Verfügung zu stellen. SASL fügt eine Sicherheitsschicht zwischen dem Protokoll und der Verbindung ein. Weitere Details zu SASL sind im RFC 2222 zu finden und bei SASL direkt. Weiteres Kriterium für LDAPv3 Konformität ist die Benutzung von TLS 3, was Bestandteil von OpenSSL 4 ist Simple Authentication and Security Layer Transport Layer Security 4 Secure Sockets Layer

28 4.1. PURE LDAP LÖSUNG Installation von OpenSSL Das erste Problem, das sich unter Solaris 2.6 stellt wenn man OpenSSL übersetzen und installieren möchte ist die Tatsache, dass Solaris 2.6 kein /dev/random hat. Um dieses Problem zu lösen muss man das Paket SUNski installieren. Dieses Paket findet man in dem Patch (sparc). Jetzt startet man noch den neuen Dienst, und wenn man die folgende Zeile in der Ausgabe von ps -eaf sieht, dann bekommt man Zufallszahlen aus /dev/random. /usr/lib/security/cryptorand /dev/random Der Rest der Installation von OpenSSL ist wie bei jeder anderen Installation auch: >./config > make > make test > make install Installation von SASL Da wir keine Kerberos 5 Umgebung haben wird diese Authentifizierungsmethode abgeschaltet. >./configure --with-pam=/usr/lib/security --enable-plain \ --disable-krb4 --enable-anon --enable-cram \ --enable-login --prefix=/usr/local/rpm > make > make install Die Option with-pam sagt, dass wir auf einem pamifizierten System sind und enable-plain ist die Passwortübermittelungsmethode. Diese Methode kann benutzt werden, da SASL OpenSSL benutzt und so die Klartext Passwörter doch nicht im Klartext übermittelt werden

29 4.1. PURE LDAP LÖSUNG Generierung der SASLDB Die Methoden CRAM-MD5 und DIGEST-MD5 sind nicht verfügbar solange man nicht eine SASLDB 6 hat. Um die SASLDB zu generieren wird das Werkzeug saslpasswd benutzt. > saslpasswd dummyuser Password: Again (for verification): Jetzt ist unter /etc/sasldb die SASLDB zu finden. Testen der SASL -> PAM Authentifizierung Vor der Integration von SASL -> PAM in OpenLDAP sollte als Erstes festgestellt werden, ob der SASL -> PAM Mechanismus funktioniert. Dieser Test wird durchgeführt mit Hilfe der Testwerkzeuge (sample-server und sampleclient), die in der SASL Bibliothek enthalten sind. Der SASL Test wird mit dem sample Dienst durchgeführt. Dazu wird die Datei /usr/local/rpm/lib/sasl/sample.conf mit folgendem Inhalt angelegt: pwcheck_method: pam Die /etc/pam.conf wird eine Sektion mit dem Namen sample angelegt:... sample auth required /lib/security/pam_pwdb.so debug \ shadow nullok sample auth required /lib/security/pam_nologin.so... Wichtig ist, dass man zwischen Linux-PAM und Solaris-PAM unterscheidet. Unter Linux gibt es ein Verzeichnis /etc/pam.d in welchem für jeden 6 SASL Passwort Datenbank 27