Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.10.2002 - 

Verzeichnisdienste/Entscheidungsgrundlagen für Verzeichnisdienste und künftige Entwicklungen

Technische Anforderungen zur Produktwahl

Mit der Einführung eines Verzeichnisdienstes stehen IT-Verantwortliche vor einer schweren Entscheidung: Das Directory soll immerhin das künftige Rückgrat der Unternehmens-IT bilden, und die Implementierung ist eine komplexe Angelegenheit. Deshalb sollte die Wahl eines Directory gut überlegt werden, damit sich das Unternehmen nicht selbst in eine Sackgasse manövriert. Von Wolfgang Ahrens*

Verzeichnisdienste (Directories) entwickeln sich zu einer immer wichtigeren Komponente der IT-Infrastruktur. Dabei haben viele Unternehmen erkannt, das insbesondere zentrale, unternehmens- und plattformübergreifende Directories erhebliche Rationalisierungspotenziale im IT-Alltag eröffnen. Um diese Potenziale wirklich ausschöpfen zu können, muss ein Unternehmen seine Anforderungen an ein Directory klar definieren.

Die erste Frage im Entscheidungsprozess sollte daher lauten: Brauche ich einen Verzeichnisdienst für eine relativ kleine, homogene Umgebung, oder benötige ich vielmehr ein Full Service Directory, das eine große heterogene Unternehmensumgebung vollständig verwalten kann? Da die Full Service Directories die höchsten Anforderungen bewältigen müssen, wird im Folgenden nur auf diese näher eingegangen.

Um alle zentralen Aufgaben in einer heterogenen IT-Umgebung zu übernehmen, muss ein entsprechendes Directory einer Vielzahl von Kriterien entsprechen. Dazu gehören beispielsweise ein plattformübergreifendes Design, eine leichte Erweiterbarkeit sowie eine hohe Skalierbarkeit. Ferner sollte der Service eine hohe Geschwindigkeit aufweisen und aufgrund seiner zentralen Funktionen ein hohes Sicherheitsniveau offerieren. Ferner ist auf die Unterstützung offener Standards zu achten.

Eines der wichtigsten Entscheidungskriterien stellt das plattformübergreifende Design dar, wenn Unternehmen mehrere Server-Betriebssysteme parallel einsetzen. Nur bei einer möglichst breiten Plattformunterstützung lassen sich tatsächlich alle Systeme einbinden und die Vorteile eines zentralen Verzeichnisdienstes voll ausnutzen. Zu den Directories die wohl die meisten Betriebssysteme unterstützen, zählt zurzeit Novells "Edirectory". Neben Novell Netware läuft es unter Microsofts Windows NT/2000, Linux, Sun Solaris, Tru 64 Unix sowie IBM AIX und dürfte damit die Erfordernisse der meisten Unternehmen an ein Full Service Directory abdecken. Ausschließlich auf Windows-Servern ist dagegen Microsofts Active Directory (AD) einsetzbar. Deshalb kommt es insbesondere für Unternehmen mit einer reinen Microsoft-Server-Umgebung in Frage. "Iplanet IDS" widerum ist aufgrund seiner Netscape-Historie auf Web-Umgebungen spezialisiert, wohingegen "IBM Secureway" eher für Midrange-Systeme konzipiert ist: Neben Sun Solaris und Windows NT unterstützt dieses Verzeichnis AIX, OS/390 und OS/400.

Für Großunternehmen ist ferner die Frage nach der Skalierbarkeit von entscheidender Bedeutung. Die meisten gängigen Directories skalieren lediglich bis zu mehreren Millionen Objekten. So erreichen etwa Iplanet oder AD mit jeweils maximal zehn Millionen Objekten ihre Grenzen. Wesentlich weiter kommen andere Produkte wie etwa das Edirectory. Hier sind Verzeichnisbäume mit bis zu einer Milliarde Objekte realisierbar, wobei jeder einzelne Server mehrere hundert Millionen Einträge enthalten kann.

Standards und Konnektoren

Ein weiteres Augemerk bei der Wahl des passenden Verzeichnisdienstes sollte dem Zusammenspiel zwischen Verzeichnisdienst und Applikationen gelten. Für den Zugriff und den Austausch auf und von Directory-Daten kommt hier meist Lightweight Directory Access Protocol (LDAP) zum Einsatz, von dem im folgenden Absatz noch die Rede sein wird. Zusätzlich zu LDAP sind jedoch meist weitere Konnektoren, Schnittstellen und Protokolle erforderlich, um die Anbindung an möglichst viele Applikationen und/oder weitere Directories zu ermöglichen. Neben LDAP und dem Directory Access Protocol (DAP) gehören hierzu auch die NDS-API, das Active Directory Services Interface (ADSI), Radius, ODBC und JDBC, http und natürlich XML, um nur einige zu nennen. Je größer diese Auswahl ist, desto einfacher ist es für ein Unternehmen, weitere Applikationen zu integrieren oder eigene verzeichnisbasierende Anwendungen zu erstellen. Der Einsatz offener Standards an Stelle proprietärer Formate erleichtert zudem das Entwickeln von verzeichnisbasierten Lösungen.

Grenzen von LDAP

Allgemein üblich ist heute der Zugriff auf Verzeichnisdaten via LDAP, das sich als De-facto-Standard etabliert hat. Das Protokoll ist eine vereinfachte Variante des ursprünglichen Directory Access Protocol (DAP), das für den Zugriff auf X.500-Directories entwickelt wurde. DAP erwies sich nämlich im Alltagseinsatz als zu komplex und konnte sich daher nicht durchsetzen. In der aktuellen Version 3 (LDAPv3) beschreibt LDAP ein Protokoll für den Zugriff von TCP/IP-Clients über einen LDAP-Server auf ein X.500-kompatibles Verzeichnis. Nahezu alle gängigen Directory-Produkte haben LDAP implementiert - Novells Edirectory ebenso wie Microsofts Active Directory, Critical Path oder Iplanet.

LDAP hat jedoch einen Nachteil: es verfügt nur über eine Syntax von zehn Befehlen. Mit deren Hilfe kann das Protokoll Objekte in einem Verzeichnis suchen und abfragen, editieren, anlegen und löschen. Darüber hinaus weist LDAPv3 noch andere entscheidende Schwächen auf, die Unternehmen bedenken sollten. Als reines Zugriffsprotokoll konzipiert, verfügt es selber über keinerlei Replikationsmechanismen. Ferner sind nur schwache Sicherheitsfunktionen implementiert, und eine Zugriffskontrolle ist gar unbekannt. Diese Funktionen müssen somit über den Verzeichnisdienst, seine Clients und ergänzenden Applikationen bereitgestellt werden.

Nicht nur die Schwächen von LDAP, auch die eingangs angesprochenen Einsatzgebiete von Verzeichnisdiensten erfordern zusätzliche Sicherheitsfunktionen. Schließlich sollen die Directories als Rückgrat der gesamten Netzwerk-Administration auch zentrale Sicherungsaufgaben übernehmen.

Um dieser Rolle gerecht zu werden, muss ein Directory eine möglichst breite Auswahl von Authentifizierungs- und Sicherheitsfunktionen unterstützen. Neben der üblichen User-Authentifizierung über Passwörter oder persönliche Identifikationsnummern (PINs) sollten auch digitale Zertifikate wie X.509v3 und weitergehende Authentifizierungverfahren wie Tokens oder Smartcards genutzt werden können. Im Idealfall besitzt das Directory ferner eine integrierte PKI Certificate Authority (CA) und ermöglicht so die Ausstellung eigener Zertifikate. Eine Funktion, mit der etwa die Produkte von Novell und Microsoft aufwarten. Ist dies von Haus aus nicht der Fall, sollten zumindest die Public Key Infrastructures (PKIs) von Drittanbietern unterstützt werden. Eine Anforderung, die heute nahezu alle gängigen Produkte erfüllen.

Doch nicht nur die Anwendungen und Daten im Netz sind zu schützen, ebenso ist das Directory selbst zu sichern. In Sachen Verzeichnissicherheit ist zwischen zwei Punkten zu unterscheiden: dem Schutz nur vor unberechtigten Zugriffen einerseits und der Vorbeugung vor Datenverlusten andererseits. Die in einer Baumstruktur abgelegten Verzeichnisdaten sichern die Directories dadurch, dass sie ganze Bäume des Hauptverzeichnisses (Master) oder Kopien von Teilbäumen, auch Replikas genannt, auf mehreren Servern räumlich voneinander getrennt speichern. Diese Replizierung erhöht somit die Ausfallsicherheit, da immer eine aktuelle Kopie bereitsteht, und beschleunigt gleichzeitig die Zugriffsgeschwindigkeit. Die Replizierungstechniken und damit der Sicherheitsgrad unterscheiden sich jedoch teilweise erheblich. Für höchste Sicherheitsansprüche sollten Unternehmen auf Produkte setzen, die eine Multi-Master-Replikation ermöglichen. Dieses Verfahren sichert den Primärbaum durch eine oder mehrere Kopien. Allgemein gilt, je feiner sich die Replizierungsoptionen einstellen lassen, umso besser ist ein Unternehmen in der Lage, das Directory und die vergebenen Zugriffsrechte an seine tatsächliche Organisationsstruktur anzupassen. Ein Beispiel hierfür wäre in einem Konzern die Darstellung jeder Niederlassung durch einen eigenen vor Ort replizierten Teilbaum.

Die Zukunft der Directories

Die Vorteile von Verzeichnisdiensten haben dazu geführt, dass sie in immer neuen Einsatzgebieten zum Zuge kommen. Dies gilt insbesondere für das Management von Anwenderidentitäten und Single-Sign-on im Web oder für UDDI (Universal Data Description and Integration) in künftigen Web-Services-Szenarien. Hier werden gerade erste Weichen gestellt, und Unternehmen sollten dies unter Aspekten der Investitionssicherheit bei der Entscheidung für ein Directory bereits berücksichtigen.

Registries, die auf dem UDDI-Standard aufbauen, gelten als eines der zentralen Elemente für die Infrastruktur der Web-Services. Sie erfassen und organisieren verfügbare Web-Services und ermöglichen den Zugriff auf sie - letztlich funktionieren sie ähnlich wie die "Gelben Seiten" des Internets. Viele Hersteller sehen hierfür LDAP-Verzeichnisse als ideale Speicherorte für UDDI-Daten, denn sie bieten einen skalierbaren, schnellen und sicheren Zugriff auf Informationen. Diese Merkmale, so die Argumentation, gehören zu den Grundvoraussetzungen für den effizienten Einsatz von Web-Services. Novell hat bei der Internet Engineering Task Force (IETF) im Juli 2002 eine Spezifikation eingereicht, um die Rolle von Verzeichnisdiensten innerhalb von Web-Services-Umgebungen genauer zu definieren. Der Vorschlag zeigt auf, wie UDDI-Daten in einem LDAP-Verzeichnisdienst darzustellen sind. Ferner definiert er ein Schema zur Darstellung der zentralen UDDI-Datentypen in einem LDAPv3-Verzeichnis mit den Befehlen businessEntity, businessService, bindingTemplates, tModel sowie der publisherAssertion.

Weitere Entwicklungsschritte zielen insbesondere auf die Schaffung eines Standards für das verzeichnisbasierte Single-Sign-on und das Management der User-Identitäten in künftigen Web-Services-Umgebungen. Wegweisend sind hier insbesondere die Gründung der Liberty Alliance (http://www.projectliberty.org/) sowie die Verabschiedung einer neuen XML-Norm, die den Austausch von Nutzer-Informationen vereinheitlicht und so auch einen unternehmensübergreifenden Single-Sign-on ermöglicht.

Der von der Liberty Alliance angestrebte offene, universelle Standard für den Single-Sign-on könnte dann die nahtlose Zusammenarbeit zwischen Anwendern und Service-Providern ermöglichen. Der Vorteil für den Endanwender wäre dabei, dass er sich nur einmal auf einer Web-Site anmeldet und dann automatisch auch für alle anderen Sites authentifiziert ist, wenn diese innerhalb so genannter Federations of Trust kooperieren und User-Informationen austauschen. Dennoch kommt dabei der Datenschutz nicht zu kurz: Privatpersonen, die zum Beispiel einen Liberty-kompatiblen Freemail-Dienst nutzen, müssen keine beliebige und unkontrollierte Weitergabe ihrer Daten fürchten.

Ein erstes technisches Gerüst für diese Pläne steht bereits. So beschreibt der XML-Standard SAML (Security Assertion Markup Language) ein einheitliches Format der Authentifizierungsdaten beim Single-Sign-on von Web Services. SAML definiert zudem Mechanismen für den Austausch von Authentifizierungs-Informationen und spielt damit für die Spezifikationen der Liberty Alliance eine entscheidende Rolle.

Directory und Web-Services

Aus dem Umfeld dieses Zusammenschlusses haben einige Hersteller schon SAML-fähige Produkte auf den Markt gebracht oder werden dies in naher Zukunft tun. Dazu gehört unter anderem Novell mit "Saturn" sowie einer neuen Version von "Ichain", Sun mit dem "Identity und Directory Server", aber auch Entrust mit dem "Get Access Portal".

Mit der Verabschiedung der Version 1.0 ihrer Spezifikation im Juli 2002 hat die Liberty Alliance ein erstes großes Etappenziel erreicht. Eine zunehmende Anzahl von Unternehmen unterstützt die Liberty Alliance, womit ein standardisiertes, verzeichnisbasierendes Sicherheitskonzept für Anwenderidentitäten im Internet in greifbare Nähe rückt. (hi)

*Wolfgang Ahrens ist Director Systems Engineering bei Novell in Düsseldorf.

Unterschiede

Auf den ersten Blick unterscheiden sich die Produkte der unterschiedlichen Hersteller kaum. Alle offerieren LDAP als Standardverfahren zum Zugriff auf Verzeichnisdaten. Dennoch eignen sich nicht alle Produkte für jedes Einsatzszenario, da Unterschiede in Sachen unterstützte Betriebssysteme oder Skalierbarkeit zu beachten sind.

Abb: Full Service Directory

Im Idealfall wickelt ein Verzeichnisdienst alle grundsätzlichen IT-Funktionen automatisch ab. Quelle: Novell