Zentralisierte Benutzerverwaltung mit OpenLDAP und AIX 5L 5.2. Projektarbeit. Zentralisierte Benutzerverwaltung mit OpenLDAP und AIX 5L 5.

Transkript

1 Projektarbeit Zentralisierte Benutzerverwaltung mit OpenLDAP und AIX 5L 5.2 Leonardo di Lella Jan Finsel Mentor: Prof. Dr. H. Stenzel 1

2 Revision History Revision Revision Summary of Changes Number Date First Draft Version Added more detailed configuration steps for AIX Abstract The purpose of this paper is to introduce the possible ways to create a centralized user management system in the faculty of computer science and engineering science located in based on OpenLDAP and on AIX. There are four steps to realize such a centralized user management system in the faculty of computer science and engineering science in. This paper covers only the first step with some initial ideas for the next three steps. The administrator will have the possibility to create, modify and to delete user accounts with a clean web application based on perl. 2

3 1 IST-ZUSTAND, PROBLEMATIK UND DIE NÄCHSTEN SCHRITTE 5 2 HARDWAREANFORDERUNG Client Server 6 3 INSTALLATION DES OPENLDAP SERVERS Was ist LDAP? Die Kompatibilität zwischen OpenLDAP und IBM Secureway LDAP OpenLDAP Server Konfiguration Erstellen der CA und des SSL Server Zertifikats Erstellen der slapd Konfiguration Usermigration Testen der Konfiguration 11 4 AIX LDAP CLIENT KONFIGURATION Nachteil dieser Lösung 13 5 PAM UND NSS LDAP MODULE UNTER AIX PAM: NSSLDAP: PAMLDAP: 15 6 CLIENT KURZBESCHREIBUNG 15 7 BESCHREIBUNG DES QUELLCODES Grundaufbau der Perlklasse admin.pl Benötigte Bibliotheken LDAP-Konfiguration: Sonstige Konfiguration Client - Der Programmteil Login Die LDAP-Verbindung Das Session-Management Die Suche Das Einfügen, Ändern, Löschen, Sperren eines Benutzers Der Logout 25 8 DER QUELLCODE - KOMPLETT 25 3

4 9 REFERENZEN 34 4

5 1 IST-Zustand, Problematik und die nächsten Schritte Die größte Problematik bei der Authentifizierung aller Benutzer ist die redundante Speicherung und Administrierung aller Userinformationen. Die Benutzer werden sowohl auf der ADVM2 als auch in der Fachhochschule Köln abgespeichert. Ein weiteres Problem ist das unsichere Authentifizierungsmechanismus NIS. In den folgenden Schritten werden zuerst alle Benutzer auf einem separaten Linux LDAP Server migriert, die dann im letzten Schritt mit dem OpenLDAP Server der FH Köln repliziert werden. Neben der einfachen Administrator durch eine zentrale Benutzerverwaltung, kann der Administrator alle Benutzer bequem über eine in Perl geschrieben Web-Oberfläche administrieren und somit Benutzer neu anlegen, editieren, löschen und sperren. 2 Hardwareanforderung 2.1 Client X86 Debian Linux OpenLDAP Server 5

6 2.2 Server AIX 5L 5.2 Server 3 Installation des OpenLDAP Servers Der Linux OpenLDAP Server basiert auf einer unstable Debian Version. Der Vorteil einer unstable ist die schnelle Verfügbarkeit neuerer Pakete. Alle unnötigen Paket wurden deinstalliert. Die gehärtete Version enthält noch zusätzlich eine Firewall, damit der Administrator den Server im Echtbetrieb vor Angreifer schützen kann. 3.1 Was ist LDAP? Die Abkürzung LDAP steht für Lightweight Directory Access Protocol, auf deutsch Leichtes Verzeichnis-Zugangs-Protokoll. Wie der Name schon sagt, unterstützt dieses Protokoll einen Verzeichnisdienst. Die erste Implementation von LDAPv1 (Lightweight Directory Access Protocol) wurde an der Universität von Michigan im Juli 1993 entwickelt. Es gibt verschiedene kommerzielle LDAP- Server. Mit OpenLDAP gibt es eine auf der Arbeit von der Michigan basierenden OpenSource-Implementation von LDAP. OpenLDAP ist auf jedem Linux und BSD-Betriebssystem verfügbar. LDAP stellt einen Verzeichnisdienst zur Verfügung, der zur Speicherung und zum Wiederabruf von Informationen über einzelne Personen einer Organisation genutzt werden kann. Viele Distributionen nutzen LDAP auch zur Authentifizierung der Benutzer. 3.2 Die Kompatibilität zwischen OpenLDAP und IBM Secureway LDAP Das bis jetzt größte Problem bei dem Versuch einen AIX Client an einem OpenLDAP Server zu authentifizieren ist die von IBM nicht eingehaltene LDAP Struktur (RFC2307 [1]). Dabei bliebt dem Administrator meist nichts anderes übrig als die OpenLDAP Sourcen zu patchen. [2] Der Nachteil dieser Lösung ist 6

7 die schlechte Wartbarkeit und das damit verbundene Sicherheitsrisiko. Der Admin hätte somit die Sourcen bei jeder neue Version des OpenLDAPs patchen müssen. Neben dem Patchen der OpenLDAP Sourcen musste der Administrator auch die LDIFs auf das OpenLDAP Format portieren. [3] Doch seit AIX 5L in der Version 5.2 hat sich das Problem des unterschiedlichen Schemas und Syntax gelöst. Der IBM Secureway LDAP Client kann nun ohne Probleme und ohne Änderungen an beiden Seiten mit dem OpenLDAP Server kommunizieren. 3.3 OpenLDAP Server Konfiguration Der OpenLDAP Server wird über den normalen Debian Paketinstallationsweg installiert. Nach der automatischen Installation werden auf der Serverseite noch die folgenden Schritte bearbeitet: 1. Erstellen der CA und des SSL Server Zertifikats 2. Erstellen der slapd Konfiguration 3. Usermigration 4. Testen der Konfiguration Erstellen der CA und des SSL Server Zertifikats OpenSSL verfügt über gute Shellscripts, damit das Erstellen der Zertifikate so einfach wie möglich ermöglicht werden kann. Der Anwender braucht sich dabei nicht mit den Manuals von OpenSSL zu beschäftigen. Das Script CA.sh erlaubt es dem Anwender Zertifikate zu erstellen und zu signieren. # misc/ca -newca CA certificate filename (or enter to create) Making CA certificate... Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to './democa/private/cakey.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase:

8 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [US]: DE State or Province Name (full name) [Texas]: NRW Locality Name (eg, city) [Austin]: Organization Name (eg, company) [Weeorg Ltd]: FH- Organizational Unit Name (eg, section) []: informatic Common Name (eg, YOUR name) []:gm.fh-koeln.de Address []:ca@gm.fh-koeln.de # misc/ca -newreq Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to 'newreq.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [US]: DE State or Province Name (full name) [Texas]: NRW Locality Name (eg, city) [Austin]: Organization Name (eg, company) [Weeorg Ltd]: FH- Organizational Unit Name (eg, section) []:LDAP server Common Name (eg, your name or your server's hostname) []:ldap.gm.fh-koeln.de Address []:admin@gm.fh-koeln.de Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request (and private key) is in newreq.pem Die CA wurde nun in der Datei cacert.pem und das Server Zertifikat in der Datei newreq.pem abgespeichert. Zum Schluß wird das Server Zertifikat mit dem signreq Befehl signiert und das Passwort mittels openssl rsa entfernt. Würden wir das Passwort nicht entfernen, so würde sich der LDAP Server beim Starten aufhängen, da er beim Lesen des Zertifikats auf das Passwort warten würde. # openssl rsa -in newreq.pem -out ldapkey.pem read RSA key Enter PEM pass phrase: writing RSA key 8

9 # rm newreq.pem Damit die Zertifikate von unserem LDAP Server gelesen werden, müssen Sie noch in das richtige Verzeichnis kopiert werden und die Rechte angepasst werden. # mv newcert.pem /usr/share/ssl/certs/ldapcert.pem # chmod og+r /usr/share/ssl/certs/ldapcert.pem # mv ldapkey.pem /etc/openldap # chown ldap /etc/openldap/ldapkey.pem # chmod 400 /etc/openldap/ldapkey.pem Erstellen der slapd Konfiguration Die Konfigurationsdatei befindet sich bei der Debian Installation unter /etc/openldap/slapd.conf. Die Datei ist in vier logischen Teile aufgeteilt: Schema, TLS, back end und Zugriffskontrolle (access control). OpenLDAP unterstützt neben TLS natürlich auch noch SSL Verbindungen. include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema loglevel 256 TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /usr/share/ssl/certs/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ldapkey.pem TLSCACertificateFile /usr/share/ssl/democa/cacert.pem security tls=112 database ldbm suffix "dc=gm,dc=fh-koeln,dc=de" rootdn "cn=admin, dc=gm,dc=fh-koeln,dc=de" rootpw SSHAvoNuRGGB+LaiwCZ8SRbBCq0lBn0BeG1W password-hash crypt directory /var/lib/ldap index objectclass eq index uid,uidnumber,gidnumber eq index cn eq,subinitial access to attr=userpassword by dn="cn=admin,dc=gm,dc=fh-koeln,dc=de" write by self write by anonymous auth access to * by dn="cn=admin, dc=gm,dc=fh-koeln,dc=de" write by self read by * read defaultaccess read 9

10 Die Struktur der LDAP Datenbank wird mit den Migrationtools von padl.com erstellt Usermigration Es gibt wahrscheinlich mehrere Möglichkeiten die User von einem AIX System in einer LDAP Datenbank zu importieren. Alle wichtigsten Informationen stehen in den Konfigurationsdateien wie der /etc/group und in der /etc/security/passwd dem Admin zur Verfügung. Der schwierigste Teil ist das Parsen der Userinformationen in einem von LDAP akzeptierten Syntax. Die Entwickler von padl.com ( haben schon gute Vorarbeit geleistet, so dass eine Migration von Linuxbenutzer in einer LDAP Struktur mittels drei Skriptaufrufe realisiert werden kann. Die drei Perl-Skripte migrate_base.pl, migrate_passwd.pl und migrate_group.pl parsen die Dateien /etc/group, /etc/passwd und /etc/shadow und erstellen eine komplette LDAP Struktur, die dann einfach nur mit slapadd importiert werden kann. Die BaseDN wird in der Konfigurationsdatei migrate_common.ph eingestellt. Dafür muss lediglich die Variable $DEFAULT_BASE angepasst werden. # cd /usr/share/openldap/migration #./migrate_base.pl > /var/lib/ldap/top.ldif #./migrate_passwd.pl /etc/passwd > /var/lib/ldap/passwd.ldif #./migrate_group.pl /etc/group > /var/lib/ldap/group.ldif # cd /var/lib/ldap # vi passwd.ldif group.ldif # remove users and groups # cat top.ldif passwd.ldif group.ldif slapadd -b "dc=gm,dc=fh-koeln,dc=de" # chown -R ldap /var/lib/ldap # chmod -R og-rw /var/lib/ldap Eine Portierung der MigrationTools Skripte auf einem AIX System ist dank Perl nicht erforderlich. Die einzige Änderung besteht in der Anpassung der Parserroutine für die Datei /etc/security/passwd. Die Passworthashes können auch eins zu eins übernommen werden, da UNIX standardmäßig DES One-way-hash benutzt. ai332: password = MGURSj.F056Dj lastupdate = flags = ADMIN,NOCHECK (MG.. = salt) 10

11 Neben der Migration der Benutzer mit Hilfe der MigrationTools gibt es noch die Möglichkeit die Userdaten mit Hilfe des Befehls sectoldif in den LDAP zu importieren. # sectoldif d cn=admin,dc=gm,dc=fh-koeln,dc=de S RFC2307 Die Option S gibt das LDAP Schema Format an. RFC2307 wird nur ab Version 5.2 unterstützt. [4] Testen der Konfiguration Der slapd Server läuft standardmäßig auf Port 389 (ldap) und auf Port 636 (ldaps). Beide Verbindungsarten sind dabei möglich. Mit Hilfe von ldapsearch kann ein einfacher Test gemacht werden: $ ldapsearch -x -LLL -h ldap.gm.fh-koeln.de -b dc=gm,dc=fh-koeln,dc=de uid=leo ldap_bind: Confidentiality required additional info: TLS confidentiality required # ldapsearch -x -ZZ -LLL -h ldap.gm.fh-koeln.de -b dc=gm,dc=fh-koeln,dc=de uid=leo dn: uid=leo,ou=people,dc=gm,dc=fh-koeln,dc=de uid: leo cn: Leonardo Di Lella objectclass: account 4 AIX LDAP client Konfiguration Auf der AIX Seite muß der AIX GS kit Client nun das CA Zertifikat in der Liste der Signer Certificates aufnehmen. Dafür wird in der gsk5ikm Schlüsselmanagement Applikation eine neue Schlüssel-Datenbank erstellt. Danach wird die CA des Linux Servers mit dem Add-Button importiert. Alle anderen CA Zertifikate können nun von der AIX Schlüssel-Datenbank gelöscht werden. 11

12 Unter AIX 5L Version 5.2 stellt die Anbindung an einem OpenLDAP Server kein großes Problem mehr dar. # mksecldap -c -h ldap.gm.fh-koeln.de -a cn=admin,dc=gm,dc=fh-koeln,dc=de -p secret \ -S rfc2307 -d dc=gm,dc=fh-koeln,dc=de -k /etc/security/ldap/key.kdb -u NONE Die Option u verhindert, dass das Programm mksecldap alle Benutzer aus der /etc/security/user zum LDAP verbindet. So kann der Administrator selbst entscheiden welcher Benutzer sich am LDAP authentifiziert und welcher nicht. # chuser SYSTEM=LDAP registry=ldap joe Im Anschluß müssen nur noch einige Anpassungen in der Datei /etc/security/ldap/ldap.cfg vorgenommen werden. ldapservers:ldap.gm.fh-koeln.de ldapadmin:cn cn=admin,dc=gm,dc=fh-koeln,dc=de ldapadmpwd:secret usessl:yes ldapsslkeyf:/etc/security/ldap/key.kdb userattrmappath:/etc/security/ldap/2307user.map groupattrmappath:/etc/security/ldap/2307group.map userbasedn:ou=people, dc=gm,dc=fh-koeln,dc=de groupbasedn:ou=group, dc=gm,dc=fh-koeln,dc=de userclasses:account,posixaccount,shadowaccount groupclasses:posixgroup 12

13 ldapversion:3 ldapport:389 ldapsslport:636 Die Datei /etc/security/ldap/key.kdb ist die Schlüssel-Datenbank, die wir schon im vorherigen Schritt erstellt haben. Die Schlüssel-Datenbank muss das Zertifikat des LDAP Servers beinhaltet sonst schlägt die Verbindung zum LDAP fehl. Nachdem alles konfiguriert wurde kann der secldapcintd Daemon auf dem AIX System gestartet werden. # restart-secldapclntd 4.1 Nachteil dieser Lösung Der Nachteil dieser Lösung wird in der zuletzt editierten Datei ldap.cfg ersichtlich. Das Passwort des Administrators kann nur als plaintext in dieser Datei abgespeichert werden. Problematisch wird das ganze wenn der LDAP Server und der AIX Client von verschiedenen Fakultäten oder Administratoren gewartet wird. Dabei müssten beide Seite das Password des LDAP Administrators kennen. Ein weiteres Problem taucht auf, wenn mehrere AIX Client eine LDAP Verbindung aufbauen wollen. Jeder AIX Client hätte somit wiederum das Passwort als plaintext auf der Festplatte. Zwar kann nur immer der Benutzer mit Root-Rechten die Datei lesen, doch bei einem Kompromittieren des Systems wäre das ganze System gefährdet. 5 PAM und NSS LDAP Module unter AIX Das PAM LDAP Modul authentifiziert die Benutzer auf einer ganz anderen Weise als das AIX LDAP System. Der Benutzer bindet sich an dem LDAP Server. Durch die Bindung an den Server wird überprüft, ob die Kombination aus Benutzername und Passwort korrekt ist, wobei der Benutzer im Falle einer erfolgreichen Bindung authentifiziert wird. Wenn die Bindung fehlschlägt, wird der Benutzer nicht authentifiziert. Das System braucht hierbei das Passwort des Administrators nicht zu wissen. 13

14 Der einzige Nachteil an dieser Implementation ist, dass nur alle PAM Dienste sich via LDAP authentifizieren lassen. Bei SSH wäre das kein Problem aber bei Telnet oder dem normalen Login über die Konsole gibt es nicht immer PAM Unterstützung. Die PAM Unterstützung ist Applikationsabhängig und ein wichtiges Feature. Unterstützt eine Software die PAM Authentifzierung so wird diese Software in der /etc/pam.conf eingetragen. Die /etc/pam.conf spezifiert die PAM Richtlinien. sshd auth required /usr/lib/security/pam_ldap.so use_first_pass sshd account required /usr/lib/security/pam_ldap.so sshd password required /usr/lib/security/pam_ldap.so sshd session required /usr/lib/security/pam_ldap.so Nach dieser Änderung authentifiziert sich sshd gegen den LDAP. Das System basiert aber immer noch auf lokale Dateien und auf die Namesauflösung. Hier kommt das NSS LDAP Modul ins Spiel. Das Modul kann auch wie das PAM LDAP ohne Probleme auf ein AIX 5.2 System installiert werden. Die installierten Module werden dann in das /usr/lib/security Verzeichnis kopiert. Nach der Installation des NSS LDAP Moduls müssen nur noch zwei Dateien, die Datei /usr/lib/security/methods.cfg und nss_ldap.conf, angepasst werden. 14

15 5.1 PAM: program = /usr/lib/security/pam options = authonly 5.2 NSSLDAP: program = /usr/lib/security/nss_ldap options = dbonly 5.3 PAMLDAP: options = db=nssldap,auth=pam Die Datei nss_ldap.conf enthält die BaseDN und alle für einen Client relevanten LDAP Informationen. 6 Client Kurzbeschreibung Für die Pflege und Administration des eingerichteten LDAP wird eine Administrations-Oberfläche benötigt. Da das später verwendete LDAP-Schema nicht genau spezifiziert ist, wird hierbei versucht die Administrationsoberfläche so anzulegen, dass die Administrations-Oberfläche ohne langwierige Umbauarbeiten angepasst werden kann. Ziel der Oberfläche ist es, den folgenden Funktionsumfang abzudecken: Anlegen von einem neuen Benutzer incl. seiner Daten Ändern eines bereits bestehenden Benutzers, incl. seiner Daten Löschen von Benutzern Sperren von Benutzern für den Zugriff auf das System. 7 Beschreibung des Quellcodes 7.1 Grundaufbau der Perlklasse admin.pl Grundsätzlich ist die Klasse admin.pl folgendermaßen aufgebaut. Zunächst werden die benötigten Bibliotheken initialisiert, damit sie im Code benutzt werden können. Da wir versucht haben den Code unabhängig vom LDAP- 15

16 Schema zu entwickeln ist ein Konfigurationsblock notwendig. Für die Entwicklung wurde zwar das POXIS-Ldap-Schema benutzt, welches zum Beispiel auch bei einem Suse Linux Enterprise Server als LDAP Schema für den Login benutzt wurde, jedoch ist dieses Schema für in dem Konfigurationsblock variabel austauschbar. Hiernach folgt ein kleiner Block in dem die sonstige Konfiguration festgelegt wird die nichts mit der Konfiguration des LDAP Codes zu tun hat. Anschließend folgt der Programmcode der ebenfalls wieder in mehrere Unterblöcke unterteilt ist. Grundsätzlich ist der Programmteil in drei wesentliche Blöcke unterteilt: 1. Vor dem Login, d.h ohne vorhandene Session. 2. Nach dem Login, d.h mit vorhandener Session 3. Hilfsfunktionen, wie zum Beispiel diverse oft gebrauchte HTML- Funktionen für den Aufbau der Webseiten oder eine Funktion zur Verbindung mit dem LDAP. Auf den gesamten Aufbau wird jetzt in den folgenden Kapiteln noch genauer eingegangen. 7.2 Benötigte Bibliotheken Codeausschnitt: use CGI; use Digest::MD5 qw(md5_hex); use Net::LDAP; use CGI::Session; Für den Client wurden folgende Bibliotheken für Perl neben den Standardbibliotheken benötigt: DAS CGI Modul Das CGI-Modul gehört seit der Perl-Version zu den Standardmodulen. Es stellt eine Menge Funktionen bereit, die typische Routine-Aufgaben von CGI-Scripts übernehmen. Die enthaltenen Funktionen sind durch vielfachen Praxiseinsatz bewährt. Es ist deshalb sinnvoll, für CGI-Scripts auf die Ressourcen zurückzugreifen, die dieses Modul bereitstellt. Ein Nachteil 16

17 des CGI-Moduls ist allerdings, dass es recht groß ist. Bei CGI-Scripts, die sehr häufig aufgerufen werden (z.b. Zugriffszähler-Scripts auf vielbesuchten Seiten), kann sich das bei der Belastung des Server-Rechners bemerkbar machen. In solchen Fällen ist es durchaus vertretbar, sich bewusst gegen die Verwendung des CGI-Moduls zu entscheiden. Bei den meisten CGI-Scripts ist die Verwendung des CGI-Moduls jedoch zu empfehlen. Denn das Modul übernimmt unter anderem auch eine ganze Reihe von automatischen Anpassungen an die Laufumgebung des Scripts, durch die mögliche Fehler vermieden werden. Das CGI-Modul besteht aus einem Hauptmodul und verschiedenen Untermodulen. Die Untermodule leisten spezielle Aufgaben wie beispielsweise die Unterstützung des neueren Fast-CGI-Standards oder die Unterstützung so genannter Server-Pushs. Digest::MD5 Erlaubt es MD5 Prüfsummen zu erstellen. NET::LDAP Net-LDAP ist eine Schnittstelle zwischen LDAP und Perl. Jedoch hat sie gegenüber anderen Schnittstellen einige Vorteile. So kann zum Beispiel über diese Schnittstelle sehr komplexe Suchfunktionen ausführen und benötigt hierfür nur eine Codeanzahl. Alle NET::LDAP Module sind in perl geschrieben. Es sind keine Systemerweiterungen nötig um mit NET::LDAP zu arbeiten oder NET::LDAP zu installieren. Zudem wird an NET::LDAP stetig weiter entwickelt. CGI::SESSION CGI-Session ist ein Perl Modul seit der Perl-Version 5. Es ist eine Bibliothek die ein leichte, sichere und modulares Session Management für HTTP- Requests ermöglicht. s. Die Sicherheit ist eine der Schlüsseleigenschaften für eine solche Applikation wie sie hier benötigt wird. CGI-Session kann dies und noch viel mehr. 17

18 7.3 LDAP-Konfiguration: Codeausschnitt: #Main Configuration LDAP my $ldapserver = " "; my $ldapport = 389; my $basedn ="dc=gm,dc=fh-koeln,dc=de"; my $ldap_userbase = 'ou=people,'; my $objectcl = 'account'; my $scope = 'one'; #Subconfiguration LDAP my $ldapprimarykey = 'uid'; my $ldapdisablefield = 'loginshell'; my $ldapdisablevalue = '/bin/false'; my $ldappasswordfield = 'userpassword'; = ('objectclass', 'uidnumber', 'homedirectory', 'loginshell', 'gidnumber', 'uid', 'shadowmax', 'shadowwarning', 'userpassword'); my $rootconnection='cn=admin,dc=gm,dc=fh-koeln,dc=de'; Die Konfiguration des LDAP ist in zwei Teile unterteilt. Im ersten Teil werden elementare Einstellungen wie die URL und den Port den LDAP-Servers eingegeben. Zusätzlich noch die Base_DN, sowie die LDAP UserBase, sowie eine Objectclass zu der die Objekte gehören sollen. Unter scope wird eingestellt, wie der Baum bei einer Suche durchsucht werden soll. Gültige Werte sind hier: One Es wird die Ebene direkt unter dem Basisobjekt durchsucht Base Nur das Basis-Objekt wird durchsucht Sub Es wird der komplette Unterbaum durchsucht. Im zweiten Teil sind alle Einstellungen, die ansonsten für den Betrieb notwendig sind einzutragen. Hierzu gehören: Die Ldapfelder, das heißt alle Felder, die für die LDAP benötigt werden. Ein Ldapprimärfeld, welches eindeutig sein muss. Das Ldapfeld, in dem das Passwort steht, damit man es verschlüsseln kann. 18

19 Das Ldapfeld, in dem man Benutzer sperren kann. Den Wert, der benötigt wird, damit ein Benutzer gesperrt ist. Diese Angaben wären bei einem spezifierten LDAP-Schema natürlich nicht wichtig, weil man dort ja alle Felder genau kennt und die jeweiligen Funktionen darauf anwenden kann. Anders als bei einer herkömmlichen Datenbank gibt es im LDAP für ein Feld keine Datentypen. Was heißt, das man zum Beispiel in ein Feld in dem man nur Integerwerte haben will theoretisch auch Zeichenketten eingeben könnte. Bei einer von einem Schema unabhängigen Implementation gibt es keine genaue Kenntnis über die wichtigen Felder. Deshalb muss zum Beispiel angegeben werden welches Feld das Userpasswort enthält, damit dieses verschlüsselt eingetragen werden kann. Genauso ist es dem Feld welches dafür genutzt wird Benutzer zu sperren, und den Wert der benötigt wird um das zu tun. Hierauf wird aber im später noch einmal genauer eingegangen. 7.4 Sonstige Konfiguration Im Konfigurationsblock der sonstigen Konfiguration, wird nur das Verzeichnis eingestellt, in dem die Sessiondaten auf dem Server gespeichert werden. 7.5 Client - Der Programmteil Login Für den Login verbindet sich der Anwender zum Perlscript Admin.pl. Im folgenden erscheint die Webseite (siehe Abbildung1): 19

20 Abbildung 1: Screenshot Login - Vor Login Hier gibt der User seinen Benutzernamen und sein Passwort ein mit dem er sich im LDAP einloggen möchte. Per Post-Befehl wird Username und Password an das Perlscript zurückgesendet. Jetzt wird versucht mit den eingegebenen Daten eine LDAP-Verbindung auftzubauen. Gelingt dies wird eine Session erstellt und die Benutzerdaten Username und Password dem Sessionobject hinzugefügt. Danach wird ins Benutzermenü weitergeleitet (siehe Abbildung 2). Für unseren eingestellten Adminaccount ist lediglich ein Password notwendig. Das Feld Username wurde aber trotzdem bereits hinzugefügt, da in einem spätern Schritt in den Rechten des LDAP Schemas zusätzliche Benutzer hinzugefügt werden könnten, die Zugriff auf die Daten des LDAPs haben. Das Herstellen der Verbindung zum LDAP sowie das Session-Management wird jetzt in den beiden folgenden Menüpunkten beschrieben. Über das Menü ist es möglich 6 Funktionen auszuführen. Die wie folgt lauten: 1. Einfügen eines neuen Benutzers 2. Editieren eines Benutzers 3. Löschen eines Benutzers 4. Suche von Usern 5. Sperren eines Users 6. Logout 20

21 7.5.2 Die LDAP-Verbindung Codeausschnitt: sub connectldap Abbildung 2: Screenshot Login - Nach dem Login $ld = Net::LDAP->new($ldapserver, port=>$ldapport, version => 3); if (!defined $ld $ld <= 0) &_start_html; &_start_head; &_head_title; "<meta http-equiv=\"refresh\" content=\"5; URL=admin.pl\">"; &_head_style; &_end_head; "<p>ldap_server nicht gefunden</p>"; &_end_body; &_end_html; $status = $ld->bind(dn => $rootconnection, password => $passwd); if ($status->code!= 0) #$this->login("unable to connect to LDAP Server!"); #$this->disp_error("can not connect to LDAP! ".$status, undef); &_start_html; &_start_head; &_head_title; "<meta http-equiv=\"refresh\" content=\"5; URL=admin.pl\">"; 21

22 &_head_style; &_end_head; "<p>konnte Benutzer nicht autentifizieren</p>"; &_end_body; &_end_html; Vor jeder Interaktion mit dem LDAP ist eine Anmeldung notwendig diese Anmeldung wird in der Perlscript Funktion connectldap erstellt. Mit der oben beschriebenen Bibliothek Perl-LDAP wird mittels der Functrion new()des Objektes NET:LDAP ein neuer LDAP-Server eingetragen. Die Funktion new() hat zwei Variablen. Zum einen HOST der in die Hostadresse angegeben wird in unserem Fall muss die Hostadresse in der Konfiguration unter der Variable $LDAPServer und der Hostport unter Variable $LDAPPort eingegeben werden. Und zum anderen die Variabel OPTIONS unter der zum Beispiel die LDAP Version angegeben werden kann. In diesem Fall hier in unserem Beispiel 3. Danach wird über die NET:LDAP Funktion bind() ein User und ein Password an den LDAP gebunden bei unserem Fall ist das die root-connection die auch in einer Konfigurationsvariable angegeben ist mit dem zugehörigen Password, welches aus der Session ausgelesen wird Das Session-Management Alle Sessions werden als Files auf der Platte des Servers gespeichert. Das Handling hier übernimmt die Bibliothek CGI::SESSION. Im Konfigurationsparameter $sessdir wird das Verzeichnis was zur Speicherung der Sessions verwendet werden soll angegeben. Das Session-Management funktioniert folgendermaßen. Sollte der Login in den LDAP mit den eingegebenen Benutzerdaten funktionieren, so eine Session über das CGI::SESSION OBject erstellt. Hierzu wird ein zufälliger MD5 Key erstellt, der dem Client in der URL der LINKS weitergegeben wird. Die Session wird einem MD5 Key zugeordnet und Username und Password in der Session gespeichert. 22

23 Will der Client eine geschützte Funktion aufrufen so wird die Session-ID auf ihr vorkommen überprüft und geprüft, ob sie nicht bereits abgelaufen ist. Sollte dies der Fall sein, gewährt das Script keinen Zugriff. Ansonsten wird eine LDAP Verbindung erstellt und die jeweilige Funktion ausgeführt Die Suche Die Suche ist für jeder Funktion notwendig bei der ein Anwender einen Benutzer erstellen, verändern, löschen oder sperren will. Für die Suche wurde eine Suchmaske entwickelt. (siehe Abbildung 1). Abbildung 3 : Screenshot Suchauswahl Es gibt 4 Attributfelder in den nach bekannten Feldern gesucht werden kann, hier sind auch die Wildcards * für beliebig viele Zeichen und % für genau ein Zeichen möglich. Zusätzlich können die anzuzeigenden LDAP Felder ausgewählt werden. Nachdem dies erfolgt ist. Wird das Suchergebnis in einer neuen Suchmaske angezeigt. Die Suche wird durch die NET:LDAP Funktion search() ausgelöst. Hier werden die Parameter Suchfilter filter, die Suchtiefe scope, die Suchbasis base und die anzuzeigenden Attribute attributes mitgegeben. Das Ergebnis der Suche wird in einer Maske ausgegeben. Diese ist in Abbildung 4 zu sehen. 23

24 Abbildung 4 : Screenshot - Suchergebnis Das Einfügen, Ändern, Löschen, Sperren eines Benutzers Beim Einfügen werden die in der Maske des Perlscriptes eingegeben Daten einem NET:LDAP:ENTRY Objekt hinzugefügt.sollten keine fehlenden Daten vorhanden sein oder sollte der Benutzer nicht existieren, wird er dem LDAP Directory hinzugefügt. Beim Ändern und Löschen bzw. Sperren wird zuerst eine Suche nach einem bestimmten User durchgeführt. Auf den gefundenen User wird dann die Funktion ausgeführt. Alle ausgeführten Funktionen sind im Objekt NET:LDAP:ENTRY zu finden. Die genaue Funktionsbeschreibungen kann man in der Bibliothek nachlesen, weil eine Erklärung zu umfangreich werden würden. Der Link lautet: Bemerkung: Wir haben beim Prototyp für das Sperren eines Users seine Login Shell einfach /bin/false gesetzt. Sicherlich gibt es noch andere Möglichkeiten einen Benutzer im POSIX Schema zu sperren, aber diese hat sich im Allgemeinen durchgesetzt. 24

25 7.5.6 Der Logout Beim Logout wird die Session aus dem Session Directory des Servers gelöscht. Danach wird zur Login Seite weitergeleitet. Um an die gesicherten Funktionen zu kommen ist diese Session also nicht mehr vorhanden. 8 Der Quellcode - Komplett #!/usr/bin/perl -w use CGI; use Digest::MD5 qw(md5_hex); use Net::LDAP; use CGI::Session; #Main Configuration LDAP my $ldapserver = " "; my $ldapport = 389; my $basedn ="dc=gm,dc=fh-koeln,dc=de"; my $ldap_userbase = 'ou=people,'; my $objectcl = 'account'; my $scope = 'one'; #Subconfiguration LDAP my $ldapprimarykey = 'uid'; my $ldapdisablefield = 'loginshell'; my $ldapdisablevalue = '/bin/false'; my $ldappasswordfield = 'userpassword'; my $ld=""; my $status=""; = ('objectclass', 'uidnumber', 'homedirectory', 'loginshell', 'gidnumber', 'uid', 'shadowmax', 'shadowwarning', 'userpassword'); my $rootconnection='cn=admin,dc=gm,dc=fhkoeln,dc=de'; #Session-Management my $sessdir = "/tmp"; #Start Program $query = new CGI; my $connection_mode = 3; $TITLE="Fachhochschule Koeln - Open LDAP Admin"; my $path_info = $query->path_info; my $script_name = $query->script_name; my $doit = $query->param('doit'); my $command =$query->param('command'); my $uid = $query->param('uid'); my $passwd = $query->param('passwd'); my $errormessage =$query- >param('errormessage'); my $sessionid=$query->param('sessionid'); if(defined $command) #Session-Überprüfung my $session2=""; if(defined $sessionid) $session2 >load("driver:file", Directory=>$sessdir); if($session2->is_empty) =CGI::Session- $sessionid, &_start_html; &_start_head; &_head_title; "<meta http-equiv=\"refresh\" content=\"5; URL=admin.pl\">"; &_head_style; &_end_head; "<p>session nicht vorhanden</p>"; &_end_body; &_end_html; if($session2->is_expired) &_start_html; &_start_head; &_head_title; "<meta http-equiv=\"refresh\" content=\"5; URL=admin.pl\">"; &_head_style; &_end_head; "<p>session mit Session- ID:".$sessionid."ist abgelaufen</p>"; &_end_body; &_end_html; else &_start_html; &_start_head; &_head_title; "<meta http-equiv=\"refresh\" content=\"5; URL=admin.pl\">"; &_head_style; &_end_head; "<p>keine SessionID vorhanden</p>"; &_end_body; &_end_html; #Session überprüft $uid=$session2->param('uid'); $passwd=$session2->param('passwd'); if($command eq "start") &_start_html; &_start_head; &_head_title; 25