Bundesamt für Sicherheit in der Informationstechnik

M 2.484 Planung von OpenLDAP

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

Verantwortlich für Umsetzung: Administrator, Leiter IT

Der Einsatz von Open LDAP in einer Institution muss sorgfältig geplant werden. Der Planung des konkreten Einsatzes von OpenLDAP geht immer die Maßnahme M 2.403 Planung des Einsatzes von Verzeichnisdiensten voraus. Aus den im Rahmen dieser Maßnahme getroffenen Entscheidungen, insbesondere wie OpenLDAP genutzt werden soll, ergeben sich Anforderungen an OpenLDAP. Die konkrete Planung hängt auch von der verwendeten Infrastruktur ab. Wenn OpenLDAP geplant wird, sind mindestens die folgenden Punkte zu berücksichtigen:

  • Einbindung in andere Anwendungen
    OpenLDAP besitzt zahlreiche Möglichkeiten, zur Unterstützung in Betriebssysteme und andere Anwendungen eingebunden zu werden, zum Beispiel:
    • zur Benutzerverwaltung in Unix- und Linux-Systemen über das Pluggable Authentication Module (PAM) und den Name Service Switch (NSS),
    • als zentraler Verzeichnisdienst in heterogenen Netzen oder zusammen mit Active Directory mittels Samba (siehe B 5.17 Samba ) oder
    • als Adressbuch und Zertifikatsverzeichnis für E-Mail-Programme wie Microsoft Outlook oder Mozilla Thunderbird (siehe B 5.3 Groupware ).
    Soll OpenLDAP gemeinsam mit anderen Anwendungen verwendet werden, so müssen die Planung, Konfiguration und Installation von Anwendungen und OpenLDAP unbedingt aufeinander abgestimmt werden. Im Rahmen der IT-Grundschutz-Systematik sind korrespondierende Maßnahmen parallel umzusetzen. Die "OpenLDAP Frequently Asked Questions" (http://www.openldap.org/faq) halten Informationen zur Anbindung an andere Anwendungen in einem eigenen Abschnitt unter Faq-O-Matic | OpenLDAP Software FAQ | Integration bereit.
  • Auflösung von Abhängigkeiten
    Um alle Funktionen eines Verzeichnisdienstes gemäß des LDAPv3-Standards zu erfüllen, ist OpenLDAP darauf angewiesen, Funktionen weiterer Anwendungen zu nutzen. Dies gilt insbesondere für die zur Datenhaltung verwendete BerkeleyDB, für die OpenLDAP optimiert wurde. Nur mit dieser hierarchischen Datenbank verfügt OpenLDAP über seinen vollen Funktionsumfang. Dabei ist zu beachten, dass es sich bei BerkeleyDB und OpenLDAP um zwei unabhängig voneinander entwickelte Software-Anwendungen handelt. OpenLDAP benötigt eine unterstützte Version der BerkeleyDB.
    Einen Überblick über die unterstützten oder notwendigen Versionen der BerkeleyDB gibt der Anhang "Recommended Versions" des OpenLDAP Administrator's Guide (http://www.openldap.org/doc). Der Anhang gibt auch Auskunft über weitere Softwarepakete, von denen die Funktion von OpenLDAP abhängt. Deren Anforderungen sind zu beachten, besonders die Installation einer Transport Layer Security-Variante wie "OpenSSL" oder "GnuTLS" und die Installation des Simple Authentication and Security Layers "Cyrus-SASL". Die denkbare Alternative "GnuSASL" wird in der Version 2.4 noch nicht von OpenLDAP unterstützt. Ohne diese beiden unterstützenden Anwendungen kann OpenLDAP den LDAPv3-Standard nicht vollständig umsetzen. Soll die Authentisierung mit Kerberos abgesichert werden, ist eine Installation der Dienste "Heimdal Kerberos" oder "MIT Kerberos" nötig. Auf die im Anhang der Administrators Guide aufgeführte Software " TCP Wrappers" zur Absicherung der Kommunikation mit dem Verzeichnisdienst sollte zugunsten eines anderen IP-Filter-Mechanismus verzichtet werden (siehe M 4.238 Einsatz eines lokalen Paketfilters ).
  • Auswahl der Konfigurationsmethode
    OpenLDAP unterstützt seit der Version 2.3 zwei verschiedene Konfigurationsmethoden. Die klassische Konfiguration wird statisch in einer Konfigurationsdatei (slapd.conf) vorgenommen, die der Serverprozess "slapd" beim Start einliest. Die aktuellere Konfiguration wird auch als Online-Konfiguration bezeichnet und speichert Konfigurationseinstellungen in einem speziellen Bereich des Verzeichnisbaumes ("slapd-config"). Die Online-Konfiguration bietet mehrere Vorteile:
    • Änderungen der Online-Konfiguration erfolgen durch LDAP-Operationen und sind über eine Netzverbindung möglich, ohne Zugriff auf das Dateisystem des IT -Systems, auf dem OpenLDAP betrieben wird.
    • Die Administration ist mit einfach zu bedienenden grafischen LDAP-Clients durchführbar.
    • Einstellungen in der Online-Konfiguration können zur Laufzeit des Servers geändert werden und werden sofort wirksam, ohne dass ein Neustart des Server-Prozesses "slapd" erforderlich ist.
    • Die Konfiguration kann als Teil des Verzeichnisses auf andere Server repliziert werden, wodurch die Administration von verteilten Verzeichnisdiensten erleichtert wird. Zum Beispiel werden Änderungen von Zugriffsrechten schneller auf allen beteiligten Servern wirksam.
    Andererseits unterstützen nicht alle Backends und Overlays die Online-Konfiguration. Zudem schützt die statische Konfiguration vor unüberlegten Änderungen der Konfiguration und begrenzt die Auswirkungen von Sicherheitsvorfällen.
    Bei der Planung von OpenLDAP ist ein Konfigurationsweg auszuwählen und dann durchgehend beizubehalten. Die Online-Konfiguration ist umso sinnvoller,
    • desto umfangreicher der Verzeichnisdienst ist,
    • desto höher seine Verfügbarkeitsanforderungen sind und
    • desto mehr Server an einem verteilten Aufbau beteiligt sind.
  • Auswahl der zu verwendenden Backends
    Aus den geplanten Nutzungsmöglichkeiten des Verzeichnisdienstes folgt, welche Backends für die spätere Installation und Konfiguration vorzusehen sind. Details zur Auswahl von Backends enthält die Maßnahme M 2.485 Auswahl von Backends für OpenLDAP .
  • Auswahl der zu verwendenden Overlays
    Ebenso wie für Backends ist auch eine Liste der zu verwendenden Overlays zu erstellen. Um über den Einsatz von Overlays zu entscheiden, sollte das entsprechende Kapitel des OpenLDAP Administrator's Guide durchgearbeitet werden. Für jedes Overlay ist zu prüfen, ob dieses einen experimentellen Status hat oder nicht mehr weiter gepflegt wird. In beiden Fällen sollte der Einsatz in einer Produktionsumgebung vermieden werden. Weiter ist für jedes Overlay über die zugehörige Dokumentation, wie der Manpage, zu prüfen, ob die Online-Konfiguration unterstützt wird. Bei der Auswahl von Overlays ist zu berücksichtigen, dass die Reihenfolge ihres Aufrufs ("stapeln") Auswirkungen auf ihre Funktionsfähigkeit haben kann, Dies ist beispielsweise der Fall, wenn ein Overlay Daten umformt, die von einem anderen Overlay in der ursprünglichen Form erwartet werden.
  • Umsetzung der festgelegten Baumstruktur
    Während der Planung des Verzeichnisdienstes wurde dessen Struktur festgelegt, die nun der Planung von OpenLDAP zugrunde zu legen ist:
    • Es muss ein geeignetes Namensmodell ausgewählt werden, sofern dies noch nicht im Rahmen der allgemeinen Planung erfolgt ist. Das klassische Namensmodell des X.500 Standards ist auf eine Abbildung von Organisationsstrukturen ausgerichtet und kennt Bezeichner wie "OrganizationalUnit" (OU), "Organization" (O) und "Country" (C) (z. B. OU=bsi, O=bund, C=de). Demgegenüber erlangt das Namensmodell im Internet-Stil eine immer größere Verbreitung. Dieses Namensmodell verwendet auf den oberen Ebenen der Baumstruktur lediglich "DomainComponents" (DC), ohne die einzelnen Bestandteile unterschiedlich zu bezeichnen ( z. B. DC=bsi, DC=bund, DC=de).
    • Geeignete Schemas, die zum Namensmodell und zur gewünschten Struktur passen, sind auszuwählen. Schemas legen fest, welche Daten in der Datenbank in welcher Form gespeichert werden können und welche Beziehungen zwischen den Daten bestehen. OpenLDAP bringt alle in RFC s spezifizierten Schemas bereits mit, weitere sind im Internet verfügbar. In der Regel sind die vorhandenen Schemas für normale Einsatzzwecke ausreichend. Sind dennoch eigene Schema-Erweiterungen notwendig, müssen diese mit äußerster Sorgfalt vorgenommen werden, denn von ihnen hängt die Funktionsfähigkeit des Verzeichnisdienstes ab.
    • OpenLDAP bietet durch Overlays zudem die Möglichkeit, Attribute von Objekten im Betrieb einzuschränken. Ein entsprechend konfigurierter slapd-Server wird dann nach den Schemas zulässige Belegungen von Objekten nicht durchführen. Detailinformationen sind in der Maßnahme M 4.386 Einschränkung von Attributen bei OpenLDAP zu finden.
    • Schemas können auch unabhängig von der festgelegten Baumstruktur notwendig sein, damit Backends und Overlays fehlerfrei funktionieren, die ihre Daten via LDAP oder im Format LDIF ablegen. Beispielsweise benötigt das Backend "back-monitor" das Schema "core.schema". Derartige Abhängigkeiten sind über die Dokumentation der Komponenten zu prüfen und zu berücksichtigen.
    • Um die Baumstruktur in OpenLDAP festzulegen, ist auch zu entscheiden, ob dynamische Objekte durch das Overlay "dds" (Dynamic Directory Services) zugelassen werden. Solche Objekte werden nach einer festgelegten Zeitspanne oder beim Ausbleiben bestimmter Ereignisse automatisch aus dem Verzeichnisdienst entfernt. Über das Overlay "dynlist" (Dynamic Lists) können zudem dynamische Gruppen gebildet werden. Dynamische Gruppen werden nicht manuell befüllt, sondern enthalten automatisch alle Objekte, die einem definierten Suchkriterium entsprechen. Dadurch können beispielsweise ohne weiteren Wartungsaufwand Gruppen und Listen eingerichtet werden, die alle Mitarbeiter auf einem Stockwerk enthalten. Dynamische Listen können auch für die Zugriffskontrolle (siehe M 4.387 Sichere Vergabe von Zugriffsrechten auf OpenLDAP ) verwendet werden. Dabei ist jedoch Vorsicht geboten, da der verringerte Administrationsaufwand zu unübersichtlichen Zugriffsberechtigungen führen kann.
  • Planung der Benutzerzugriffe
    Der Zugriff durch anonyme Benutzer sollte vermieden werden. Wenn ein anonymer Zugriff dennoch notwendig ist, so sollte der Verzeichnisdienst nur Daten mit geringem Schutzbedarf enthalten. Soll auf einen Teilbereich mit geringem Schutzbedarf zugegriffen werden, während der Verzeichnisdienst auch Daten mit höherem Schutzbedarf enthält, so wird empfohlen, zwei verschiedene slapd-Serverdienste einzurichten, von denen einer anonymen Zugriff erlaubt und nur die Daten mit geringem Schutzbedarf enthält. Dies kann unter anderem durch Replikation gelöst werden (siehe M 4.389 Partitionierung und Replikation bei OpenLDAP ). Dazu wird beispielsweise aus einem Verzeichnisdienst mit Mitarbeiter-Daten nur der Name und die Durchwahl für ein öffentliches Telefonbuch repliziert.
    Zur Planung der Benutzerzugriffe gehört auch, Verantwortlichkeiten von Administratoren festzulegen. So können verschiedene Administratoren für verschiedene Datenbanken im Verzeichnisdienst zuständig sein (siehe auch M 2.407 Planung der Administration von Verzeichnisdiensten ).
  • Planung des Client-Einsatzes
    Die Planung von OpenLDAP darf nicht auf den slapd-Server beschränkt bleiben, auch die Auswahl und Unterstützung durch die Clients muss berücksichtigt werden. OpenLDAP stellt geeignete Anwendungen in Form der ldap*-Werkzeuge bereit. Diese Werkzeuge werden jedoch vollständig über die Kommandozeile gesteuert. Sie erfordern einen hohen Schulungsaufwand und haben nur eine geringe Benutzerakzeptanz. In der Praxis werden meist grafische Werkzeuge eingesetzt oder der Client ist Bestandteil einer Anwendung. Werden beim Anwender bereits Verzeichnisdienste über LDAP gesteuert, sind gegebenenfalls schon Client-Anwendungen im Einsatz, deren Fähigkeiten bei der Planung von OpenLDAP zu berücksichtigen sind. Es kann auch sinnvoll sein, durch den slapd-Server Funktionen zu übernehmen, die nach der LDAP-Spezifikation nicht vorgesehen sind, wenn den Clients entsprechende Funktionen fehlen. Overlays für OpenLDAP stellen solche Funktionen bereit:
    • Durch das Overlay "chain" (Chaining) wird ein Server in die Lage versetzt, selbstständig Referrals (dies sind Verweise auf übergeordnete Server, Repliken etc.) zu verfolgen, statt dem Client die Adresse mitzuteilen, unter der dieser selbst suchen könnte.
    • Durch das Overlay "valsort" (Value Sorting) übergibt der Server Suchergebnisse an einen Client bereits in einer sortierten Reihenfolge.
  • Performance Tuning
    Zuletzt ist bei der Planung auch die benötigte Leistung zu berücksichtigen, die die Verfügbarkeit stark beeinflussen kann. Insbesondere sind häufig gesuchte Attribute zu indizieren.

Prüffragen:

  • Wird die verwendete Version der BerkeleyDB von OpenLDAP unterstützt?

  • Werden Abhängigkeiten von OpenLDAP zu anderen Anwendungen geprüft und erfüllt?

  • Werden Backends und Overlays für OpenLDAP passend zu den Anforderungen ausgewählt?

  • Werden die OpenLDAP-Overlays in der korrekten Reihenfolge eingesetzt?

  • Wird die Auswahl und Unterstützung von Client-Anwendungen für OpenLDAP bei der Planung berücksichtigt?

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