Bundesamt für Sicherheit in der Informationstechnik

M 4.388 Sichere Authentisierung gegenüber OpenLDAP

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Um Open LDAP zu nutzen, ist es in der Regel notwendig, dass der Verzeichnisdienst einer Sitzung die Identität eines Benutzers zuordnen kann. Nur dann kann der Verzeichnisdienst sinnvoll eingesetzt werden, um z. B. Betriebssystemressourcen zu verwalten und nur dann greifen die festgelegten Zugriffsrechte (siehe M 4.387 Sichere Vergabe von Zugriffsrechten auf OpenLDAP ). Im Rahmen des "binds" am slapd-Server wird deshalb die Identität des Benutzers angegeben. Geschieht dies nicht, wird von einem anonymen Zugriff (anonymus) gesprochen. Wird die Identität im Rahmen des "binds" angegeben, so sollte der Benutzer nachweisen, dass er tatsächlich die Identität hat, die er vorgibt. Ist ein solcher Nachweis nicht notwendig, kann sich jeder Benutzer mit einer beliebigen Identität anmelden, es handelt sich dann um eine nicht authentisierte Nutzung (unauthenticated).

Anonyme Benutzer

Wenn nicht im Rahmen der Planung von OpenLDAP (siehe M 2.484 Planung von OpenLDAP ) entschieden wurde, dass der Verzeichnisdienst anonym genutzt werden darf, muss die anonyme Nutzung durch die Konfigurationsdirektive "disallow bind_anon" unterbunden werden.

Wenn der Verzeichnisdienst zwischen verschiedenen Benutzern unterscheiden soll, muss auch eine Authentisierung stattfinden. Eine Anmeldung ohne Identitätsnachweis sollte außerhalb von Teststellungen nicht zugelassen werden. Die Authentisierung ist mit der Konfigurationsdirektive "require authc" zu erzwingen.

Authentisierung mittels Passwort

Die grundsätzliche Methode, die OpenLDAP zur Authentisierung eines Benutzers vorsieht, ist die Kombination einer Benutzerkennung und eines Passwortes, sie wird als "simple bind" bezeichnet. Diese Authentisierungsmethode gilt dann als sicher, wenn das verwendete Passwort nur dem zugehörigen Benutzer bekannt ist.

Übertragung des Passworts

Nach den Spezifikationen des Standards LDAPv3 wird das Passwort zur Authentisierung im Klartext an den Server übertragen. Daher muss die Kommunikationsverbindung zwischen Client und Server verschlüsselt werden (siehe M 5.170 Sichere Kommunikationsverbindungen beim Einsatz von OpenLDAP ), damit das Passwort nicht von einem Angreifer abgehört werden kann.

Es wird dringend empfohlen, die mögliche Verschlüsselung der Kommunikationsverbindung durch den slapd-Server nicht nur anzubieten, sondern als Voraussetzung für eine "bind"-Operation zu erzwingen. Andernfalls hängt die Sicherheit einer Verbindung von der Entscheidung und der Fachkenntnis des Benutzers sowie den Fähigkeiten der eingesetzten Client-Software ab. Über die Direktive "security" können global oder datenbankspezifisch Anforderungen an die bestehende Verbindungssicherheit über die Verschlüsselungsstärke für verschiedene Operationen festgelegt werden, beispielsweise durch "security simple_bind=XYZ". Die Angabe XYZ ist durch einen Security Strength Factor (SSF) zu ersetzen. Der SSF ist eine Zahl, die für das Verschlüsselungsverfahren und die verwendete Schlüssellänge steht, die zur Verschlüsselung der eigentlichen Nachrichten mit einer symmetrischen Chiffre verwendetet wird, wie beispielsweise 56 für DES, 112 für Triple DES und 128, 192, oder 256 für AES. Sie sollte mindestens auf 112 festgelegt werden. Gegebenenfalls sind aktuelle Forschungsergebnisse und die Empfehlungen des BSI zu berücksichtigen. In der Direktive aufgeführte Operationen werden bei einer niedrigeren Verbindungssicherheit abgewiesen.

Ablage des Passworts

Ist sichergestellt, dass das Passwort nur gesichert übertragen wird, kann das Passwort immer noch auf Seiten des Servers gefährdet sein. Wird ein Server kompromittiert oder gelingt beispielsweise ein Zugriff auf eine Datensicherung der Verzeichnisdienstobjekte, könnte ein Angreifer Kenntnis von Passwörtern der Benutzer erlangen. Deshalb sind lediglich die Prüfsummen (Hashwerte) von Passwörtern zu speichern. Dem steht entgegen, dass der LDAP-Standard keine gehashten Passwörter unterstützt. OpenLDAP realisiert serverseitig eine Ablage der gehashten Passwörter und unterstützt verschiedene Hashing-Algorithmen. Es sollte ein Algorithmus aus der Gruppe Secure Hash Algorithm (SHA) in der Variante SSHA, das heißt "gesalzen" verwendet werden. Gesalzen bedeutet, dass das Passwort vor Bildung des Hashwertes um einen weiteren Wert ergänzt wird, um Wörterbuchattacken auf das Passwort zu erschweren. Keinesfalls sollte als Hashing-Algorithmus CRYPT ausgewählt werden. CRYPT wird betriebssystemspezifisch implementiert, weshalb die Authentisierung gegenüber OpenLDAP nach einer Migration auf ein anderes Betriebssystem gegebenenfalls nicht mehr funktioniert.

Der slapd-Server wird über die Direktive "password-hash {Algorithmus}" angewiesen, nur den, mit dem angegebenen Algorithmus erzeugten Hashwert eines Passworts, im Verzeichnis abzulegen. Die geschweiften Klammern sind dabei Teil der Syntax, so wird SSHA mittels "password-hash {SSHA}" festgelegt. Die Direktive gilt immer dann, wenn Passwörter über den slapd-Server eingerichtet oder geändert werden, das heißt mittels der Applikation "ldappasswd" oder über eine andere Client-Anwendung.

Werden LDIF-Dateien erzeugt und importiert, so müssen in der Datei angegebene Inhalte des Feldes "userPassword" bereits als Hashwerte vorliegen, wenn ein Hashwert genutzt werden soll. Das gleiche gilt für die Angabe des rootDN-Passworts in der Konfiguration (siehe M 4.384 Sichere Konfiguration von OpenLDAP ). Um Hashwerte von Passwörtern zu erzeugen, ist das slap*-Werkzeug slappasswd zu benutzen. Über den Parameter "-h" wird der zu verwendende Hashing-Algorithmus angegeben, der empfohlene Wert SSHA entspricht der Voreinstellung. Hinter dem Parameter "-s" wird das Passwort im Klartext angegeben. Die Ausgabe des Werkzeugs ist dann mit einem vorangestellten {SSHA} in die LDIF- oder Konfigurationsdatei zu übernehmen. Wird das Werkzeug in der Kommandozeile verwendet, ist die in der Regel eingerichtete Eingabe-Historie vorher abzuschalten, weil das Passwort sonst im Klartext darin gespeichert wird.

Qualität des Passworts

Selbst wenn Passwörter verschlüsselt übertragen und als Hash-Wert abgelegt werden, besteht immer noch die Gefahr, dass Benutzer zu schwache Passwörter verwenden. Sie können beispielsweise durch Wörterbuchattacken leicht ermittelt werden. Es sollte organisatorische Vorgaben geben, damit Benutzer keine schwachen Passwörter wählen (siehe M 2.11 Regelung des Passwortgebrauchs ). OpenLDAP unterstützt derartige Vorgaben technisch durch das Overlay "ppolicy" (Password Policy). Das Overlay setzt Regeln wie eine minimale Länge eines Passwortes oder ein minimales und maximales Alter bis zur möglichen bzw. nötigen Änderung eines Passworts um. Außerdem kann es diverse Qualitätsprüfungen von Passwörtern vornehmen und führt pro Benutzer eine Liste früherer Passwörter, um zu verhindern, dass diese erneut verwendet werden. Über Passwortregeln hinaus sperrt das Overlay "ppolicy" das Passwort-Attribut nach mehrmals fehlgeschlagener Authentisierung für einen vorgegebenen Zeitraum für jeglichen Zugriff, um eine Brute-Force-Attacke auf das Passwort zu verhindern. Die jeweiligen Vorgaben, zum Beispiel wie lang ein Passwort sein muss oder nach wie vielen Fehleingaben eine Sperrung erfolgt, können in Richtlinien (policies) detailliert festgelegt werden. Richtlinien lassen sich benutzerspezifisch oder für das gesamte Verzeichnis sowie für Teilbäume zuordnen. Der rootDN ist wird nicht durch das Overlay "ppolicy" eingeschränkt.

Weitere Authentisierungsmechanismen

OpenLDAP ist in der Lage, für die Authentisierung von Benutzern auf Funktionen anderer Anwendungen zurückzugreifen. So können auch Authentisierungsmechanismen verwendet werden, deren Sicherheit über diejenige von Benutzerkennung und Passwort hinausgeht (strong bind). Notwendig ist dafür die Abstraktionsschicht Simple Authentication and Security Layer (SASL). SASL unterstützt über sogenannte Mechs verschiedene Authentisierungs- und Verschlüsselungsmechanismen und kann selbst wiederum auf externe Verfahren zurückgreifen. So können Benutzer unter anderem über SSL / TLS -Zertifikate (siehe M 5.66 Clientseitige Verwendung von SSL/TLS ) oder durch das Kerberos-Verfahren authentisiert werden. Die Authentisierung wird von OpenLDAP an SASL delegiert. Besteht für den Informationsverbund ein hoher oder sehr hoher Schutzbedarf oder existiert bereits eine Authentisierungsinfrastruktur außerhalb von OpenLDAP, sollte die Anbindung via SASL erfolgen.

Prüffragen:

  • Ist sichergestellt, dass die Authentisierung am OpenLDAP-Verzeichnisdienst ausschließlich über verschlüsselte Verbindungen erfolgt?

  • Werden OpenLDAP Passwörter lediglich als Hashwerte gespeichert und wird dafür ein geeigneter Hashing-Algorithmus verwendet?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK