Unentbehrliches Netzwerk-Know-how (tecCHANNEL COMPACT)
LDAP, Teil 3
Der Authentifizierungsprozess wird bei jedem Verbindungsversuch des Clients verwendet, um dessen Privilegien zu überprüfen und zu bestimmen. Alle Aktionen werden durch den Level der Autorisierung (Gewährung von Rechten) kontrolliert. Voraussetzung ist die erfolgreiche Authentifizierung.
Auf dieser Seite
Generell stellen sich bei der Verwendung oder der Einführung von LDAP die folgenden Fragen, wie etwa:
Zugriffssteuerung unter LDAPEin allgemein gültiges Konzept für die Zugriffskontrolle wurde anfänglich für LDAP nicht vorgesehen. Mittlerweile existieren jedoch über RFC 2820 einige allgemeine Empfehlungen in Bezug auf das Thema LDAP und Sicherheit. Alle wesentlichen LDAP-Implementierungen wie etwa OpenLDAP besitzen Mechanismen zur Zugriffssteuerung. Unter OpenLDAP kommen ACLs (Access Control List/Zugriffskontrollliste) zum Einsatz. Geregelt wird dies über die Konfigurationsdatei slapd.conf. Diese Datei enthält die Einträge für die Konfiguration des slapd Standalone Server. Der slapd beantwortet die LDAP-Anfragen der Clients – es ist der LDAP-Server oder Verzeichnisserver: # User darf eigene Attribute ändern, # authentifizierte User lesen # alle andere sehen nichts access to attr=telephoneNumber,seeAlso,description,audio, businessCategory,carLicense,displayName,homePhone, homePostalAddress,jpegPhoto,labeledURI,mobile,pager, photo,homeTelephoneNumber,favouriteDrink by self write by users read by * none Oder so: # Grundregel, damit anonyme User das Verzeichnis durchsuchen können access to attr=entry,objectClass by dn="uid=admin,ou=People,dc=Schriesheim,dc=int" write by * read Oder so: access to * attr=userPassword by self write by anonymous auth access to * by * read Die ACLs werden der Reihe nach abgearbeitet und die erste Übereinstimmung wird genommen. Im Beispiel kann ein beliebiger User das Passwort also nicht lesen. Zu beachten ist, dass der als rootdn definierte DN immer Schreiberlaubnis hat. In der schon bekannten BNF-Form würde dies so aussehen: <access directive> ::= access to <what>
[by <who> <access> <control>]+
<what> ::= * | [ dn[.<target style>]=<regex>]
[filter=<ldapfilter>] [attrs=<attrlist>]
<target style> ::= regex | base | one | subtree | children
<attrlist> ::= <attr> | <attr> , <attrlist>
<attr> ::= <attrname> | entry | children
<who> ::= [* | anonymous | users | self |
dn[.<subject style>]=<regex>]
[dnattr=<attrname> ]
[group[/<objectclass>[/<attrname>][.<basic style>]]=<regex> ]
[peername[.<basic style>]=<regex>]
[sockname[.<basic style>]=<regex>]
[domain[.<basic style>]=<regex>]
[sockurl[.<basic style>]=<regex>]
[set=<setspec>]
[aci=<attrname>]
<subject style> ::= regex | exact | base | one | subtree | children
<basic style> ::= regex | exact
<access> ::= [self]{<level>|<priv>}
<level> ::= none | auth | compare | search | read | write
<priv> ::= {=|+|-}{w|r|s|c|x}+
<control> ::= [stop | continue | break]Dabei stellt <what> die Einträge und/oder Attribute dar, auf die der Zugriff gewährt wird, <who> spezifiziert, welchen Entities (*, anonymous, users, self, dn=<regex>) Zugriff gewährt wird und <access> bestimmt das Zugriffsrecht (none, auth, compare, search, read, write). Mehr Informationen zu dieser Thematik erhalten Sie z.B. unter http://www.openldap.org. AuthentifizierungsmechanismenBevor eine Zugriffssteuerung greifen kann, muss die Authentifizierung erfolgreich durchlaufen werden. Dieser Authentifizierungsprozess existiert seit den frühesten LDAP-Versionen. In der Terminologie von LDAP spricht man von einer Bindung an das Verzeichnis. Benötigte Parameter für eine Bindung sind der Benutzername in Form eines DN und ein Passwort (Credential). Zur Erfüllung verschiedener Ansprüche an die Sicherheitsstufen gibt es folgende grobe Einteilung der Authentifizierung:
Verwendung findet dieses Authentifizierungsverfahren hauptsächlich bei der Kommunikation zwischen Verzeichnisservern. Die übertragenen Daten einer Replikation sind oftmals sicherheitskritisch. Außerdem wird meist umfassender schreibender Zugriff auf die Replik benötigt, der für andere Anwendungen verhindert werden soll. Durch RFC 2251 ist der Authentifizierungsprozess für LDAP definiert worden. Es handelt sich um die so genannte Bind-Operation (Bindung), mittels derer sich ein LDAP-Client beim LDAP-Server anmeldet. Diese Operation ist in ein Bind Request und ein Bind Response aufgeteilt. Der bind request enthält neben der LDAP-Protokollversionsnummer einen DN eines Eintrags, welcher die zu beweisende Identität kennzeichnet, also z.B. ein Personeneintrag, sowie schließlich die Kennzeichnung der verwendeten Authentifizierungsmethode und die dazugehörenden Daten. Hierbei sind zurzeit zwei Methoden definiert:
Folgende SASL-Mechanismen wurden entweder in RFC 2222 oder in Folgespezifikationen definiert:
GSSAPI steht für Generic Security Service Application Program Interface (Version 2 in RFC 2078). Die beiden wichtigsten GSSAPI-Mechanismen sind: Kerberos V5 (RFC 1510), eine Kerberosversion, in der die Sicherheitsschwächen von Kerberos V4 behoben wurden. X.509-basierte so genannte Strong Authentication, bei der die Authentifizierung über X.509-Schlüsselpaare in Verbindung mit der Zertifizierung des öffentlichen Schlüssels geschieht. Über die „Hintertür“ GSSAPI wird so das für X.500 spezifizierte strong bind ermöglicht.
Abhängig vom gewählten SASL-Mechanismus werden bei der LDAP-Authentifizierung im bind request anstelle des DNs andere Identitätskennungen (z.B. ein Kerberos-principle) und andere Identitätsbeweise mitgeschickt. Ebenfalls abhängig vom Authentifizierungsmechanismus schickt der Server als Antwort unterschiedlich modellierte bind responses zurück. Der hierbei mitgegebene Error-Code (SUCCESS, wenn die Authentifizierung erfolgreich war, oder aber der Grund, warum diese nicht erfolgreich war) ist jedoch in jedem Fall festgelegt. In RFC 2830 wird spezifiziert, wie TLS zur Verschlüsselung der gesamten Kommunikation zwischen Client und Server im LDAP-Protokoll verwendet werden soll. Hierbei initiiert der Client eine solche Verschlüsselung durch den StartTLS-Befehl, wonach die zu verwendende TLS/SSL-Version ausgehandelt wird sowie die X.509-Zertifikate ausgetauscht werden. Mit TLS kann sich nicht nur der Server mit seinem Zertifikat authentifizieren, sondern auch der Client. In diesem Fall kann die Client-Authentifizierung über den SASL-Mechanismus EXTERNAL auch für die LDAP-Authentifizierung verwendet werden. Ansonsten dient TLS nur zur Verschlüsselung der Verbindung. RFC 2829 spezifiziert, welche dieser Authentifikationsmechanismen von einer standardkonformen LDAPv3-Implementierung in jedem Fall unterstützt werden muss:
Viele LDAP-Implementierungen unterstützen aber mehr als diese drei Pflichtmechanismen. So lässt sich zum Beispiel mit der Open-Source-Implementierung OpenLDAP eine Authentifizierung mittels Kerberos 5 via SASL-GSSAPI realisieren. Welche SASL-Mechanismen ein Server unterstützt, wird in einem speziellen Eintrag, dem so genannten ROOTDSE-Eintrag, veröffentlicht. Passwörter können in LDAP-Servern sowohl im Klartext als auch verschlüsselt abgelegt werden. Das Standard-Schema spezifiziert zur Speicherung des Passworts das Attribut USERPASSWORD. Wird es verschlüsselt abgelegt, wird der jeweilige Verschlüsselungs- bzw. Hash-Algorithmus in geschwungener Klammer vor das verschlüsselte Passwort gesetzt. Die üblichsten Algorithmen sind crypt, md5 und sha, aber auch die sichereren smd5 und ssha können eingesetzt werden. Damit der Client beim Setzen eines neuen Passworts nicht wissen muss, wie der Server das Passwort ablegt, wurde in RFC 3062 eine Erweiterung des LDAP-Protokolls spezifiziert. Bei manchen Authentifizierungsverfahren über SASL werden die Passwörter auch gar nicht im LDAP-Server, sondern an anderen Orten gespeichert (RADIUS). Die Erweiterung bewirkt, dass der Server das vom Client mit dem alten Passwort zusammen geschickte neue Passwort entsprechend seiner Konfiguration verarbeitet und speichert. Des Weiteren wurde in RFC 3112 ein neues Attribut AUTHPASSWORD mit einer eigenen Syntax für verschlüsselte Passwörter spezifiziert. Sicherheitsrisiken bei der Verwendung von LDAPBeim Einsatz eines zentralen Authentifizierungssystems wird die Kompromittierung des zentral gespeicherten Passworts zu einem erhöhten Sicherheitsrisiko. Wenn dieses zentrale Passwort kompromittiert wurde, ist eben nicht nur ein Rechner oder eine Anwendung offen, sondern alle Schnittstellen, die am Authentifizierungssystem angeschlossen sind. Deshalb sollten root-Passwörter immer dezentral auf den jeweiligen Rechnern bleiben und nicht in das LDAP-Authentifizierungssystem integriert werden. Es gibt mittlerweile eine ganze Reihe von Hackertools, deren dediziertes Ziel ist, LDAP-Passwörter zu kompromittieren. Eines dieser Tools ist das C-Programm Kold („Knocking on LDAP’s Door“ http://www.phenoelit.de), welches einen Wörterbuch-Angriff auf jeden Eintrag eines LDAP-Servers durchführt. Ein Perl-Programm mit ähnlicher Funktion heißt LDAP_Brute.pl (http://angreypacket.com). Solche Online-Attacken sind relativ leicht an den Log-Dateien des LDAP-Servers zu erkennen. Darüber hinaus setzen sie voraus, dass entweder anonym auf den LDAP-Server zugegriffen werden kann oder dass dem Angreifer mindestens ein Passwort bekannt ist, um überhaupt die Einträge finden zu können. Schließlich funktionieren solche Attacken auch nur bei sehr schwachen Passwörtern, die aus Vornamen oder ganzen Wörtern bestehen. Wenn darauf geachtet wird, dass z.B. mindestens eine Ziffer und ein Sonderzeichen im Passwort enthalten sind, gehen solche Angriffe meistens ins Leere. Eine adäquate Passwortqualität ist also gefordert. Ein weiteres Tool zum Kompromittieren von LDAP-Passwörtern heißt Lumberjack (http://www.phenolit.de), welches nicht einen LDAP-Server angreift, sondern LDIF-Dateien analysiert. LDIF-Dateien werden häufig zu Replikationszwecken über das Netz geschickt und können – geschieht dies nicht durch verschlüsselte Kanäle – abgefangen werden. Es wurde sogar beobachtet, dass Firmen solche LDIF-Dateien offen im Web abgelegt hatten. Lumberjack versucht, die verschlüsselten Passwörter in LDIF-Dateien zu knacken. Da der Angriff nicht über das Netz geht – der Angreifer also unbegrenzte Zeit für die Analyse hat –, versucht Lumberjack jede mögliche Kombination aus Buchstaben, Ziffern und Sonderzeichen, verschlüsselt diese mit dem in geschwungener Klammer angegebenen Algorithmus und vergleicht das Resultat mit den verschlüsselten Passwörtern. Aufgrund der Existenz solcher Tools wie Lumberjack ist von einer Klartextübertragung von LDIF-Dateien unbedingt abzuraten. Außerdem sollte darauf geachtet werden, dass die Passwörter in relativ kurzen Abständen erneuert werden. Ein wesentliches Merkmal für sichere Passwörter ist die Kontrolle der Passwortlänge, der Nutzung eines möglichst großen Zeichenvorrats (Klein- und Großbuchstaben, Ziffern und Sonderzeichen) bei der Bildung von Passwörtern, ihrer Gültigkeitsdauer und der Beschränkung ihrer Wiederverwendung. Eine diese Punkte vorschreibende Passwortregel (Password Policy) ist gerade im Zusammenhang mit zentralen Authentifizierungssystemen von großer Bedeutung. Viele LDAP-Implementierungen können solche Regeln erzwingen. Ein entsprechender Standard wird zurzeit im Rahmen der IETF entwickelt. Für LDAP-Implementierungen, wie die Open-Source-Implementierung OpenLDAP, die bisher solche Passwortregeln nicht unterstützen, kann diese Funktionalität mittels eines Web-Front-Ends implementiert werden. Dabei muss aber sichergestellt sein, dass Passwortänderungen nur über dieses Gateway erfolgen. Außerdem muss zusätzlich ein Client regelmäßig überprüfen, ob Passwörter bereits abgelaufen sind und solche Einträge dann entsprechend sperren. Wie bei allen anderen Netzwerkprotokollen, bilden Angriffsszenarien, wie „Man in the Middle Attack“ und das Abhören von Netzverbindungen weitere mögliche Gefahren. Das Ziel eines solchen Angriffs ist es, den Computer des Angreifers logisch zwischen den beiden kommunizierenden Computern zu postieren, um den gesamten Datenverkehr zu kontrollieren. Abhilfe bringen bei einem solchen Szenario digitale Signaturen. Wenn für die LDAP-Kommunikation, insbesondere beim Authentifizierungsvorgang, TLS verwendet wird, sollten aber auch solche Angriffe nicht fruchten. Während der Initiierung einer TLS-Verbindung kann sowohl eine Server- als auch eine Client-Authentifizierung mittels X.509-Zertifikaten durchgeführt werden, wodurch auch „Man in the Middle“-Angriffe ausgeschlossen werden können. LDAP in der AnwendungLDAP kommt in den unterschiedlichsten Bereichen und Funktionen zur Anwendung. Der Umfang verzeichnisartiger Informationen nimmt in starkem Maße zu. Nachteilig ist, dass diese Informationen oftmals in verschiedenen proprietären Datenbanken abgelegt sind. LDAP bietet ein flexibles, einfach zu handhabendes Standardprotokoll zur Verwaltung all dieser Informationen. Die direkte Integration von LDAP-Unterstützung in die Client-Programme vereinfacht die Umstellung bzw. das Neuprogrammieren von Verzeichnisdienst-Clients. Außerdem lassen sich die Verwaltungsdaten von Betriebssystemen auf LDAP-Servern ablegen, sofern die Betriebssysteme ausreichend modular gestaltet sind. Derzeit ist es z.B. unter Linux und Solaris dank PAM (Pluggable Authentication Module) bzw. NSS (Name Service Switch) möglich, die gesamte Benutzerverwaltung im Verzeichnis zu halten und zu pflegen. Verschiedene Daemon-Software wie der sendmail-MTA, der Apache-Webserver oder Samba können ebenfalls ihre Benutzerverwaltungstabellen aus LDAP-Verzeichnissen beziehen. Auch ausgewachsene Systems Management-Software wie Tivoli oder HP OpenView gewinnen durch den Einsatz von LDAP-Verzeichnissen an Flexibilität. Authentifizierung/SystemverwaltungEin großes Anwendungsgebiet für LDAP sind Authentifizierungen. Hier liegen die Benutzerinformationen wie Username und Passwort im Verzeichnis. So kann das System den Benutzer gegen das Verzeichnis authentifizieren. Dies gilt übrigens nicht nur für die verschiedenen Unix-Plattformen, sondern zum Beispiel auch für die Regelung des Zugangs zu Webseiten. Die Einsatzmöglichkeiten für die elektronische Authentifizierung sind vielfältig. Ein entsprechendes Verfahren kann prinzipiell in jede Client-Server- oder Multi-Tier-Anwendung integriert werden, um den Clients oder auch einzelnen Anwendern den Zugriff auf die entsprechenden Systemkomponenten zu gewährleisten. Darüber hinaus lassen sich mithilfe einer elektronischen Authentifizierung auch komfortable Single Sign-On-Lösungen realisieren, d.h., ein Anwender meldet sich einmalig bei einer bestimmten Serverkomponente (z.B. LDAP-Verzeichnis) an und bekommt dabei die seiner Rolle entsprechenden Rechte zugewiesen. Ab diesem Zeitpunkt hat der Anwender die Möglichkeit, auf weitere Anwendungen – zu deren Nutzung er berechtigt ist – zuzugreifen, ohne sich bei jeder genutzten Anwendung neu anmelden (authentifizieren) zu müssen (siehe Abbildung 3.13). Ein denkbares Szenario ist die einmalige (morgendliche) Anmeldung eines Anwenders an seinem Arbeitsplatz-PC, danach hat er Zugang zum Intranet, Internet und dezidierten Anwendungssystemen (z.B. SAP, FIBU, MIS), ohne weitere Benutzernamen und/oder Passwörter eingeben zu müssen. Zudem kommt LDAP vermehrt zur Anwendung im Bereich der Mailserver (Adressbuch), einmal zur Authentifizierung und auch zur Speicherung ihrer Konfigurationen und zur Abfrage von Empfängern Identity ManagementAls Speicherort aller Informationen über die gemanagten Identitäten dient in der Regel ein LDAP-Verzeichnis (siehe Abbildung).  Multifunktional: Beispiel einer LDAP-Anwendung in Unternehmen. AdressbuchAls Adressbuch findet LDAP häufiger Verwendung, beispielsweise zum Einbinden von Benutzerdaten in Webseiten oder als unternehmensweites Adressbuch mit Schnittstelle zu den Mailprogrammen. Praktisch hierbei ist, dass die Informationen des Benutzerverzeichnisses verwendet werden können, so dass ein Benutzer einmal angelegt wird und dann auch sofort in allen Adressbüchern auftaucht. Gleichzeitig können die Informationen des Benutzerverzeichnisses für die Authentifizierung verwendet werden. LDAP-ToolsAn dieser Stelle werden die Befehle von OpenLDAP unter Linux vorgestellt. Die wichtigsten LDAP-Tools sind: ldapsearch – Suchen im LDAP-Verzeichnis Das Programm ldapsearch dient dazu, nach Attributen oder Werten von Attributen im Verzeichnisbaum zu suchen. Der Output von ldapsearch entspricht in der Syntax einem LDIF-File. So kann dieser Output direkt wieder verwendet werden, um zum Beispiel Daten von einem Teil des LDAP-Baums in einen anderen zu kopieren.Unter Lotus Domino und im IBM Directory Server ist ldapsearch standardmäßig implementiert. ldapadd – Hinzufügen von Einträgen in das LDAP-Verzeichnis ldapmodify – Ändern von Einträgen im LDAP-Verzeichnis ldapdelete – Löschen von Einträgen im LDAP-Verzeichnis Die Programme ldapadd und ldapmodify sind identisch. Bei ldapadd wird ldapmodify lediglich mit dem Parameter HINZUFÜGEN aufgerufen. Mit ldapmodify lassen sich Änderungen an Objekten im LDAP-Baum durchführen. Dazu bietet ldapmodify zwei Möglichkeiten: Entweder tippt man die Informationen in der Kommandozeile ein oder erstellt zunächst eine LDIF-Datei und übergibt diese dann an ldapmodify. ldapmodrdn – Umbenennen von Einträgen im LDAP-Verzeichnis ldappasswd – Ändern von Benutzerpasswörtern im LDAP-Verzeichnis. Mit freundlicher Genehmigung von www.addison-wesley.de
|
In diesem Beitrag
|
