Verzeichnisdienste/Offen für künftige Erweiterungen

LDAP sorgt für Kontakte im Corporate Directory

03.07.1998

Ein Blick auf die ökonomischen Zusammenhänge verdeutlicht schnell die Bedeutung unternehmensweiter Verzeichnisdienste. Wenn beispielsweise 1000 Mitarbeiter eines Unternehmens jeden Tag nur zehn Minuten mit der Suche nach Daten verbringen, dann bedeutet dies bei durchschnittlichen Lohnkosten von 100 Mark pro Stunde jährliche Kosten von über drei Millionen Mark. Diese Ausgaben lassen sich mit der Einrichtung von Directories einsparen. Rechnet man die nicht kalkulierbaren Wettbewerbsvorteile durch effizientere interne Prozesse hinzu, so amortisieren sich die Investitionen in unternehmensweite Verzeichnisdienste (Directory Services, neuerdings wird auch der Begriff "Corporate Resource Directories" (CRDs) gebraucht - schnell.

Die Einsatzgebiete für CRDs sind vielfältig. Neben klassischen Telefonlisten und Adreßdatenbanken können Raumbelegungslisten ebenso in einem Directory abgelegt werden wie Kundengesprächsdaten, Schlüsselverwaltungen oder E-Mail-Adressen. Angesichts dieser Vorteile entscheiden sich immer mehr Unternehmen zur Einführung einer verzeichnisbasierten Lösung. Neben Großunternehmen wie Siemens oder der Deutschen Bank setzen immer mehr Mittelständler wie beispielsweise der Automobilzulieferer Winklhofer & Söhne auf diesen Ansatz. Der international aktive bayerische Anbieter stand vor Frage, wie er eine hohe Zahl an Kontaktdaten effizient pflegen sollte. Angepeilt war eine herstellerunabhängige Lösung, die sich mit ihren Schnittstellen reibungslos in die bestehende DV-Landschaft einfügten sollte.

Gemeinsam mit dem Münchner Softwareunternehmen IC Con- sult, das die Implementierung übernahm, entschied man sich für ein CRD. "Wir mußten alle bestehenden Datenquellen berücksichtigen", erklärt Ulrich Lembach, Projektleiter bei Winklhofer & Söhne, "und gleichzeitig eine für das ganze Unternehmen durchgängige Lösung entwickeln, die auch im Außendienst funktioniert." Der Automobilzulieferer setzte bei der Directory-Technologie auf offene Standards. Die Entscheidung fiel zugunsten des OSI-Standards X.500 in Verbindung mit "Outlook 98" als Benutzer-Schnittstelle. "Wir benötigen Werkzeuge, die unternehmensweite Prozesse optimal unterstützen und von den Anwendern schnell und problemlos angenommen werden", erklärt Lembach die Wahl. Zudem, so die Kritik des Projektkleiters, orientieren sich die meisten Tools zu stark an technischen Strukturen und nicht an Geschäftsabläufen.

Für die Wahl von Outlook zum Zugriff auf das Corporate Directory sprach auch, daß fast alle PC-Arbeitsplätze unter Windows laufen. Neben einer Kostensenkung hat dies den Vorteil, daß man auf dem Anwender-Desktop stets ein homogenes, aktuelles Produkt vorhält. Zudem begrenzt das den Schulungsaufwand, und das einmal erworbene Know-how der Anwender wird effizient genutzt. Weiterhin sprach für diesen Ansatz die nahtlose Integration in die restlichen Windows-basierten Applikationen. Dabei liefert Outlook mit Tools wie E-Mail, Terminplanung und Notizfunktion das Rüstzeug für die organisatorischen Anforderungen. Obwohl der Umgang mit den Outlook-Policies für den Administrator nicht ganz einfach ist, ist dies für Winklhofer & Söhne die wirtschaftlichste Lösung.

Um von der grafischen Benutzer-Schnittstelle Outlook per LDAP (siehe Kasten "LDAP...") auf das Corporate Directory zugreifen zu können, brauchten die Arbeitsplatz-PCs eine Komponente aus der "Dirx"-Familie von Siemens- Nixdorf. Hierzu wurde das LDAP-fähige "Dirxdiscover" als Outlook-Ergänzung auf jedem Client installiert. Benötigt Outlook einen Verzeichniseintrag, erhält die Ergänzung per Dynamic Data Exchange (DDE) den Auftrag, eine LDAP-Anfrage an den X.500-Server zu formulieren. Durch diese modulare Interprozeßkommunikation sind alle Schnittstellen sauber gekapselt, und die Einzelkomponenten lassen sich bei Bedarf leicht austauschen oder durch neuere Versionen ersetzen.

Als logisches Gegenstück zu den Outlook-Clients fungiert ein Windows-NT-Server mit "Exchange" für 150 User. Diese Plattform kann zusätzlich auch als einfacher Zugang zum Intranet genutzt werden. Auf dem NT-Server läuft auch das X.500-Direc- tory "Dirx 4.0" von Siemens-Nixdorf sowie eine Netzwerk-Faxlösung. Der LDAP-Server ist eine Komponente von Dirx und wird unter NT ebenso wie der DSA-Prozeß (siehe Kasten) von X.500 als Service realisiert.

"Dank seiner weitgehenden Standardisierung und Vollständigkeit ist X.500 derzeit die erste Wahl für Verzeichnisdienste", erklärt Werner Pfadler, Geschäftsführer von IC Consult, die Implementierung. LDAP dagegen lobt Pfadler, der die Directory-Realisierung bei dem Automobilzulieferer übernahm, als den ressourcensparendsten Weg, um mit Windows-Clients auf ein X.500-Directory zuzugreifen.

Weil die Werkzeuge zum Einpflegen der Daten im ursprünglichen Zustand nicht den unternehmensinternen Prozessen entsprachen, mußten sie an die spezifischen Gegebenheiten angepaßt werden. Die Hauptfrage war hierbei, wer wann welche Daten aktualisieren darf. Damit ein Vertriebsmitarbeiter Änderungen direkt beim Kunden vor Ort vornehmen kann, erhalten die mobilen Clients eine Kopie der nötigen Directory-Einträge. Nimmt der Mitarbeiter Änderungen vor, so werden sie bei der nächsten Verbindung zum Firmennetz per E-Mail an das CRD weitergegeben. Um Konflikte bei mehreren gleichzeitigen Änderungen zu vermeiden, ist eine Feinabstimmung der Berechtigungen erforderlich sowie der Aufbau von Eintragsregeln.

In der Praxis wird eine geänderte Kontaktinformation per E-Mail durch die Windows-Schnittstelle oder per MAPI an den Exchange Server geschickt. Dieser sortiert sie regelbasiert und übergibt die Daten dann in das Corporate Directory.

Damit später entschieden werden kann, wer Schreib- und Leserechte für diesen Datensatz besitzt, speichert das CRD die Kundeninformationen zusammen mit der Identifikation des Absenders. Der Anwender erhält vom Server zur Sicherheit per E-Mail eine Bestätigung, daß seine Daten eingegangen sind.

Um die Datenkonsistenz zu gewährleisten, überwacht der auf dem Server laufende Mailbox-Agent die eingehenden E-Mails und prüft, ob ein Datensatz alle erforderlichen Mindestinformationen für einen Eintrag ins Directory umfaßt. Enthält eine Nachricht beispielsweise nur bruchstückhafte Kontaktinformation, wie Vornamen und eine Notiz, ist sie wahrscheinlich nur für den Ersteller interessant und wird nicht ins globale Verzeichnis eingetragen. Kommen weitere Informationen zu einem Datensatz hinzu, entscheidet der Mailbox-Agent jeweils neu, ob sie für eine globale Verfügbarkeit relevant sind. Der "gläserne Benutzer" wird vermieden, da persönliche Notizen der Anwender nur lokal auf dem Arbeitsplatz gespeichert sind.

Die Kommunikation mit den Arbeitsplatzrechnern ist grundsätzlich bidirektional. Zum Einstellen neuer oder geänderter Verzeichnisinformationen wird als Message-Queue die Out-Queue von Outlook benutzt. In der Richtung vom Server zum Client sorgt Dirxdiscover für die LDAP-Verbindung zum Directory. LDAP ist in dieser Anwendung also ein reines Abfrageprotokoll. Obwohl die Komponenten und LDAP prinzipiell auch das Anlegen und Ändern von Daten unterstützen, werden per LDAP keine Änderungen an Datensätzen vorgenommen.

Dieses scheinbar aufwendige Schema hat entscheidende Vorteile bei den mobilen Clients. Weil die Synchronisation des Anwenderverzeichnisses per Message-Queues erfolgt, kann der Mobilrechner des Außendienstmitarbeiters alle Änderungen wie gewohnt annehmen und bei der gelegentlichen Einwahlverbindung ins Firmennetz übertragen. Das Notebook erhält bei dieser Gelegenheit per Download die aktualisierten Directory-Datensätze für seine lokale Kopie in der "Kontakte"-Funktion von Outlook. In der lokalen Kopie wird dabei per Attribut vermerkt, welche Datensätze aus dem zentralen Directory kommen. Hierdurch vereinfacht sich ein späterer Abgleich, da nur veränderte Datensätze ausgetauscht werden müssen.

Verwirklichung eines Meta-Directory

Zudem besitzt jeder Kontaktdatensatz eine eindeutige Identifikationsnummer, ist also unabhängig von Namen oder anderen Suchkriterien eindeutig für alle Teilnehmer zu identifizieren. Falls sich beispielsweise nur der Name des Ansprechpartners beim Kunden ändert, können der Datensatz und alle seine Referenzen beibehalten werden.

Der Zugriff über LDAP entspricht im gezeigten Beispiel dem Gedanken eines echten Meta-Directories, bei dem Datenhaltung und Zugriff für den Benutzer transparent in seinen Applikationen zusammengeführt werden. Diesen modularen Ansatz wählen viele Unternehmen, um eine solide Grundlage für Erweiterungen zu erhalten. Ein weiterer logischer Schritt wäre beispielsweise die Kopplung von Telefonanlage und Computersystem mittels Computer Telephony Integration (CTI). Auch Module von SAP R/3 können von den stets aktuell gehaltenen CRD-Einträgen profitieren. Mit Chipkarten, digitalen Signaturen und X.509-Kryptotechnik bieten sich zudem umfangreiche Einsatzbereiche für die Zukunft. "Der Vorteil des Meta-Directory liegt in der logischen Zentralisierung mehrerer objektorientierter Datenhaushalte für personen- und ressourcenbezogene Daten", erklärt Jürgen Biermann, Projektleiter bei IC Consult. Für die Recherche und Administration erweist sich dabei LDAP als zukunftsichere Schnittstelle für den Zugriff auf die unternehmensweiten Verzeichnisdienste.

LDAP (Lightweight Directory Access Protocol) - der Universelle Weg

Der Anwender von PC-Netzen hat bei Directory Services die Qual der Wahl. Mit den klassischen Novell Directory Ser- vices, Lotus Notes, Banyans Streettalk und den angekündig- ten Active Directories von Microsoft konkurriert das Angebot der offenen Systemwelten.

Das seit 1988 standardisierte X.500 und seine 1993 verbesserte Variante X.500 (93) wird vor allem in großen Unternehmen eingesetzt, um für heterogene Umgebungen ein universelles Directory mit Replikations- und Sicherheitsstandards zu erhalten. Die Datenhaltung der Directory-Informationen ist dabei unabhängig von X.500. Sie kann beispielsweise auf ISAM- oder SQL-Datenbanken erfolgen. Mehrere X.500-Server (Directory Service Agents = DSAs) können sich einen Verzeichnisbaum teilen.

Die Weiterleitung von Anfragen ist durch X.500 ebenso geregelt wie eine Single-Master-Replikation durch das Directory Information Shadowing Protocol (DISP). Leider benötigt das in X.500 vorgesehene Directory Access Protocol (DAP) einen kompletten OSI-Protokoll-Stack. Der im Vergleich zu TCP/IP oder anderen Netzprotokollen deutlich höhere Implementierungsaufwand und Ressourcenverbrauch verhinderte lange Zeit den X.500-Erfolg auf der Client-Seite.

Mit der Entwicklung des Lightweight Directory Access Protocol (LDAP) an der Universität von Michigan wurde diese Barriere ab 1995 aufgehoben. Durch die Beschränkung auf TCP/IP als Kommunikationsprotokoll und das Weglassen der unwichtigeren X.500-Funktionsaufrufe stellt LDAP eine einfach zu benutzende Client-Schnittstelle dar. Je nach Anwendung geht man von einer Entlastung der Client-Ressourcen bis zum Faktor zehn aus. Der Siegeszug des Internet und damit von TCP/IP hat schließlich auch einen universellen Bedarf an Directory-Informationen und entsprechend mit LDAP ausgerüstete Clients wie den Netscape Browser hervorgebracht.

Die De-facto-Standardisierung der Clients hat praktisch alle Anbieter von Verzeichnisprodukten dazu bewogen, sich auf diese offene Plattform einzustellen. LDAP ist in seiner gegenwärtigen Version 2 noch nicht vergleichbar mit dem mächtigeren DISP oder den umfangreichen Sicherheitsstandards unter DAP/OSI. Mit der Einführung der dritten LDAP-Version sollen jedoch viele dieser Einschränkungen aufgehoben werden. Dem Anwender steht dann mit LDAP ein umfassendes Zugangsprotokoll zur Verfügung.

Angeklickt

Für TCP/IP-Clients ist LDAP das Mittel der Wahl beim Zugriff auf X.500-Directories. LDAP ist weitestgehend an den X.500-Standard angelehnt, so daß keine Kompatibilitätsprobleme auftreten. Lediglich die Funktionsvielfalt ist auf den für Clients typischen Umfang beschränkt. Zudem vermeidet der Anwender so die Abhängigkeit von einem bestimmten Hersteller und ist bei der Wahl seiner Applikationen frei. Ferner bietet die Nutzung der LDAP-Schnittstelle die Möglichkeit, später neue Anwendungen wie computergestützte Telefonie oder SAP R/3 in das unternehmensweite Directory zu integrieren.

Peter Averkamp ist freier Journalist in München.