LDAP-Clientverwaltung
Inhaltsverzeichnis
Einleitung
Diese Dokumentation gibt eine allgemeine Einfuehrung in das Thema LDAP. Ausserdem wird der clientseitige Umgang mit Open-LDAP am Fachbereich 3 der Universitaet Bremen beschrieben.
Viele der OpenLDAP-spezifischen Punkte werden nur grundlegend erkleart. Eine ausfuehrliche Dokumentation ist unter http://www.openldap.org/ zu finden.
1. Was ist LDAP?
LDAP steht fuer 'Lightweight Directory Access Protocol' und ist ein Protokoll, welches die Kommunikation zwischen Clients und einem Verzeichnisdienst beschreibt. Ein solcher Verzeichnisdienst ist eine im Netzwerk verfuegbare, hierarchische Datenbank, die Daten objektorientiert in einer Baumstruktur ablegt.
Angesprochen werden solche Objekte ueber den sogenannten Distinguished Name (DN), der aus seinem relativen Namen (Relative Distinguished Name, kurz RDN) und den RDNs der uebergeordneten Objekte bis zur Verzeichnisbasis zusammengesetzt ist.
Ein RDN ist dabei immer ein Attritbut des jeweiligen Objektes, in Verbindung mit seinem Wert. Hat ein Objekt z.B. ein Attribut 'cn' (common name), dessen wert 'egon' ist, kann der RDN des Objektes 'cn=egon' sein.
Welches Attribut fuer den RDN verwendet wird, ist letztendlich dem Ersteller des Objektes ueberlassen. Der Einfachheit und Datenkonsistenz wegen sollte es aber eine Einigung auf ein Bestimmtes RDN-Attribut fuer die jeweilig verwendeten Objekttypen geben. (Bei UNIX-Accounts ist es z.B. 'uid')
Angenommen dem Objekt mit dem RDN 'cn=egon' ist nur noch ein Objekt 'ou=People' (ou = organizationalUnit) uebergeordnet, welches wiederum der Basis 'dc=informatik,dc=uni-bremen,dc=de' untergeordnet ist, lautet der DN des Objektes 'cn=egon,ou=People,dc=informatik,dc=uni-bremen,dc=de'.
In der Regel koennen jedem Objekt in der Verzeichnisstruktur weitere Objekte untergeordnet werden. Ausnahme stellen dabei z.B. die uebergeordneten RDNs der Verzeichnisbasis dar. Ist z.B. Serverseitig der DN 'dc=informatik,dc=uni-bremen,dc=de' als Datenbasis festgelegt worden, koennen Daten nur untergeordnet zu diesem DN abgelegt werden. Uebergeordnete DNs, wie z.B. 'dc=uni-bremen,dc=de' muessten auf dem Server als eigenstaendige Datenbasis definiert werden, damit dort Daten abgelegt werden koennen.
Ein Objekt in einem Verzeichnis ist eine Sammlung von Attributen, die jeweils einen Typ haben und einen oder mehrere Werte enthalten. Die Syntax der Werte ist dabei abhaengig vom Attributtyp, genauso, wie die Anzahl von Werten, die ein Attribut aufnehmen kann.
Um eingrenzen zu koennen, welche Attribute ein bestimmtes Objekt aufnehmen kann, gibt es das besondere Attribut 'objectClass', welches schematische Regeln fuer ein Objekt festlegt, an die es sich halten muss. Dabei kann ein Objekt auch mehrere Objektklassen enthalten.
In einer Objektklasse wird z.B. festgelegt, welche Attribute ein Objekt enthalten muss und welche optional zur Verfuegung stehen. Ein Objekt kann keine Attribute aufnehmen, die nicht in mindestens einer seiner Objektklassen definiert sind und muss mindestens die Pflichtattribute aller seiner Objektklassen enthalten.
Attribute und Objektklassen werden in sogenannten Schemas definiert, die serverseitig eingebunden werden.
Um ungewollte Zugriffe auf Baeume, Objekte oder Attribute zu verhindern, stellt LDAP verschiedene Mechanismen zur Authentifikation von Benutzern und dem Einrichten von Zugriffsberechtigungen fuer diese zur Verfuegung.
2. Allgemeine Zugriffsmoeglichkeiten auf die Server/das LDAP-Verzeichnis
In diesem Abschnitt werden einige Werkzeuge erklaert, mit deren Hilfe man auf ein LDAP-Verzeichnis zugreifen kann.
Die beiden Standardports, die von LDAP verwendet werden, sind einmal der Port 389 (ldap://) fuer unverschluesselte Verbindungen und 636 (ldaps://) auf dem die Daten per TLS/SSL gesichert sind.
Da ldaps:// aber nicht offiziell dokumentiert ist, solle man die empfohlene Methode 'start_tls' ueber Port 389 (dazu spaeter mehr) vorziehen.
Fuer die Authentifikation am Server gibt es verschiedene Moeglichkeiten. Einmal die sogenannte 'simple bind' Methode, bei der die Authentifizierungsdaten einfach in Klartext an den Server uebermittelt werden. Diese Methode sollte aus Sicherheitsgruenden nur in Verbindung mit einer gesicherten TLS/SSL-Verbindung verwendet werden.
Die zweite Methode ist 'Simple Authentication and Security Layer' (SASL), welche wiederum verschiedene Mechanismen zur gesicherten Authentifizierung bereit stellt.
Welche Methode man bevorzugt, ist einem selbst ueberlassen. In diesem Dokument wird jedoch nur auf das 'simple bind' in Verbindung mit einer TLS/SSL-Verbindung eingegengen. Aus den offiziellen Dokumentationen der jeweiligen Tools kann man jedoch alles entnehmen, was fuer eine SASL- gestuetzte Authentifikation erforderlich ist.
SASL wird von den momentan laufenden LDAP-Servern nicht unterstuetzt. Daher wird ausdruecklich empfohlen, beider allen 
Anfrage an den Server, die nicht als anonymer Benutzer getaetigt werden, TLS/SSL zu verwenden.
2.1 Access Control List
LDAP ermoeglicht die Verwendung komplexer ACLs, mit dessen Hilfe der Zugriff auf die Daten im Verzeichnis von ganzen Baeumen bis auf einzelne Attribute beschraenkt werden koennen. Als Zugriffskriterien lassen sich dabei Gruppenmitgliedschaften, allgemein LDAP-Filter, IP-Adressbereiche, eine mindestanforderung an die Verschluesselung und mehr angeben.
Die meisten dieser Kriterien sind auf Accounts im LDAP-Verzeichnis bezogen. Prinzipiell wird jedes Objekt in der Datenbank, welches das Attribut 'userPassword' enthaelt als Account behandelt und laesst somit eine Authentifizierung zu.
Es koennen unter anderem die folgenden Zugriffsarten gegeben werden: (eine hoehere Stufe schliesst die darunterliegenden ein. So darf 'read' z.B. auch 'compare' und 'auth')
none Der User hat keinerlei Zugriff.
auth Ein User schickt dem Server seine Benutzerdaten.
Der Server vergleicht diese und gewahrt entweder Zugriff oder
quittiert mit einem Fehler.
compare Ein User schickt einen Datensatz an den LDAP-Server, mit einem DN
eines bestehenden. Der Server vergleich diese und liefert true
oder false.
read Der User darf die Daten lesen.
write Der User darf die Daten veraendern.Dadurch lassen sich Dummyuser anlegen, die nur fuer die Verteilung von Zugriffsrechten verwendet werden koennen. Auf den aktiven LDAP-Servern sind solche Dummyuser unter dem DN 'ou=admin,dc=informatik,dc=uni-bremen,dc=de' abgelegt und werden z.B. verwendet, um bestimmten Skripten Zugriff auf nur die Daten zu gewaehren, die auch wirklich notwenidig sind.
Die Zugriffe auf die Daten im LDAP-Verzeichnis des FB3 sind nach den folgenden Kriterien beschraenkt: (Ausszug)
Benutzerdaten (Ausser Passwoerter)
Mitglieder der Gruppe fb3-t write Dummyuser uid=nsswitch,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=syncrepl,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=openid,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=adduser,ou=System,dc=informatik,dc=uni-bremen,dc=de write Alle authentifizierten Benutzer, bezogen auf ihre eigenen Daten read
Passwoerter
Mitglieder der Gruppe fb3-t write Dummyuser uid=syncrepl,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=adduser,ou=System,dc=informatik,dc=uni-bremen,dc=de write Alle authentifizierten Benutzer, bezogen auf ihr eigenes Passwort write Anonyme Benutzer auth
Gruppen
Mitglieder der Gruppe fb3-t write Dummyuser uid=nsswitch,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=group,ou=System,dc=informatik,dc=uni-bremen,dc=de write Dummyuser uid=openid,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=syncrepl,ou=System,dc=informatik,dc=uni-bremen,dc=de read
Netgroups
Dummyuser uid=nsswitch,ou=System,dc=informatik,dc=uni-bremen,dc=de read Dummyuser uid=netgroup,ou=System,dc=informatik,dc=uni-bremen,dc=de write Dummyuser uid=syncrepl,ou=System,dc=informatik,dc=uni-bremen,dc=de read
auto_home
Dummyuser uid=autofs,ou=System,dc=informatik,dc=uni-bremen,dc=de write Alle read
alle restlichen Daten
Anonyme Benutzer auth Dummyuser uid=syncrepl,ou=System,dc=informatik,dc=uni-bremen,dc=de read
Die Dummyuser mit den Schreibrechten sind fuer die Synchronisationsskripte erstellt worden. Der Dummyuser 'nsswitch' ist auf allen Clienthosts eingetragen, damit das System Zugriff auf die entsprechenden Daten hat. Der Dummyuser 'syncrepl' wird fuer die Synchronisation der Replicaserver benoetigt und hate Leserechte auf das gesamte Verzeichnis.
2.2 LDIF
LDIF ist die Abkuerzung fuer 'LDAP Data Interchange Format' und beschreibt ein textbasiertes Datenformat zur Darstellung von Informationen in einem LDAP-Verzeichnis.
Da LDAP lediglich ein Kommunikationsprotokoll fuer Verzeichnisdienste definiert, deren interne Datendarstellung herstellerspezifisch sein kann, wurde LDIF entwickelt, um einen einfachen Austausch von Daten auch zwischen heterogenen Systemen zu ermoeglichen.
Die erste Zeile eines Datensatzes enthaelt dabei immer den DN, gefolgt von von den Objektklassen, den Attributen und deren Werten. Der Abschluss einer Objektdefinition ist eine Leerzeile. Wie bereits weiter oben erwaehnt, kann ein Attribut, je nach Typ, auch mehrere Werte aufnehmen. In LDIF wird dies einfach durch das wiederholte auffuehren eines Attributes mit einem jeweils anderen Wert dargestellt.
Fuer die Darstellung gilt das Format '<Attributname>: <Attributwert>'
Laesst sich ein Attributwert nicht als Text darstellen, so wird er in base64-Kodierung nach einem doppelten Doppelpunkt (::) nach dem Attributnamen dargestellt.
'<Attributname>:: <base64-kodierter Attributwert>'
Dies wird z.B. fuer das Abbilden von Grafiken benoetigt. Eine JPEG-Grafik koennte z.B. wie folgt in LDIF abgebildet werden:
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG ...
Bei mehrzeiligen Wertzuweisungen ist zu beachten, dass nach einem Zeilenumbruch ein einzelnes Leerzeichen anzeigt, dass die Zeile eine Fortsetzung der vorangegangenen Zeile ist.
Hier ein Beispiel fuer einen Datensatz im LDIF Format:
dn: cn=testgruppe,ou=Group,dc=informatik,dc=uni-bremen,dc=de objectClass: top objectClass: posixGroup cn: testgruppe userPassword: * gidNumber: 123 memberUid: mitglied1 memberUid: mitglied2 memberUid: ...
LDIF kann jedoch nicht nur vollstaendige Datensaetze abbilden, sondern auch Aenderungen an bestehenden Objekten beschreiben. In diesem Fall wird nach dem DN in der ersten Zeile des Datensatzes der Modus der Modifikationen angegeben, gefolgt von einer oder mehreren Aenderungsanweisungen, die jeweils durch eine Zeile die nur ein '-' enthaelt, voneinander getrennt werden.
Moechte man z.B. einem Objekt ein Attribut hinzufuegen und den Wert eines anderen Attributes veraendern, koennte ein LDIF-Datensatz wie folgt aussehen:
dn: cn=testgruppe,ou=Group,dc=informatik,dc=uni-bremen,dc=de
changetype: modify
add: description
description: Testeintrag im LDAP-Verzeichnis
-
replace: userPassword
userPassword: {crypt}neuespasswortEin weiteres Beispiel zum Umbenennen und Verschieben eines Objektes:
dn: cn=testgruppe,ou=Group,dc=informatik,dc=uni-bremen,dc=de changetype: modrdn newrdn: cn=gruppe deleteoldrdn: 1 newsuperior: dc=informatik,dc=uni-bremen,dc=de
Weitere Beispiele und Beschreibungen sind in den Manpages unter ldif(5) zu finden.
Die technischen Spezifikationen von LDIF sind auf http://tools.ietf.org/html/rfc2849 einsehbar.
2.3 OpenLDAP-Utilities
Die OpenLDAP-Software bietet neben einem Serverprogramm auch diverse Client-Tools fuer die Kommunikation mit einem LDAP-Server an. Diese Tools arbeiten mit dem unter 2.1 beschriebenen LDIF.
Die drei wichtigsten Tools sind hier ldapsearch, ldapmodify und ldapdelete. Diese Tools verwenden eine gemeinsame, allgemeine Konfigurationsdatei ldap.conf. Genauso wie ldappasswd, mit dessen Hilfe man Passwoerter im LDAP-Verzeichnis aendern kann.
ACHTUNG: Die LDAP-Tools unter Solaris sind genauso benannt, wie die Open- LDAP-Tools, unterscheiden sich jedoch in der Benutzung! Die Unterscheide werden unter Punkt 2.4 genauer beschrieben.
2.3.1 ldapsearch
ldapsearch durchsucht den angegebenen LDAP-Server nach einem definierbaren Suchfilter und gibt die gefundenen Daten in LDIF zurueck.
Die allgemeinen Verbindungsdaten, wie Serveradresse, eventuelle Verschluesselung, Basis-DN fuer Suchanfragen usw. entnimmt das Programm der allgemeinen Konfigurationsdatei ldap.conf. Ist diese Datei nicht vorhanden oder noch nicht korrekt konfiguriert bzw. wenn man eigene Verbindungsdaten verwenden moechte, kann man diese auch als Option dem Programm uebergeben.
Beim folgenden Beispiel wird angenommen, dass keine ldap.conf vorhanden ist und alle Daten anonym lesbar und unter dem Basis-DN 'dc=informatik,dc=uni-bremen,dc=de' abgelegt sind:
ldapsearch -x -H "ldaps://ldap1.informatik.uni-bremen.de" \ -b "dc=informatik,dc=uni-bremen,dc=de" -s sub
-x gibt an, dass das 'simple bind' Verfahren zur Authentifizierung am Server verwendet werden soll. Gibt man diese Option nicht an, wird per default SASL verwendet. Durch das Weglassen von Authentifizierungsdaten wird man automatisch als anonymer Benutzer authentifiziert.
Mit der Option -H kann man einen oder mehrere, durch Leerzeichen getrennte, Server-URIs angeben. Eine weitere Option zum Definieren eines anzusprechenden Servers ist die Option -h, welche einen Hostnamen oder eine IP-Adresse erwartet. -H ist den Manpages nach die bevorzugte Methode Serveradressen anzugeben.
-b (base) definiert den Basis-DN, von dem die Suchanfrage ausgeht, waehrend -s (scope) angibt, wie tief die Suche in die untergeordneten Objekte vordringen soll. Die moeglichen Werte fuer -s sind 'base', was bedeutet, dass nur das Basis-DN-Objekt durchsucht wird, 'one', das alle direkt dem Basis-DN untergeordneten Objekte einschliesst und 'sub', was saemtliche Unterverzweigungen in die Suche einschliesst. Der Defaultwert fuer -s ist in der Regel 'sub'. Der Default fuer -b ist auf den LDAP-Servern des FB3 'dc=informatik,dc=uni-bremen,dc=de'.
Das Beispielkommando wuerde also saemtliche (anonym lesbaren) Daten, die im LDAP-Verzeichnis unter der Basis "dc=informatik,dc=uni-bremen,dc=de" abgelegt sind, ausgeben.
Durch die 'ldaps://'-Schreibweise der Server-URI, wird die Verbindung zum Server automatisch ueber Port 636 abgwickelt und dabei TLS/SSL verschluesselt.
Es ist ausserdem moeglich auch die Kommunikation auf Port 389 (ldap://) zu verschluesseln, indem man sich der 'start_tls'-Funktion bedient. Diese kann durch die Option -Z (TLS versuchen) bzw. -ZZ (TSL erzwingen) gestartet werden. Dabei ist zu beachten, dass sich 'ldaps://' und 'start_tls' nicht kombinieren lassen.
ldapsearch -x -ZZ -H "ldap://ldap1.informatik.uni-bremen.de" \ -b "dc=informatik,dc=uni-bremen,dc=de" -s sub
Bis auf -x und -Z[Z], koennen alle diese Optionen in der allgemeinen ldap.conf definiert werden. Die Authentifikation per SASL ist bei den OpenLDAP-Utilities ein unveraenderbarer default. Da die Server kein SASL unterstuetzen, muss immer ein -x angegeben werden.
Ausserdem ist die Kombination ldap:// und -ZZ ldaps:// vorzuziehen, da ldaps:// nicht offiziell dokumentiert oder spezifiziert ist. Daher sollte immer mit ldap:// und -ZZ gearbeitet werden.
Fuer die weiteren Beispiele wird angenommen, dass eine korrekt konfigurierte ldap.conf vorhanden ist und alle Verbindungsbedingten Daten automatisch von ldapsearch bezogen werden.
Um das Suchergebnis einzugrenzen, kann man einen Filter angeben, der mehrere, logisch miteinander verknuepfbare, Bedingungen zulaesst. LDAP- Suchfilter sind nach RFC 4515 definiert. (http://www.rfc-editor.org/rfc/rfc4515.txt)
Wird kein Filter angegeben, wird der default-Filter '(objectClass=*)' angewendet.
Einige Beispiele fuer Suchfilter:
(objectClass=posixAccount) |
Es werden nur Objekte zurueckgegeben, die die Objektklasse 'posixAccount' enthalten. |
(!(objectClass=posixAccount)) |
Es werden nur Objekte zurueckgegeben, die nicht die Objektklasse 'posixAccount' enthalten. |
(&(objectClass=posixAccount)(!(uid=benutzer))) |
Es werden nur Objekte zuruckgegeben, die die Objektklasse 'posixAccount' enthalten und die ein Attribut 'uid' haben, dessen Wert nicht 'benutzer' ist. |
(|(uid=benutzer)(uid=t*)) |
Es werden nur Objekte zurueckgegeben, die ein Attribut 'uid' haben, welches den Wert 'benutzer' enthaelt oder mit dem Zeichen 't' beginnt. |
(&(objectClass=posixAccount)(|(uid=benutzer)(uid=test))) |
Es werden nur Objekte zurueckgegeben, die die Objektklasse 'posixAccount' enthalten und ein Attribut 'uid' haben, welches den Wert 'benutzer' oder 'test' enthaelt. |
Filterbedingungen werden nur auf Attribute angewendet, die auch in einem Objekt vorhanden sind. Enthaelt ein Objekt im Suchbereich ein im Filter angegebenes Attribut nicht, so wird die ensprechende Bediungung bei diesem Objekt immer als nicht zutreffend behandelt.
Beispiel: Es sollen alle Objekte mit der Objektklasse 'posixAccount' mit dem Attribut 'uid=test' ausgegeben werden:
ldapsearch -x -ZZ "(&(objectClass=posixAccount)(uid=test))"
Sucht man auf diese Weise im LDAP-Verzeichnis, werden jeweils alle lesbaren Attribute der gefundenen Objekte angezeigt. Moechte man sich nur bestimmte Attribute anzeigen lassen, kann man diese einfach, nacheinander und mit Leerzeichen getrennt, hinter dem Filter angeben. Der DN wird aber in jedem Fall angezeigt und laesst sich nicht ausblenden.
Das folgende Kommado zeigt z.B. von allen gefundenen Objekten jeweils nur die Attribute 'uid' und 'objectClass' an, sofern diese im jeweiligen Objekt vorhanden sind.
ldapsearch -x -ZZ "(&(objectClass=posixAccount)(uid=test))" uid objectClass
Zu beachten waere noch, dass jedes Objekt im LDAP-Verzeichnis Attribute enthaelt, die in der Regel unsichtbar sind und automatisch vom slapd erzeugt werden, die sogenannten 'operativen Attribute'. Diese operativen Attribute enthalten unter anderem eine interne, im Verzeichnis einzigartige ID, den 'Universally Unique Identifier' (UUID), den Zeitpunkt an dem das Objekt erstellt wurde, den DN des Benutzers, der das Objekt erstellt hat und einiges mehr.
Die operativen Attribute eines Objektes kann man sich durch ein '+' in der Attributliste anzeigen lassen.
ldapsearch -x -ZZ "(objectClass=posixAccount)" +
Weitere Beispiele und eine Dokumentation aller verfuegbaren Optionen sind in der Manpage zu ldapsearch (ldapsearch(1)) zu finden.
2.3.2 ldapmodify
ldapmodify ermoeglicht es, Daten in LDIF in ein LDAP-Verzeichnis einzugeben. Das Tool verwendet dabei dieselben Verbindungsoptionen wie ldapsearch bzw. dieselbe Konfigurationsdatei ldap.conf.
Mit der Option -f kann man den Pfad zu einer Datei uebergeben, die LDIF- Daten enthaelt. Ansonsten erwartet ldapmodify eine Eingabe von Daten ueber die Standardeingabe.
Hat man mehrere Datensaetze hintereinander in einer Datei abgelegt, kann die Option -c sehr nuetzlich sein. Sie bewirkt, dass fehlerhafte Datensaetze uebersprungen werden und beim naechsten weitergemacht wird. Gibt man diese Option nicht an, bricht das Programm die laufende Operation ab, wenn die LDIF-Daten fehlerhaft sind, oder der Server einen Fehler zurueckgibt, z.B. weil ein Datensatz bereits vorhanden ist.
Standardmaessig erwartet ldapmodify Modifikationsanweisungen in LDIF. Mit der Option -a kann man jedoch auch vollstaendige Datensaetze in das LDAP- Verzeichnis einlesen.
Moechte man z.B. folgenden Datensatz in das Verzeichnis einfuegen, legt man diesen am besten in einer Datei ab und fuehrt das darauf folgende Kommando aus:
test.ldif
dn: cn=test,dc=informatik,dc=uni-bremen,dc=de
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: test
userPassword: {crypt}passwordldapmodify -x -ZZ -a -f test.ldif
Soll ein Datensatz veraendert werden, koennte dies z.B. so aussehen:
change.ldif
dn: cn=test,dc=informatik,dc=uni-bremen,dc=de
changetype: modify
replace: userPassword
userPassword: {crypt}neuesPasswortldapmodify -x -ZZ -f change.ldif
Da anonyme Benutzer normalerweise keine Schreibrechte im LDAP-Verzeichnis haben, muesste der Server diese Schreibvorgaenge jedoch mit einer Fehlermedung quittieren. Um sich am Server zu authentifizieren, kann man die Optionen -D und -W/-w verwenden.
Mit -D wird ldapmodify der DN eines Accountobjektes uebergeben, welches idealerweise die entsprechenden Berechtigungen hat, die gewuenschten Schreiboperationen durchfuehren zu koennen. -w erwartet, dass das Passwort des Accountobjektes in Klartext in der Kommandozeile uebergeben wird. Dies ist z.B. fuer skriptgesteuerte Aenderungen am LDAP-Verzeichnis nuetzlich. Durch die Benutzung von -W kann man das Passwort aber auch in einen Prompt eingeben.
-D und -W/-w verwenden die Methode 'simple auth' und sollten daher in Verbindung mit TLS/SSL angewendet werden.
ldapmodify -x -ZZ -f change.ldif -D "cn=admin,dc=informatik,dc=uni-bremen,dc=de" -W
ODER
ldapmodify -x -ZZ -f change.ldif -D "cn=admin,dc=informatik,dc=uni-bremen,dc=de" -w passwort
Weitere Beispiele und eine Dokumentation aller verfuegbaren Optionen sind in der Manpage zu ldapmodify (ldapmodify(1)) einsehbar.
2.3.3 ldapdelete
Im Gegensatz zu ldapsearch und ldapmodify arbeitet ldapdelete nicht mit LDIF, sondern mit einfachen DNs. Es gelten dieselben Optionen fuer Verbindungen zum Server wie bei ldapsearch und ldapmodify.
Wie ldapmodify verfuegt ldapdelete ueber eine Option -c, die bewirkt, dass Fehler zwar gemeldet werden, das Programm aber bis zum Ende weiterlaeuft.
Als Eingabe wird ein DN oder eine durch Zeilenumbrueche getrennte Liste von DNs erwartet, die aus dem LDAP-Verzeichnis entfernt werden sollen.
Als Quelle dient entweder die Kommandozeile, die Standardeingabe, oder eine Datei (-f).
Auch hier ist zu beachten, dass anonyme Benutzer in der Regel nicht die Berechtigung haben, Daten im LDAP-Verzeichnis zu veraendern. Darum ist es, wie bei ldapmodify, noetig sich am Server zu authentifizieren.
Will man z.B. den im ldapmodify-Beispiel erstellten Datensatz wieder aus dem Verzeichnis entfernen, kann man folgendes Kommando anwenden:
ldapdelete -x -ZZ -D "cn=admin,dc=informatik,dc=uni-bremen,dc=de" -W "cn=test,dc=informatik,dc=uni-bremen,dc=de"
Weitere Beispiele und eine Dokumentation aller verfuegbaren Optionen sind in der Manpage zu ldapdelete (ldapdelete(1)) einsehbar.
2.3.4 ldappasswd
ldappasswd nutzt dieselben Verbindungsoptionen wie alle anderen OpenLDAP- Utilities. Um Passwoerter zu aendern, muss man dem Tool Authentifizierungsdaten fuer einen LDAP-Benutzer mit entsprechenden Schreibrechten uebergeben, sowie den Accountnamen, dessen Passwoer geaendert werden soll.
Um z.B. als Benutzer 'testuser' sein eigenes Passwort zu aendern, kann man folgendes Kommando verwenden:
ldappasswd -D "uid=testuser,ou=People,dc=informatik,dc=uni-bremen,dc=de" -W -x -ZZ
Da keine weiteren Optionen uebergeben wurden, erstellt der LDAP-Server automatisch ein zufaelliges Passwort und gibt dieses danach aus, sofern es erfolgreich ins Verzeichnis geschrieben werden konnte.
Moechte man ein eigenes Passwort setzen, kann man dies mit den Optionen -s bzw. -S angeben. -s erwartet das neue Passwort in der Kommandozeile, waehrend -S einen Prompt zur Verfuegung stellt.
ldappasswd-D "uid=testuser,ou=People,dc=informatik,dc=uni-bremen,dc=de" -W -s pwd -x -ZZ
ODER
ldappasswd -D "uid=testuser,ou=People,dc=informatik,dc=uni-bremen,dc=de" -x -W -S -ZZ
Um das Passwort eines Benutzers zu aendern, der nicht dem entspricht, als der man sich mit -D am Server authentifiziert, kann man einfach den DN des jeweiligen Benutzers uebergeben.
Beispiel:
ldappasswd -x -ZZ -D "cn=admin,dc=informatik,dc=uni-bremen,dc=de" -W -S "uid=testuser,ou=People,dc=informatik,dc=uni-bremen,dc=de"
Ob und wie per ldappasswd erstellte Passwoerter gehasht werden, wird auf der Serverseite festgelegt.
2.4 Solaris LDAP-Utilities
Wie unter Punkt 2.3 beschrieben, haben die LDAP-Tools unter Solaris die selben Namen, wie die OpenLDAP-Tools und sind daher leicht zu verwechseln. Die grundlegende Bedienung ist zwar die selbe, wie bei den OpenLDAP-Tools, jedoch nicht voellig identisch.
So erwarten die Sun-Tools z.B. immer einen Base-DN (-b) und einen Suchfilter. Beispiel:
ldapsearch -x -b "dc=informatik,dc=uni-bremen,dc=de" obejctclass=*
Ausserdem muss bei einer SSL/TLS-Verbindung anscheinend immer der Pfad zum Zertifikat angegeben werden (-P).
ldapsearch -x -Z -b "dc=informatik,dc=uni-bremen,dc=de" -P /var/ldap obejctclass=*
2.5 Perl-Skripte
Perl bietet mit der Bibliothek Net::LDAP eine komfortable Moeglichkeit eine Verbindung zu einem LDAP-Server herzustellen und Datensaetze aus ihm auszulesen und zu veraendern.
Dabei ist es sowohl moeglich Daten in LDIF zu importieren/exportieren, als auch ueber entsprechende Methoden Daten in oder aus Variablen zu lesen/schreiben.
Die benoetigten Dateien und eine ausfuehrliche Dokumentation sind unter http://ldap.perl.org/ zu finden.
Die meisten Linux Distributionen sollten diese Lib in ihren Standard- Repositories haben. (z.B. perl-LDAP unter Fedora 7 oder libnet-ldap-perl unter Debian 4)
Da einige der ueberarbeiteten und neuen Verwaltungsskripte auf diese Bibliothek zurueckgreifen (mehr unter Abschnitt 5.), sollte diese zumindest auf allen Systemen, von denen aus administrative Aufgaben erfuellt werden, installiert sein.
2.6 .htaccess
Mit Webservern, die LDAP unterstuetzen, kann auch .htaccess Authentifizierungsdaten von einem LDAP-Server beziehen.
Wichtige Voraussetzung bei Apache 2.2 die Einbindung der Module "mod_ldap" und "mod_authnz_ldap"in der httpd.conf:
LoadModule ldap_module modules/mod_ldap.so LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
und der folgende globale Eintrag in der httpd-ssl.conf:
LDAPTrustedGlobalCert CA_BASE64 /Pfad_zum_Root_Zertifikat/cacert.crt
Im nachfolgenden ".htaccess" Beispiel koennen sich nur Mitglieder der Gruppe fb3t mit ihrem unix-Passwort anmelden:
AuthType Basic AuthName "private area" AuthBasicProvider ldap AuthLDAPURL "ldaps://ldapfarm.informatik.uni-bremen.de/ou=People,dc=informatik,dc=uni-bremen,dc=de?uid?sub?(objectClass=*)" AuthLDAPBindDN uid=nsswitch,ou=System,dc=informatik,dc=uni-bremen,dc=de AuthLDAPBindPassword "secret" AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off Require ldap-group cn=fb3t,ou=Group,dc=informatik,dc=uni-bremen,dc=de
Eine ausfuehrliche Dokumentation der Apache-Module 'mod_ldap' und 'mod_authnz_ldap' koennen der offiziellen Apache-Dokumentation entnommen werden.
3. Aufbau der Server
Als Server wird der slapd (Standalone LDAP Deamon) von OpenLDAP, mit einem Berkeley-DB-Backend, unter Solaris 10 verwendet.
Die momentan aktiven Server sind ldap-master, ldap1, ldap2 und ldap3.
ldap-master ist dabei der Masterserver von dem die Replicaserver ldap1, ldap2 und ldap3 ihre Daten beziehen. Schreiboperationen sind nur auf dem Masterserver erlaubt. Versucht man schreibend auf einen der Replicaserver zuzugreifen, antwortet dieser mir einem Verweis (referral) auf ldap-master.
Die Synchronisation der Replicaserver erfolgt push-basiert, was bedeutet, dass der Masterserver alle Schreiboperationen ohne Verzoegerung an die Replicaserver weitergibt.
Replicaserver dienen dem Zweck der Daten- und Ausfallsicherheit, sowie der Lastverteilung. So koennen z.B. in der ldap.conf mehrere LDAP-Server angegeben werden, die der Reihe nach angesprochen werden, falls einer nicht erreichbar ist. Alternativ kann man als Serveradresse ldapfarm verwenden, von der aus alle LDAP-Anfragen gleichmaessig auf die Server verteil werden.
3.1 Verwendete Schemas
Wie in Abschnitt 1. beschrieben, kann innerhalb eines Objektes mit dem Attribut 'objectClass' festgelegt werden, welche Attribute das jeweilige Objekt aufnehmen kann. Die verschiedenen Objektklassen und deren Attribute wiederum werden serverseitig in sogenannten Schemas definiert.
In diesem Abschnitt wird nur grob angesprochen, welche Schemas auf den Servern eingebunden sind und was diese enthalten.
core.schema, cosine.schema, inetorgperson.schema
Die Kernschemas, die grundlegende Objektklassen und Attribute nach dem X.500-Standard zur Verfuegung stellen. Standardmaessig im OpenLDAP-Paket enthalten.
nis.schema
Das NIS-Schema stellt Objektklassen und Attribute zur Abbildung von UNIX- Accounts, Gruppen, Automount-Maps, usw. im Verzeichnisdienst zur Verfuegung. Im OpenLDAP-Paket enthalten.
samba.schema
Das Samba-Schema ermoeglicht es, einen Samba-PDC an den LDAP-Service anzubinden, und die zusaetzlichen Accountdaten in UNIX-Accountobjekten einzubetten. Von samba.org bezogen, bzw. im Samba-Paket enthalten.
autofs.schema
Ermoeglicht die Implementierung von einheitlichen Automount-Maps, die mit nur geringem Aufwand plattformuebergreifend anwendbar sind. Im OpenLDAP-Paket enthalten.
userdb.schema
Das userdb-Schema ist ein selbsterstelltes Schema, welches auf das NIS- Schema aufbaut und Attribute aus der Userdatenbank /home/userdb/data/user ergaenzt, die nicht im NIS-Schema enthalten sind.
pykota.schema
Stellt Objektklassen und Attribute zur Verwaltung der Druckerquota bereit. http://www.pykota.com/
3.2 Gliederung der Datenbank
Wie in Abschnitt 1. erwaehnt, ist die Datenbank in einer hierarchischen Baumstruktur organisiert. Die Wurzelebene dieser Struktur enthaelt ein virtuelles Objekt mit der Klasse 'OpenLDAProotDSE', welches aus der Konfiguration des Servers erstellt wird.
Ausserdem enthaelt das rootDSE-Objekt Informationen ueber den Namenskontext der Datenbank, die verwendeten Schemas und die unterstuetzten Zugriffs- und Kontollmethoden.
Der DN des rootDSE-Objektes ist "", also ein leerer String. Eine Liste der eingebundenen Schemas ist unter dem DN "cn=subschemas" zu finden, waehrend die Konfiguration des Servers unter "cn=config" angesprochen werden kann.
Das OpenLDAProotDSE-Objekt eines LDAP-Servers kann wie folgt ausgelesen werden:
ldapsearch -x -ZZ -b "" -s base +
Da fast alle Inhalte des rootDSE-Objektes zu den operativen Attributen gehoeren, muss man das '+' im Bereich der Attributliste angeben, um diese sehen zu koennen.
Die Basis fuer die eigentlichen Nutzdaten des LDAP-Server kann man dem Attribut 'namingContexts' entnehmen. Da ein LDAP-Server mehr als nur eine Datenbasis zur Verfuegung stellen kann, kann dieses Attribut auch mehrere Werte enthalten.
Die Daten unter dem DN "dc=informatik,dc=uni-bremen,dc=de" sind zwecks Strukturierung und Administrierbarkeit unter anderem in die folgenden Organisationseinheiten (ou = organizationalUnit) unterteilt:
3.2.1 Benutzeraccounts (ou=People)
Die Objekte fuer Benutzeraccounts sind unter dem DN "ou=People,dc=informatik,dc=uni-bremen,dc=de" zu finden und aufbauend auf das NIS-Schema als UNIX-Account angelegt. Sie enthalten zusaetzlich noch Samba-Attribute, welche es einem Samba-Server ermoeglichen sie als Samba- Domainaccounts wahrzunehmen. Ausserdem sind Attribute zur Einbindung der Benutzerdatenbank des FB3 enthalten.
Ein vollstaendiges Accountobjekt ist wie folgt aufgebaut:
dn: uid=testaccount,ou=People,dc=informatik,dc=uni-bremen,dc=de
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: UDBentry
objectClass: sambaSamAccount
##### NIS-Attribute
# Accountname
uid: testaccount
# UNIX-Passwort
userPassword: {crypt}mKA7Wa6cUWxUc
# Account ID
uidNumber: 12345
# Gruppen ID
gidNumber: 114
# Login Shell
loginShell: /usr/local/bin/bash
# Pfad zum Homeverzeichnis
homeDirectory: /home/testaccount
# Vollstaendiger Name
cn: Mustermann, Martin
# gecos
gecos: Martin Mustermann, Raum xxx, Tel: 234
##### userdb-Attribute
# Status (S|M|X...)
UDBstatus: S
# Matrikelnummer
UDBmatnr: 23456
# Chipkartennummer
UDBkanr: 1234
# Datum der Accounterstellung
UDBdate: 2008-02-26
# Studiengang/Fachbereich
UDBstuga: Informatik
# Kommentar
UDBcomment: Dies ist ein Kommentar
# Titel
UDBtitel: Dr.
# Grund fuer Accountsperrung
UDBlocked: aus_testgruenden_gesperrt-2008-02-26
# Datum fuer Ablauf des Accounts
UDBexpires: 2008-02-27
# Begruendung fuer Ablauf des Accounts
UDBexpreason: laeuft aus testgruenden ab
# Optionales Attribut zur Zugriffsbeschraenkung auf bestimme Hosts
# Dieses Attribut kann beliebig viele Werte aufnehmen
UDBhostaccess: test
UDBhostaccess: test2
##### Samba-Attribute
# Samba SID
sambaSID: S-1-5-21-3665695678-2981675336-587275816-123
# Passwort
sambaLMPassword: 01FC5A6BE7BC6929AAD3B435B51404EE
sambaNTPassword: 0CB6948805F797BF2A82807973B89537
# Verschiedene von Samba benoetigte Daten
sambaPwdLastSet: 0
sambaPwdCanChange: 0
sambaPwdMustChange: 2147483647
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
# Accountflaggs
sambaAcctFlags: [U]
# Anzeigename, der z.B. im Windows XP Startmenue erscheint
displayName: Martin MustermannZu den verwendeten Objektklassen:
Zum NIS-Schema gehoeren auch die Objektklassen 'posixAccount' und 'shadowAccount', die jeweils einen Eintrag in der /etc/passwd und der /etc/shadow repraesentieren.
Die Objektklasse 'UDBentry' wird im selbst erstellten userdb-Schema definiert und ergaenzt das NIS-Schema um die fuer die Userdatenbank des FB3 benoetigten Attribute.
sambaSamAccount gehoert zum Samba-Schema und ergaenzt Attribute, die ein Samba-Server benoetigt, um ein solches Objekt als Samba-Account mitverwenden zu koennen.
3.2.2 Gruppen (ou=Group)
Gruppen sind unter der Organisationseinheit ou=Group untergebracht und wie bei den Accounts nach dem NIS-Schema als UNIX-Gruppen deklariert. Auch sie enthalten zusaetzlich Samba-Attribute, welche es einem Samba-Server ermoeglicht sie sie als Domaingruppen zu mappen.
Ein vollstaendiges Gruppenobjekt ist wie folgt aufgebaut:
dn: cn=fb3t,ou=Group,dc=informatik,dc=uni-bremen,dc=de objectClass: top objectClass: posixGroup objectClass: sambaGroupMapping ##### NIS Atribute # Name der Gruppe cn: fb3t # Gruppenpasswort userPassword: * # Gruppen ID gidNumber: 495 # Liste von Accountnamen, die Mitglied der Gruppe sind memberUid: bine memberUid: cabo memberUid: cboehm memberUid: cyu memberUid: ..... ##### Samba-Attribute # Samba-SID sambaSID: S-1-5-21-3665695678-2981675336-587275816-2345 # Samba-Gruppentyp sambaGroupType: 2
Zu den verwendeten Objektklassen:
Die Objektklasse 'posixGroup' ist Teil des NIS-Schemas und repraesentiert einen Eintrag in der /etc/group, waehrend 'sambaGroupMapping' aus dem Samba-Schema es einem Samba-Server erlaubt, diese Gruppe als Samba- Domaingruppe zu verwenden.
3.2.3 Mountpoints (ou=Mounts)
Automount-Maps, fuer den Einsatz mit autofs, sind unter dem Objekt mit dem DN "ou=Mounts,dc=informatik,dc=uni-bremen,dc=de" abgelegt, waehrend die Mastermap den DN "ou=auto.master,dc=informatik,dc=uni-bremen,dc=de" traegt.
Eine Mountmap, wie z.B. fuer die Homeverzeichnisse, ist wiederum eine Organisationseinheit, die ou=Mounts untergeordnet ist. Die Mastermap verweist, wie bei dem dateigestuetzten Aequivalent, auf die jeweiligen Maps in ou=Mounts.
Die Verwendung einer LDAP-gestuetzten Mastermap ist optional. Die Verwendung von Automount-Maps wird im Abschnitt fuer die Einrichtung von Clients weiter erlaeutert.
Ein vollstaendiger Mountpointeintrag sieht wie folgt aus:
dn: cn=peter,ou=auto_home,ou=Mounts,dc=informatik,dc=uni-bremen,dc=de objectClass: automount cn: peter automountInformation: pierre:/export/home/stud/&
Ein Eintrag in der Mastermap ist identisch mit einem solchen Mountpoint- Eintrag. Im Attribut 'automountInformation' wird dabei auf die entsprechende Automount-Map verwiesen. Dieser Verweis kann entweder eine lokale Datei sein, die natuerlich auf jedem System, das diese Map verwenden soll, vorhanden sein muss, oder das Schluesselwort 'ldap' gefolgt von einem Doppelpunkt (:) und dem DN der gewuenschten Map im LDAP- Verzeichnis.
Der Eintrag fuer die Homedirectories in der auto.master Map koennte z.B. wie folgt aussehen:
dn: cn=/home,ou=auto.master,dc=informatik,dc=uni-bremen,dc=de objectClass: automount cn: /home automountInformation: ldap:ou=auto_home,ou=Mounts,dc=informatik,dc=uni-br emen,dc=de
3.2.4 Netgroup (ou=Netgroup)
Die Netgroups, die unter anderem fuer den hostbasierten SSH-Zugriff verwendet werden, sind in der Organisationseinheit Netgroup untergebracht, und auch sie bauen auf dem NIS-Schema auf.
Da es bei LDAP, genausow wie bei NIS, zu Problemen kommen kann, wenn eine Netgroup zu viele Mitglieder hat, gibt es auch hier die Moeglichkeit eine Gruppe in mehrere Untergruppen aufzuspalten.
Eine Netgroup koennte z.B. wie folgt abgebildet werden:
dn: cn=trhosts,ou=Netgroup,dc=informatik,dc=uni-bremen,dc=de objectClass: top objectClass: nisNetgroup # Name der Netgroup cn: trhosts # Verweise auf weitere Netgroups memberNisNetgroup: trhosts0 memberNisNetgroup: trhosts1 memberNisNetgrpup: ... dn: cn=trhosts0,ou=Netgroup,dc=informatik,dc=uni-bremen,dc=de objectClass: top objectClass: nisNetgroup # Name der Netgroup cn: trhosts0 # Eintraege in der Netgroup nisNetgroupTriple: (herzog1.home.informatik.uni-bremen.de,-,) nisNetgroupTriple: (herzog2.home.informatik.uni-bremen.de,-,) nisNetgroupTriple: ...
4. Einrichten von Clients
Dieser Abschnitt beschreibt, wie man Clients verschiedener Plattformen so einrichtet, dass Benutzer sich mit LDAP-Accounts an ihnen anmelden koennen.
Skripte, die die Konfiguration der wichtigsten Plattformen automatisch abwickeln, liegen unter /home/ldap bereit.
4.1 Linux allgemein
Die meisten Linux-Distibutionen pflegen die OpenLDAP-Software in ihren Standardrepositories, was das Einrichten von Linux-Clients fuer einen OpenLDAP-Server sehr erleichtert.
Die Pfade zu den Konfigurationsdateien koennen sich dabei in den verschiedenen Distributionen voneinander unterscheiden, doch der Aufbau ist bei allen derselbe.
Zu beachten ist, dass es meistens mindestens zwei Konfigurationsdateien fuer LDAP gibt. Einmal ist da die allgemein fuer die OpenLDAP-Tools geltende und dann noch mindestens eine fuer nsswitch und PAM. Ausfuehrliche Dokumentationen fuer diese Konfigurationsdateien koennen in den jeweiligen Manpages eingesehen werden.
Auf die Konfiguration der Authentifizierung unter bestimmten Distributionen wird in den folgenden Unterpunkten genauer eingegangen. Die allgemeine Konfiguration sollte jedoch ueberall etwa so aussehen, um mit den laufenden LDAP-Servern zu arbeiten:
ldap.conf (in der Regel unter /etc/ldap oder /etc/openldap zu finden)
# Liste von LDAP Servern; ist ein Server nicht ereichbar, wird der jeweils # naechste in der Liste angesprochen (mit Leerzeichen getrennt) uri ldaps://ldapfarm.informatik.uni-bremen.de/ # Basis-DN, unter dem das LDAP-Verzeichnis standardmaessig durchsucht wird base dc=informatik,dc=uni-bremen,dc=de # Verifizierung des Server-CA-Zertifikats erzwingen tls_reqcert demand # Einbindung des root-CA-Zertifikats zur Verifizierung tls_cacert /etc/openldap/certs/cacert.pem
Fuer eine sichere TLS/SSL-Verbindung muss das root-CA-Zertifikate der Zertifizierngsstelle eingebunden werden. (www.ca.informatik.uni-bremen.de) Dabei ist zu beachten, dass bei TLS/SSL gesicherten Verbindungen immer der vollstaendige Domainname des jeweiligen Servers verwendet werden muss!
Moechte man die Serverzertifikate nicht verifizieren, kann man die Option 'tls_reqcert' auf 'never' setzen.
4.1.1 Fedora 7
Folgende Packages werden unter Fedora 7 fuer die Einrichtung einer Benutzerauthentifizierung per LDAP benoetigt:
openldap openldap-clients nss_ldap
(nss_ldap enthaelt gleichzeitig die benoetigten PAM-Bibliotheken.)
Das Paket nss_ldap wird ueber die Datei /etc/ldap.conf konfiguriert, waehrend die Konfigurationsdatei der openldap-client-Tools unter /etc/openldap/ldap.conf zu finden ist.
4.1.1.1 nsswitch-Services und Benutzerauthentifikation
Um eine Benutzerauthentifikation per LDAP zu ermoeglichen und die von den nss-Services benoetigten Daten aus LDAP zu verwenden, sind die folgenden Dateien relevant:
/etc/openldap/ldap.conf /etc/ldap.conf /etc/ldap.secret /etc/nsswitch.conf /etc/pam.d/system-auth
Die Datei /etc/openldap/ldap.conf sollte hierbei wie im Beispiel unter Abschnitt 4.1 gestaltet werden.
Die /etc/ldap.conf koennte z.B. wie folgt aussehen:
# Liste von LDAP Servern; ist ein Server nicht erreichbar, wird der # jeweils naechste in der Liste angesprochen (mit Leerzeichen getrennt) # # WICHTIG: Auf Fedora-Systemen kann es zu Verbindungsproblemen kommen, wenn # der '/' am Ende des URI fehlt! Dieser Fehler hat bei Tests dazu gefuehrt, # dass das System nicht mehr gebootet werden konnte! # uri ldap://ldapfarm.informatik.uni-bremen.de/ # Basis-DN, unter dem das LDAP-Verzeichnis standardmaessig durchsucht wird base dc=informatik,dc=uni-bremen,dc=de # Sollten die Benutzerdaten nicht anonym einsehbar sein, wird ein # LDAP-Account (proxyuser) mit den entsprechenden Leserechten benoetigt binddn cn=nsswitch,ou=Proxyusers,dc=informatik,dc=uni-bremen,dc=de bindpw nsswitchread # Mit pam_filter kann man den Zugriff auf den Host anhand eines Suchfilters # beschraenken. Es werden alle Benutzer von den nss-Services erkannt, aber # nur die Accounts, die in diese Filter passen, duerfen sich einloggen # (Benutzung von PAM vorrausgesetzt) #pam_filter uid=a* # Kontext fuer nsswitch-Abfragen # Syntax: # nss_base_XXX base?scope?filter # 'scope' beschreibt dabei, wie der angegebene DN durchsucht werden soll. # Moeglich sind die Werte 'base' (nur das Objekt des DN selbst), 'one' # (alle unmittelbar dem Objekt untergeordneten Objekte) und 'sub' # (rekursiv alle Objekte, die dem Objekt untergeordnet sind) # Fuer 'filter' kann ein LDAP-Suchfilter eingesetzt werden, um die Liste # der von den nss-Services gelisteten Benutzer einzugrenzen. nss_base_passwd ou=People,dc=informatik,dc=uni-bremen,dc=de?one nss_base_group ou=Group,dc=informatik,dc=uni-bremen,dc=de?one nss_base_netgroup ou=Netgroup,dc=informatik,dc=uni-bremen,dc=de?one # Lokale Benutzer, bzw. Benutzer bei denen angenommen wird, dass sie # nicht im LDAP-Verzeichnis vorhanden sein sollten und somit bei Abfragen # ignoriert werden nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon # Initialisierung der TLS-Verbindung ueber Port 389 ssl start_tls # Verifizierung des Server-CA-Zertifikats erzwingen tls_reqcert demand # Einbindung des root-CA-Zertifikats zur Verifizierung tls_cacert /etc/openldap/certs/cacert.pem
Mit der Option 'pam_filter', ist es moeglich den Zugriff auf den Host auf LDAP-Benutzer zu beschraenken, die auf einen LDAP-Suchfilter passen. Nur Benutzer, die in das Suchmuster fallen, koennen sich einloggen. Der Rest wird von den nsswitch-Services zwar erfasst, aber alle Loginversuche werden abgelehnt.
Ausserdem ist es moeglich, die von den nsswitch-Services zu verwendeten Objekte auf die selbe Weise zu beschraenken. Mit den 'nss_base_*' Optionen kann man nicht nur die Suchbasis fuer den jeweiligen Service definieren, sondern auch einen LDAP-Suchfilter uebergeben. Es werden jeweils nur Objekte fuer diesen Service beruecksichtigt, die auf den Suchfilter passen.
Damit die nsswitch-Services, wie passwd, group usw. funktionieren, muessen diese Lesezugriff auf die entsprechenden Daten haben. Zu diesem Zweck kann man sogenannte 'Proxyuser' einrichten, dessen einziger Zweck es ist, bestimmte Berechtigungen im LDAP-Verzeichnis zu erhalten und damit Zugriff auf bestimmte Daten zu gewahren.
Es koennen zwei solcher Benutzer in der Konfigurationsdatei angegeben werden. Einmal einer fuer die allgemein zugaenglichen nss-Services, der es Benutzernamen, Gruppen usw. auslesen kann und einer fuer administrative Aufgaben, wie das Auslesen der der Passworthashes fuer den shadow-Dienst, oder das Aendern von Passwoertern.
Da die Benutzer aber Schreibrechte auf ihre eigene Passwoerter haben und die Passworthashes durch die Verwendung von PAM nicht aktiv ausgelesen werden muessen, muss nur der Proxyuser fuer die normalen nsswitch-Dienste angegeben werden.
Gibt man dennoch den administrativen Proxyuser an, so muss dieser Schreibrechte auf die Benutzerpasswoerter haben, damit diese sie aendern koennen. (AUS SICHERHEITSGRUENDEN NICHT ZU EMPFEHLEN!)
Da zur Authentifizierung der Proxyuser die 'simple bind' Methode verwendet wird, sollte auf jeden Fall darauf geachtet werden eine TLS/SSL-gesicherte Verbindung zum Server herzustellen.
In diesem Fall wird das durch die Verwendung von 'ssl start_tls' erreicht. Eine zweite Moeglichkeit besteht darin als URI ldaps:// zu verwenden. Dabei ist aber zu beachten, dass 'ssl start_tls' und ldaps:// sich nicht kombinieren lassen. 'ssl start_tls' ist ldaps:// vorzuziehen.
Aus Sicherheitsgruenden sollten Proxyuser nicht mehr Rechte im LDAP-Verzeichnis haben, als unbedingt notwendig. Da die Passwoerter in Klartext abgelegt sind und auf allen Clients vorhanden sein muessen, reicht es bereits, wenn ein Angreifer in einen Client einbricht und diese Dateien auszuliest, um Zugriff auf das LDAP-Verzeichnis zu erlangen.
Aus diesem Grund sollten nur die notwendigsten Leserechte und wenn moeglich keinerlei Schreibrechte an diese Accounts vergeben werden. Besonders den Proxyuser fuer die nss-Services betreffend, da sein Passwort fuer alle Benutzer lesbar ist.
Die einzige Moeglichkeit, diese Methode zu umgehen, waere der Einsatz von Kerberos, was aber einen bedeutenden Mehraufwand mit sich bringen wuerde.
Um nun die nss-Services passwd, group und netgroup zu veranlassen das LDAP-Verzeichnis nach Daten zu durchsuchen, muessen folgende Anpassungen in der Datei /etc/nsswitch.conf vorgenommen werden:
Auszug aus /etc/nsswitch.conf
passwd: files ldap shadow: files group: files ldap netgroup: files ldap
Derzeit sind nur passwd, shadow, group, netgroup und automount (dazu spaeter mehr) im LDAP-Verzeichnis enthalten.
Es wird empfohlen die Passwoerter _nicht_ per shadow vom LDAP-Server zu beziehen, sondern die Authentifikation der Benutzer ueber PAM abzuwickeln. Fuer den shadow-Service ist es zwingend erforderlich, dass alle Passwoerter als 'crypt'-Hash im LDAP-Verzeichnis vorhanden sind. Da es aber grundsaetzlich meoglich ist, dass dies nicht der Fall ist und PAM unabhaengig vom Format des Passwortes funktioniert, ist PAM shadow vorzuziehen.
Ausserdem ermoeglicht PAM es, den Zugriff auf den Host, auf bestimme Benutzer zu beschraenken. (siehe 'pam_filter' im Konfigurationsbeispiel weiter oben)
Um PAM fuer LDAP zu konfigurieren, muss die Datei /etc/pam.d/system-auth wie folgt angepasst werden:
/etc/pam.d/system-auth (Beispiel)
#%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth sufficient pam_ldap.so try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account sufficient pam_unix.so account sufficient pam_ldap.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_ldap.so password sufficient pam_unix.so md5 shadow nis nullok use_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so
Die Aenderungen sollten sofort aktiv werden und koennen getestet werden, indem man z.B. 'id' auf einen Benutzer im LDAP-Verzeichnis anzuwenden,oder einfach versucht sich mit einem LDAP-Benutzer am System anzumelden.
4.1.1.2 autofs
Da autofs die allgemeine Konfigurationsdatei /etc/openldap/ldap.conf und nicht die fuer nsswitch und PAM verwendet, muessen die automount-Daten anonym lesbar sein. Die einzige Alternative, waehre die Verwendung von SASL, da autofs 'simple bind' nicht unterstuetzt.
Fuer die Konfiguration von autofs sind die folgenden Dateien relevant:
/etc/nsswitch.conf /etc/sysconfig/autofs /etc/auto.master /etc/autofs_ldap_auth.conf
Um den Automounter zu veranlassen, Mountinformation aus dem LDAP- Verzeichnis zu beziehen, gibt es zwei Moeglichkeiten. Zum einen kann man die lokale Mastermap /etc/auto.master so anpassen, dass einzelne Mountmaps vom LDAP-Server gelesen werden, oder man passt die Datei /etc/nsswitch.conf so an, dass die lokale Mastermap ignoriert und alle noetigen Daten vom LDAP-Server gelesen werden, sofern diese dort vorhanden sind.
Eine zentral gelegene Mastermap hat den Vorteil, dass bei Aenderungen nur das jeweilige LDAP-Objekt veraendert werden muss und nicht die /etc/auto.master-Dateien auf allen betroffenen Clients.
Verwendet man lieber die lokale Mastermap koennte ein Eintrag in ihr z.B. so aussehen: /home ldap:ou=auto_home,ou=Mounts,dc=informatik,dc=uni-bremen,dc=de
Stellt man die Option 'automount' in der Datei /etc/nsswitch.conf von 'files' auf 'ldap' bzw. 'ldap files' um, so wird versucht, die Mastermap direkt vom LDAP-Server zu beziehen.
autofs unterstuetzt standardmaessig mehrere Automount-Schemas, die bei der Suche nach einem Mountpoint der Reihe nach abgearbeitet werden. Um dies zu verhindern, kann man in der Datei /etc/sysconfig/autofs ein Schema statisch festlegen und dabei auch die Standards umgehen, um auch nicht unterstuetzte Schemas verwenden zu koennen.
Fuer Automount-Schemas werden zwei Objektklassen (Klasse der Automount-Map und Klasse eines Mapeintrages) und drei Attribute benoetigt (Name der Map, Name des Mapeintrages, Wert des Mapeintrages), die sich in den Schemas unterscheiden. In den Kommentaren in der Datei /etc/sysconfig/autofs sind diverse Beispiele vorgegeben.
Das auf den Servern verwendete Schema wird wie folgt festgelegt:
MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="ou" ENTRY_ATTRIBUTE="cn" VALUE_ATTRIBUTE="automountInformation"
In der Datei /etc/autofs_ldap_auth.conf kann man autofs dazu veranlassen sich per SASL am Server zu authentifizieren, um die Mountdaten zu beziehen. Eine Dokumentation hierzu ist in der Datei selbst enthalten. Da die LDAP- Server momentan kein SASL unterstuetzen, kann diese Datei ignoriert werden.
4.1.2 Debian 4
Fuer Debian 4 werden die folgenden Packages benoetigt:
ldap-utils libnss-ldap libpam-ldap autofs-ldap
Im Gegensatz zu Fedora, stellt Debian drei LDAP Konfigurationsdateien zur Verfuegung. Die allgemeine unter /etc/ldap/ldap.conf, die wie im Beispiel unter Punkt 4.1 gestaltet werden sollte, die /etc/libnss-ldap.conf, fuer die nsswitch Services und die /etc/pam_ldap.conf, fuer PAM.
4.1.2.1 nsswitch-Services und Benutzerauthentifikation
Relevante Dateien:
/etc/ldap/ldap.conf /etc/libnss-ldap.conf /etc/libnss-ldap.secret /etc/pam_ldap.conf /etc/pam_ldap.secret /etc/nsswitch.conf /etc/hosts.equiv /etc/pam.d/common-auth /etc/pam.d/common-session /etc/pam.d/common-account /etc/pam.d/common-password
Die Dateien /etc/libnss-ldap.conf und /etc/pam_ldap.conf sind eigentlich identisch und werden (vermutlich) nur wegen den Angehoerigkeit zu verschiedenen Packages getrennt behandelt. Beide Dateien werde genauso konfiguriert, wie das unter Punkt 4.1.1.1 beschriebene Fedora Aequivalent. Der Einfachheit wegen koennte man eine der beiden Dateien auch einfach durch einen Symlink auf die jeweils andere ersetzen. Dasselbe gilt natuerlich auch fuer die jeweilige .secret Datei.
Die Aenderungen an der Datei /etc/nsswitch.conf sehen ein wenig anders aus, als unter Fedora:
Auszug aus /etc/nsswitch.conf
passwd: compat ldap group: compat ldap shadow: compat netgroup: ldap
Genauso wie unter Fedora, ist es zu empfehlen die Passwoertrt ueber PAM abzugleichen und nicht den shadow-Service zu verwenden.
Das Abfragen von Benutzer-IDs, Gruppen usw. sollte mit diesen Einstellungen bereits funktionieren. Damit die Authentifizierung jedoch funktioniert, muessen folgende Dateien im Verzeichnis /etc/pam.d veraendert werden:
/etc/pam.d/commom-auth (Beispiel)
auth sufficient pam_unix.so nullok_secure auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
/etc/pam.d/commom-session (Beispiel)
session required pam_unix.so session optional pam_ldap.so
/etc/pam.d/commom-account (Beispiel)
account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_deny.so
/etc/pam.d/common-password (Beispiel)
password sufficient pam_ldap.so password required pam_unix.so use_first_pass md5 shadow
4.1.2.2 autofs
autofs unter Debian unterstuetzt zwei moegliche Automount-Schemas und es gibt keine Meoglichkeit diese zu aendern, wie unter Fedora. Ausserdem muss das Startupscript fuer den autofs-Service (/etc/init.d/autofs) auf eines der beiden Schemas eingestellt werden.
Und zwar muessen dafuer in den Zeilen 181 und 182, in der Funktion 'getldapmounts' die Namen angepasst werden, die dem Tool /usr/lib/autofs/autofs-ldap-auto-master uebergeben werden, wenn man ein anderes als das default-Schema (autofs.schema) verwenden moechte.
Auszug aus /etc/init.d/autofs
function getldapmounts()
{
if [ -x /usr/lib/autofs/autofs-ldap-auto-master ]; then
[ ! -z $LDAPURI ] && export LDAPURI="$LDAPURI"
[ ! -z $LDAPBASE ] && export LDAPBASE="$LDAPBASE"
/usr/lib/autofs/autofs-ldap-auto-master 2> /dev/null
######################################################################
# In diesen Zeilen werden die Attribute festgelegt #
# #
/usr/lib/autofs/autofs-ldap-auto-master -m automountMap \ #
-e automount -n ou -k cn -v automountInformation 2> /dev/null #
######################################################################
fi
}Dies ist jedoch nur noetig, wenn man die auto.master Map vom LDAP Server beziehen moechte. Alternativ kann, wie unter Fedora, die Datei /etc/auto.master angepasst werden.
Da das default-Schema bereits dem verwendeten entspricht, ist hier keine Anpassung notwendig. Das zweite unterstuetzte Schema ist das im NIS-Schema definierte.
4.2 Solaris 10
Bei Solaris 10 sind alle benoetigen Packages bereits vorhanden. Da aber nicht OpenLDAP als Grundlage fuer die Solaris-LDAP-Tools stellt, gestaltet sich die Konfiguration ein wenig anders, als unter Linux.
4.2.1 nsswitch-Services und Benutzerauthentifikation
Solaris 10 hat bereits einen eigenen, von Sun entwickelten LDAP-Client vorinstalliert. Dieser Client laesst sich relativ einfach mit nur einem Kommando konfigurieren und sogar noch leichter, wenn vorgefertigte Konfigurationsprofile auf dem LDAP-Server hinterlegt sind. (Nicht unterstuetzt auf den laufenden Servern)
Ist dies der Fall, reicht es das Kommando 'ldapclient init <server>' auszufuehren. Das Tool erledigt dann automatisch alle noetigen Systemeinstellungen.
Eine manuelle Konfiguration des Clients koennte z.B. wie folgt aussehen:
ldapclient manual -v \ -a authenticationMethod=tls:simple \ -a credentialLevel=proxy \ -a defaultSearchBase=dc=informatik,dc=uni-bremen,dc=de \ -a defaultSearchScope=sub \ -a defaultServerList="ldapfarm.informatik.uni-bremen.de" \ -a domainName=informatik.uni-bremen.de \ -a preferredServerList="ldapfarm.informatik.uni-bremen.de" \ -a serviceSearchDescriptor="passwd:ou=People,dc=informatik,dc=uni-bremen,dc=de" \ -a serviceSearchDescriptor="group:ou=Group,dc=informatik,dc=uni-bremen,dc=de" \ -a serviceSearchDescriptor="netgroup:ou=Netgroup,dc=informatik,dc=uni-bremen,dc=de" \ -a serviceSearchDescriptor="auto_home:ou=auto_home,ou=Mounts,dc=informatik,dc=uni-bremen,dc=de" \ -a attributeMap="auto_home:automountMapName=ou" \ -a attributeMap="auto_home:automountKey=cn" \ -a proxyDN=cn=nsswitch,ou=Proxyusers,dc=informatik,dc=uni-bremen,dc=de \ -a proxyPassword=nsswitchread
Das Attribut 'serviceSearchDescriptor' folgt dabei der Syntax '<service>:<dn>?<scope>?<filter>'. Wie bei den OpenLDAP- Konfigurationsdateien, kann man mithilfe des Filters die Liste von den nss-Services erfassten Suchobjekte begrenzen. (z.B. die Liste der passwd-Benutzer)
Es gibt jedoch scheinbar keine Moeglichkeit, wie bei OpenLDAP mit 'pam_filter', den Zugriff auf einen Client zu beschraenken.
Eine ausfuehrliche Dokumentation zur Benutzung von ldapclient, sowie die Erklaerung aller verfuegbaren Optionen ist in den Manpages zu finden. (ldapclient(1M))
Das Ueberpruefen der Serverzertifikate laesst sich, anders als bei OpenLDAP- Clients, nicht abschalten. Deshalb muss das root-CA-Zertifikat auf jeden Fall eingebunden werden.
Da der Sun-LDAP-Client das Zertifikat jedoch im NSS-Format (Network Security Services) benoetigt, muss das PEM-Zertifikat vorher konvertiert werden.
Um die vorhandene *.pem-Datei in dieses Format zu bringen, kann man das Tool 'certutil' verwenden, das auf Solaris vorinstalliert sein sollte:
ldap2# /usr/sfw/bin/certutil -N -d /var/ldap ldap2# /usr/sfw/bin/certutil -A -n "rootCA-FB3" -i cacert.pem -a -t CT \ > -d /var/ldap ldap2# chmod 444 /var/ldap/*
Das erste Kommando legt dabei die NSS-DB fuer die Zertifikate an (Passwort leer lassen). Das zweite pflegt das Zertifikat in diese Datenbank ein. Die DB muss dabei fuer alle Benutzer lesbar sein.
Das Zertifikat sollte eingebunden werden, bevor das ldapclient-Kommando ausgefuehrt wird!
Alle Dateien, die ldapclient veraendert, werden nach /var/ldap/restore kopiert und gehen somit nicht verloren. Die LDAP Konfigurationsdateien die, nicht mit Konfigurationsdateien von OpenLDAP kompatibel sind, liegen in /var/ldap.
Auch hier ist wieder zu empfehlen, nicht den shadow-Service zu benutzen, sondern PAM entsprechend zu konfigurieren. Dafuer muessen folgende Anpassungen an der Datei /etc/pam.conf vorgenommen werden:
/etc/pam.conf (Beispiel)
# # Authentication management # # login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_dial_auth.so.1 login auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user login auth required pam_unix_auth.so.1 # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user rlogin auth required pam_unix_auth.so.1 # # Kerberized rlogin service # krlogin auth required pam_unix_cred.so.1 krlogin auth required pam_krb5.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user rsh auth required pam_unix_cred.so.1 # # Kerberized rsh service # krsh auth required pam_unix_cred.so.1 krsh auth required pam_krb5.so.1 # # Kerberized telnet service # ktelnet auth required pam_unix_cred.so.1 ktelnet auth required pam_krb5.so.1 # # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_cred.so.1 ppp auth required pam_unix_auth.so.1 ppp auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authentication # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user other auth required pam_unix_auth.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth sufficient pam_lap.so.1 use_first_pass passwd auth required pam_passwd_auth.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account sufficient pam_ldap.so.1 other account required pam_unix_account.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session sufficient pam_ldap.so.1 other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1
Leider bietet das pam_ldap-Modul von Sun nicht die Moeglichkeit den Zugriff auf einen Host durch einen LDAP-Filter zu begrenzen. Alternativ kann man aber ueber die Option 'serviceSearchDescriptor' in ldapclient einen Filter uebergeben und so die Liste der verfuegbaren Benutzer eingrenzen.
Eine andere Moeglichkeit ist, das pam_ldap-Modul von PADL (padl.com) statt dem Sun-Modul zu verwenden. (ungetestet)
4.2.2 autofs
Da ldapclient keine Einstellungen fuer autofs vornimmt, muessen diese von Hand nachgetragen werden. Als erstes muss in der Datei /etc/nsswitch.conf der Wert 'automount' auf 'files ldap' eingestellt werden.
Auszug aus /etc/nsswitch.conf
automount files ldap
Das Verwenden der Mastermap vom LDAP-Server gestaltet sich als relativ schwierig, weshalb die entsprechenden Maps am besten in die lokale /etc/auto.master-Map eingebunen werden sollten.
Die Grundlage dafuer wurde schon in den Optionen vom oben beschriebenen ldapclient-Kommado geschaffen:
-a serviceSearchDescriptor="auto_home:ou=auto_home,ou=Mounts,dc=informatik,dc=uni-bremen,dc=de" \ -a attributeMap="auto_home:automountMapName=ou" \ -a attributeMap="auto_home:automountKey=cn" \
Sollen andere Maps als 'auto_home' vom LDAP-Verzeichnis bezogen werden, muss ldapclient mit den entsprechend erganezten Optionen erneut ausgefuehrt werden. (ACHTUNG: Dabei wird die Datei nsswitch.conf automatisch mit der Datei nsswitch.ldap ueberschrieben!)
Um die auto_home-Map nun in die auto.master einzubinden, erstellt man einfach eine Datei /etc/auto_home mit dem Inhalt '+auto_home' und bindet diese wie eine lokale Map ein.
/etc/auo_home
+auto_home
/etc/auo.master
/home auto_home
Nach einem Neustart des autofs-Services sollten die Mountpoints aus dem LDAP-Verzeichnis zur Verfuegung stehen.
4.3 Mac OS X
Dieser Abschnitt bezieht sich auf Mac OS X Leopard. Unter anderen Versionen sollte die Konfiguration in etwa gleich ablaufen, kann jedoch in einigen Punkten abweichen.
Unter Mac OS X wird der Grossteil der Einstellungen ueber die grafische Oberflaeche erledigt. Vorher sollte allerding sichergestellt sein, dass in der Datei /etc/openldap/ldap.conf das rootCA-Zertifikat eingebunden und der Wert 'TLS_REQCERT' auf 'demand' eingestellt ist.
Danach kann man im Finder unter 'Applications/Utilities' das 'Directory Utility' aufrufen. Unter dem Reiter 'Services' ist in der Liste ein Punkt 'LDAPv3' vorhanden. Ist der Reiter nicht zu sehen, kann er ueber den Button 'Advanced Setting' sichtbar gemacht werden. Durch einen Doppelklick auf den 'LDAPv3'-Eintrag gelangt man nun zur LDAP-Serverliste.
Durch einen Klick auf den Button 'New...' kann man einen Server in die Liste aufnehmen. Im darauf folgenden Dialog gibt man den Servernamen ein, setzt die Haekchen bei 'Encrypt using SSL' und 'Use for authentication' und klickt dann auf 'Continue'.
Das verwendete Template ist 'RFC 2307 (UNIX)' und die Searchbase entspricht der 'base'-Option in der ldap.conf. Sind die Benutzerdaten nicht anonym lesbar, werden im naechsten Schritt die Autentifizierungsdaten eines Benutzers mit den entsprechenden Rechten verlangt.
Nach einem weiteren Klick auf 'Continue' werden die eingegebenen Daten ueberprueft und sollte alles korrekt eingegeben worden sind, wurde der Server erfolgreich in die Liste aufgenommen und der Vorgang kann mit 'OK' abgeschlossen werden.
Damit autofs funktioniert, sollte der Eintrag jedoch noch einmal editiert werden, da das default-Schema nicht dem auf den FB3-Servern verwendeten entspricht. Unter dem Reiter 'Search & Mappings' kann man saemtliche Attribute und Objektklassen nach eigenem Bedarf um-mappen, sowie die Basis-DNs fuer die Suche nach den jeweiligen Daten festlegen.
Unter den Punkten 'Automount' und 'AutomountMap' muss im Feld 'RecordName' jeweils 'automountMapName' durch 'ou' und 'automountKey' durch 'cn' ersetzt werden.
Bei Mac OS X ist es, anders als bei Linux, nicht meoglich, auf die lokale Mastermap /etc/auto.master zu verzichten. Es ist jedoch moeglich, die lokale Mastermap um Daten aus dem LDAP-Verzeichnis zu erweitern. Indem man z.B. eine Zeile '+auto.master' hinzufuegt, wird die Matsermap 'auto.master' vom LDAP-Server mit beruecksichtigt.
Alternativ kann man einzelne Maps aus dem LDAP-Verzeichnis beziehen und auch lokale erweitern.
/etc/auto.master (Beispiel)
# # Automounter master map # +auto_master # Use directory service /net -hosts -nobrowse,nosuid
ODER
/etc/auto.master (Beispiel)
# # Automounter master map # /net -hosts -nobrowse,nosuid /home auto_home
/etc/auto_home (Beispiel)
+auto_home
Zum Schluss sollte man noch sicher stellen, dass der eingetragene LDAP- Server im 'Directory Utility' unter 'Search Policy' in der 'Authentication'-Liste eingetragen ist. Ist dies nicht der Fall, kann er ueber den '+'-Button hinzugefuegt werden.
Auf diese Weise kann man beliebig viele Server in die Liste eintragen.
Leider scheint es keine Meoglichkeit zu geben, Filter fuer die Suchbereiche anzugeben, oder den Zugriff auf einen Host nur bestimmten Benutzern zu erlauben.
4.4 Windows
Es ist leider nicht moeglich einen Windows-Client direkt an einen OpenLDAP- Server anzubinden. Aber man kann einen Samba-Server aufsetzen, der den LDAP-Server als Backend verwendet. Mit den unter Abschnitt 3. erwaehnten Samba-Attributen kann ein UNIX-Account im LDAP-Verzeichnis somit gleichzeitig als Samba-Account verwendet werden.
Eine Dokumentation zu Samba mit LDAP-Backend kann auf samba.org gefunden werden.
5. Verwaltung
Die Verwaltung der Daten im LDAP-Verzeichnis baut auf das alte, fuer NIS verwendete, System auf. Verschiedene Skripte stehen zum Teil im FB3- Dateisystem und zum anderen Teil auf bestimmten Hosts zur Verfuegung, um alle relevanten Daten einzusehen und gegebenenfalls zu veraendern.
In den folgenden Abschnitten werden die Verwaltungsmoeglichkeiten der verschiedenen Datengruppen ausgefuehrt und ein Vergleich zu den bisherigen Methoden gezogen.
5.1 Benutzer
Das Hinzufuegen und Entfernen von Benutzern ist fuer den Anwender praktisch unveraendert. Die Skripte 'adduser' und 'delete_user' stehen z.B. weiterhin zur Verfuegung und haben sich nur inhaltlich, aber nicht in der Funktion veraendert. Weiteres zu den Verwaltungsskripten spaeter.
5.1.1 Zugriffsbeschraenkung auf bestimmten Hosts
Da der Wunsch geaeussert wurde, auf bestimmten Hosts den Benutzerzugriff einzuschraenken, wurden dazu mehrere Moeglichkeiten ausgearbeitet, die in diesem Abschnitt erlaeutert werden.
5.1.1.1 PAM-Filter
Auf Systemen, die das pam_ldap-Modul von PADL (padl.com) verwenden, kann man ueber die entsprechende Konfigurationsdatei den Zugriff auf den Client mit Hilfe eines LDAP-Filters beschraenken. (siehe Abschnitt 4.1.1.1)
*Getestet unter Debian und Fedora *Prinzipiell moeglich unter Solaris (PAM-Modul muss uebersetzt und eingebunden werden) *Nicht moeglich unyer Mac OS X
5.1.1.2 Netgroup
Auf Systemen die Netgroups unterstuetzen und die Option 'compat' in der /etc/nsswitch.conf erlauben, kann mithilfe von Netgroups die Benutzerliste beeinflusst werden. Dabei ist es sowohl moeglich Netgroups als White- wie auch als Blacklist anzuwenden.
Beispiel fuer Whitelist: Moechte man nur den Benutzern, die in der Netgroup 'trusers' eingetragen sind, den Zugriff auf einen Host erlauben, muessen folgende anpassungen vorgenommen werden:
/etc/nsswitch.conf fuer Linux
passwd: compat passwd_compat: ldap
/etc/passwd
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh ... +@trusers +::::::/sbin/nologin
/etc/nsswitch.conf fuer Solaris
passwd: compat passwd_compat: ldap shadow: compat shadow_compat: ldap
/etc/passwd
root:x:0:0::/root:/bin/bash daemon:x:1:1::/: ... +@trusers +::::::/bin/false
/etc/shadow
root:FSIueEouAzv1I:6445:::::: daemon:NP:6445:::::: smmsp:*::::::: nobody:*::::::: .... +@trusers
Durch diese Einstellungen werden die Mitglieder der Netgroup 'trusers' in die passwd-Liste des Systems aufgenommen. Diese Methode laesst sich auch ohne Netgroup auf einzelne Benutzer anwenden. Die letzte Zeile sorgt dafuer, dass die restlichen Benutzer dem System bekannt bleiben.
/etc/passwd
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh ... +testuser1 +testuser2 +::::::/sbin/nologin
Beispiel fuer Blacklist: Moechte man den Mitgliedern eine bestimmten Netgroup den Zugriff auf den Host verweigern, muessen folgende Anpassungen gemacht werden:
Die Datei /etc/nsswitch.conf wird wie im Whitelist-Beispiel angepasst.
/etc/passwd
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh ... -@ntrusers +
Das einzelne '+' bindet alle LDAP-Benutzer in den passwd-Service ein, waehrend '-@ntrusers' alle Mitglieder der Netgroup 'ntrusers' davon ausschliesst. Das Aussschliessen von einzelnen Benutzern ist ebenfalls moeglich.
/etc/passwd
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh ... -testuser1 -testuser2 +
Ein LDIF-Eintrag einer solchen Netgroup koennte z.B. so aussehen:
dn: cn=trusers,ou=Netgroup,dc=informatik,dc=uni-bremen,dc=de objectClass: nisNetgroup objectClass: top cn: trusers nisNetgroupTriple: (-,testuser1,) nisNetgroupTriple: (-,testuser2,) nisNetgroupTriple: (-,testuser3,)
Dabei ist aber zu beachten, dass es bei LDAP, genauso wie bei NIS, zu Problemem bezueglich der Groesse der Netgroups kommt. Sollte daher eine Netgroup zu viele Mitglieder enthalten sollte sie aufgespalten werden.
Eine einfache Verwaltung aller Netgroups (auch der fuer z.B. trustedhosts) waehre z.B. ueber eine aehnliche Struktur, wie beim momentanen auto.home.d- Verzeichnis auf bob, moeglich.
*Getestet unter Debian und Solaris *Prinzipiell moeglich unter allen Systemen, die Netgroups unterstuetzen *Nicht moeglich unter Mac OS X
5.1.1.3 Modifizierter Replicaserver
Da es unter Mac OS X scheinbar nicht ohne weiteres Moeglich ist, den Hostzugriff zu begrenzen, ist hier moeglicherweise die einzige Moeglichkeit ein eigener Replicaserver, der nur die Benutzerdaten synchronisiert, die auf den angbebundenen Systemen verwendet werden sollen.
Die selbe Eischraenkung schein fuer Samba-Domains zu gelten. Eine weitere Einschraenkung bei Samba-Domain ist es, dass ein Accountobjekt nur eine Samba-SID aufnehmen kann und somit nur Mitglied in einer Samba-Domain zur Zeit sein kann.
Um dies zu umgehen koennte man z.B. einen Replicaserver einrichten, der alle Daten, ausser den Samba-SIDs repliziert. Die SIDs koennten dann per Skript eingefuegt werden.
5.1.1.4 Hierarchische Ablage von Benutzerobjekten
Da LDAP-Datenbanken hierarchisch organisiert sind, waehre es grundsaetzlich moeglich die Benutzerobjekte in einer nach z.B. Arbeitsgruppen gegliederten Baumstruktur abzulegen.
Indem man dann auf Clients nur jeweils einen untergeordneten Zweig als Suchbasis fuer Benutzerobjekte angibt, koennte der Zugriff auf einen Host dadurch unter praktisch allen Plattformen auf diesem Unterzweig begrenzt werden.
Da dieses System jedoch extrem unflexibel ist, ist der Verwaltungsaufwand relativ hoch. Wenn z.B. Benutzer verschiedenen Arbeitsgruppen angehoeren sollen oder oft unter ihnen wechseln, muessten Datensaetze mehrfach vorhanden sein, oder Verweise auf sie muessten gepflegt werden.
5.1.1.5 nss-Filter
Bei der SUN- und der PADL-nss_ldap-Lib kann man bei den Suchbasen fuer die verschiedenen Datengruppen einen Filter einstellen. Alle Accounts, die nicht auf diesen Filter zutreffen, werden in der entsprechenden Datengruppe nicht beruecksichtigt.
Erklaerungen dazu sind unter den Punkten 4.1.1.1 (nss_ldap-Lib von PADL) und 4.2.1 (Solaris ldapclient) und in den offiziellen Dokumentation der jeweiligen Systeme zu finden.
5.1.1.6 Zugriffsbeschraenkung unter Samba
Unter Samba gibt es mehrere Moeglichkeiten, eine bestimmten Gruppe von Benutzern den Zugriff zu erlauben, bzw. zu gewaehren. Da Samba nur die Accounts beruecksichtigt, die auch von den nss-Services der passwd- Datenbank zugeordnet werden, kann man schon durch die Systemeinstellungen der Maschine, auf der der Samba-Server laufen soll, die Liste der zu beruecksichtigenden Accounts einschraenken. (siehe z.B. Abschnitt 5.1.1.5)
Desweiteren besteht die Moeglichkeit mit den Direktiven 'valid users' und 'invalid users' den Zugriff fuer UNIX- und Netgroups zu erlauben bzw. verweigern. Weiteres dazu kann der Manpage zu smb.conf(5) entnommen werden.
5.1.2 Passwoerter
5.1.2.1 Passwoerter allgemein
Da die Passwoerter schon in der Antragsdatei gehasht sind, wird, wie bisher auch, beim Erstellen des Accounts nur das UNIX-Passwort, aber kein Samba- Passwort gesetzt. Soll der Account sich an einer Samba-Domain authentifizieren koennen, muss dieses nachtraeglich erstellt werden.
Zum Verwalten der Passwoerter stehen mehrere Moeglichkeiten zur Wahl. Auf Systemen die PAM verwenden, laesst sich ueber das passwd-Modul von PAM das passwd-Kommando so konfiguerieren, dass darueber sowohl das UNIX- als auch das Samba-Passwort im LDAP-Verzeichnis geandert werden kann. Ausserdem ist in den OpenLDAP-Client-Tools ein Programm 'ldappasswd' enthalten, das es ermoeglicht das UNIX-Passwort im LDAP-Verzeichnus zu veraendern. (siehe Abschnitt 2.2.4)
Da ldappasswd aber mit DNs arbeitet ist dieses Tool eher fuer Techniker, als fuer normale Benutzer geeignet.
Die 'smbldap'-Toolsammlung (http://www.iallanis.info/) enthaelt ein nuetzliches Perlskript 'smbldap-passwd' mit dem Komfortabel sowohl UNIX- als auch Samba-Passwoerter in einem Schritt geaendert werden koennen.
Desweiteren waere es auch ohne weiteres moeglich ein Web-GUI fuer normale Benutzer zur Verfuegung zu stellen, mit dem sie ihre Passwoerter aendern koennen.
Das manuelle Aendern eines Passwortes, z.B. per LDIF und ldapmodify, ist ebenfalls moeglich. Dabei kann das Passwort sowohl in Klartext, als auch als Hash in das LDAP-Verzeichnis geschrieben werden. Da der slapd mehrere Hashschemas fuer Passwoerter unterstuetzt, muss man bei einem gehashten Passwort angeben, welches Hashschema verwendet wird. Wird dies nicht gemacht, wird der Hash als Klartextpasswort identifiziert. Das Hashschema wird dabei in geschweiften Klammern ('{' und '}' ) gefolgt vom Hash selbst angegeben.
Soll die Authentifizierung der Benutzer allein ueber PAM ablaufen, so ist egal, welches Hashschema fuer die Passwoerter verwendet wird. Soll aber der shadow-Service verwendet werden, so _muessen_ die Passwoerter mit {crypt} gehasht sein.
Die unterstuetzten Hashschemas sind {CRYPT}, {MD5}, {SMD5}, {SSHA} und {SHA}.
Bei den folgenden LDIF-Beispielen, bei dem das Passwort des Benutzers 'testbenutzer' ueberschrieben wird, lautet das Passwort immer 'test':
dn: uid=testbenutzer,ou=stud,ou=People,dc=informatik,dc=uni-bremen,dc=de changetype: modify replace: userPassword userPassword: test
ODER
dn: uid=testbenutzer,ou=stud,ou=People,dc=informatik,dc=uni-bremen,dc=de
changetype: modify
replace: userPassword
userPassword: {crypt}KcitZI/Pds2ksODER
dn: uid=testbenutzer,ou=stud,ou=People,dc=informatik,dc=uni-bremen,dc=de
changetype: modify
replace: userPassword
userPassword: {ssha}mnyna4WDb0XHC9GPpCG5gArcnBO9qoHpODER
dn: uid=testbenutzer,ou=stud,ou=People,dc=informatik,dc=uni-bremen,dc=de
changetype: modify
replace: userPassword
userPassword: {md5}CY9rzUYh03PK3k6DJie09g==Diese LDIF-Daten koennten z.B. ldapmodify einfach in das LDAP-Verzeichnis uebernommen werden.
Aus Sicherheitsgruenden ist es natuerlich nicht zu empfehlen, Passwoerter in Klartext zu speichern. Davon abgesehen ist es praktisch jedem selbst ueberlassen, wie er seine Passwoerter hasht. Nur fuer die Verwendung von shadow-Passwoertern, wird man auf ein Schema ({crypt}) beschraenkt.
5.1.2.2 Passwoerter im FB3
Die momentane Regelung mit NIS sieht es vor, dass das Aendern der Passwoerter nur auf einem Passworthost erlaubt ist. Die Umstellung auf LDAP erlaubt es, dies per PAM auf jedem Host zu ermoeglichen.
Fuer die Uebergangsphase ist es vorgesehen, dass die Regelung mit dem Passworthost bestehen bleibt und die NIS-Passwoerter per Cronjob in das LDAP-Verzeichnis eingepflegt werden.
5.2 Benutzerdatenbank
Die urspruenglich in /home/userdb/data/user gelegenen zusaetzlichen Benutzerdaten sind von nun an in die Accountobjekte im LDAP-Verzeichnis integriert. Aus Kompatibilitaetsgruenden wird das alte Format aber weiterhin als readonly-Datei verfuegbar sein. Dafuer werden die entsprechenden Daten regelmaessig durch ein Skript aus dem LDAP-Verzeichnis exportiert.
Aenderungen an den userdb-Daten sind nur noch direkt im LDAP-Verzeichnis moeglich. Dazu kann man die entsprechenden Attribute entweder manuell veraendern oder das Web-GUI unter https://www.informatik.uni-bremen.de/ verwenden. Das Web-GUI entspricht dabei in seiner Funktionalitaet dem fuer die alte Userdatendatenbank verwendeten GUI.
Die Verwendung des GUIs ist dabei dem manuellen Editieren von Daten vorzuziehen, da es die Eingaben vor dem Schreiben in das Verzeichnis auf Gueltigkeit prueft, wodurch fehlerhafte Daten vermieden werden koennen.
Da die Userdatenbank im alten Format fuer Lesezugriffe zur Verfuegung steht, ergeben sich keine Aenderungen an rein lesenden Skripten, die auf die userdb-Daten zugreifen.
Eine Aufstellung aller veraenderten, entfallenden und neuen Skripten ist unter Punkt 5.5 zu finden.
Fuer die Ubergangsphase wird das alte System vorerst bestehen bleiben. Die Userdatenbankdaten werden dann per Cronjob regelmaessig in das LDAP- Verzeichnis eingepflegt.
5.3 Gruppen
An der Verwaltung der Benutzergruppen wird sich fuer den Anwender nichts aendern. Die Aenderungen bestehen nur darin, dass die Gruppen nun automatisch mit dem LDAP-Verzeichnis und nicht mehr mit NIS abgeglichen werden.
(Waehrend der Ubergangspahse wird dies von einem Cronjob erledigt)
5.4 Mountpoints
Auch an der Verwaltung der Mountpoints in /etc/informatik/auto.home.d/ auf bob wird sich von der Anwenderseite her nichts veraendern. Das Makefile wurde so angepasst, dass ein entsprechendes Skript ausgefuehrt wird, welches die Automountdaten mit dem LDAP-Server abgleicht und Aenderungen in das Verzeichnis uebertraegt.
(Waehrend der Ubergangspahse wird dies von einem Cronjob erledigt)
5.5 Zusammenfassung / Gegenueberstellung mit dem alten System
An dieser Stelle wird zu einen spaeteren Zeitpunkt eine Aufstellung aller zentralen Skripte folgen, die im Zuge der Umstellung von NIS auf LDAP veraendert werden. In der Uebergangsphase, in der NIS und LDAP parallel betrieben werden sollen, werden vorerst alle Daten aus NIS und der Userdatenbank mit per Cronjob ausgefuehrten Skripten in das LDAP- Verzeichnis eingepflegt.
Ausnahmen sind (bis jetzt) Gruppen und Mountpoints. Die entsprechende Skripte auf bob sind soweit angepasst, dass diese Daten direkt mit dem LDAP-Verzeichnis synchronisiert werden.
Die crongesteuerten Skripte sind auf bob und auf fidel zu finden:
bob
/services/ldap/bin.new/nisldapsync.pl
Synchronisiert die UNIX-Passwoerter aus /etc/informatik/passwd mit LDAP.
/services/ldap/bin.new/syncaccs.pl
Synchronisiert die Userdatenbank mit LDAP.
/services/ldap/bin.new/syncnetgroup.pl
Synchronisiert die Netgroups aus /home/nic/netgroup.informatik mit LDAP.
fidel
/etc/smb/smbpasswd_to_ldap.pl
Synchronisert die Sambapasswoerter mit LDAP.