Innovative Netzwerkstrukturen in der Automobilbranche

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Die Firmengruppe
1.2 Motivation

2 Grundlagen
2.1 Strukturen
2.1.1 Domäne und File-Sharing
2.1.2 eMail- und Groupware
2.1.3 ERP-System
2.1.4 Data Warehouse
2.1.5 Archiv
2.1.6 Entwicklungsplattformen hibis
2.1.7 Qualitätssicherungssystem hibis
2.1.8 Portalsystem
2.1.9 Weitere Webservices
2.2 Zielsetzung
2.3 Organisation der Arbeit
2.4 Definition Single Sign-On
2.4.1 Vorteile des Single Sign-On
2.4.2 Risiken von Single Sign-On
2.4.3 Gründe für Single Sign-On
2.5 Single Point of Administration
2.6 Verzeichnisdienste
2.6.1 Abgrenzung zu relationalen Datenbanken
2.6.2 X.500-Empfehlungen
2.6.3 Lightweight Directory Access Protocol
2.6.4 Meta Directories

3 Auswahl eines Verzeichnisdienstes
3.1 Analyse der Situation
3.2 Probleme
3.3 Globaler Lösungsansatz
3.4 Kriterienkatalog
3.5 Marktposition der Verzeichnisdienstanbieter
3.6 Beschreibung der Produkte
3.6.1 Proprietäres Closed-Source System
3.6.2 Open-Source-Software-System
3.6.3 Closed-Source-Software mit Open-Source-Integration
3.6.4 Vergleich der Systeme
3.7 Systemstrategien
3.8 Entscheidung

4 Migrationskonzept
4.1 Systemauswahl für die prototypische Migration
4.2 Szenarien
4.2.1 Big-Bang-Methode
4.2.2 Step-by-Step-Methode
4.2.3 Methodenauswahl
4.3 Planungsrichtlinien für eDirectory
4.4 Planungsrichtlinien der eDirectory-Partitionierung
4.5 Planungsrichtlinien zur eDirectory-Replikation
4.6 Planung einer unternehmensweiten Sicherheitsrichtlinie
4.6.1 Generelles
4.6.2 Privilegienvergabe
4.6.3 Administration
4.6.4 Datenkommunikation
4.6.5 Zertifikatsautorität
4.6.6 LDAP-Zugriff
4.6.7 Clientzugriff auf den Verzeichnisdienst
4.6.8 Remotezugriff zur Fernadministration
4.7 Erstellungsreihenfolge einer unternehmensweiten Richtlinie
4.8 Migrationsreihenfolge

5 Entwurf des Prototypen
5.1 Planung des Prototypen
5.1.1 Namenskonventionen und weitere Regeln
5.1.2 Betriebssystem
5.1.3 Entwurf des Verzeichnisbaums
5.1.4 Verzeichnissynchronisation
5.2 Implementation des Prototypen
5.2.1 Rahmenbedingungen
5.2.2 Konfiguration der Betriebssysteme
5.2.3 Erstellung des Verzeichnisbaums
5.2.4 Übernahme der NT-Domäne
5.2.5 Konfiguration des DirXML-Datenflusses

6 Zusammenfassung

Anhang
A: Protocom ROI-Rechner für Single Sign-On
B: eMail-Statements zum SAP-LADP-Connector
C: eMail-Statement zum Launch des MIIS2003 in Deutschland
D: XML-Dokument NT-to-eDirectory-Treiber des Testsystems
E: DirXML-Remote-Loader-Konfiguration
F: Ausschnitte aus der Novell Preisliste

Glossar

Quellenverzeichnis

Ehrenwörtliche Erklärung

Abstract

Diese Arbeit beschäftigt sich mit der Erstellung eines Konzepts zur Einführung eines Verzeichnisdienstes im Rahmen des Single-Sign-On-Gedankens in dem heterogenen Netzwerk der hagebau und dessen prototypische Umsetzung. Jeder Anwender in der hagebau-Zentrale erhält zu jedem der vielen Systeme jeweils ein Benutzerkonto und ein Kennwort. Diese unterschiedlichen Systeme führen jeweils eine separate Benutzerverwaltung und das führt zu einem Mehraufwand an Verwaltung für Administratoren und Anwender.

Beginnend mit der Auswahl dreier Verzeichnisdienstanbieter aufgrund der Marktposition, wird der Verzeichnisdienst von einem Anbieter konzipiert. Jeder dieser Anbieter verfolgt einen anderen Ansatz, bei denen sich zwei konkurrierende Richtungen herauskristallisieren. Der proprietäre Ansatz mit Microsoft Active Directory als Hauptvertreter, der offene Ansatz mit OpenLDAP und ein Intermediärer mit Novell eDirectory, der beide Richtungen verbindet. Um den geeigneten Anbieter herauszufinden, wird eine Liste mit gewichteten Kriterien aufgestellt. Basierend auf diesem gewichteten Vergleich wird das Novell eDirectory ausgewählt, da es alle für den produktiven Kern der hagebau-Zentrale erforderlichen Basisanwendungen unterstützt.

Auf diesem ausgewählten Verzeichnisdienst werden mehrere Konzepte erstellt. Zum einen ein Phasenkonzept über die Migration, zum anderen ein Konzept über die Aufstellung einer unternehmensweiten Sicherheitsrichtlinie. Weiterhin wird eine Namenskonvention erstellt und die Migrationspläne der Systeme in eine chronologische Ordnung gebracht. Der Prototyp wird mitsamt den zu konnektierenden Systemen geplant. Abschließend wird ein spezieller Teil dieses prototypischen Entwurfs in einem Testsystem realisiert. Für ein Single Sign-On ist zusätzlich eine Clientsoftware auf dem Client nötig, der aufgrund der Infrastruktur sich an dem bereitgestellten Verzeichnisdienst und auch automatisch an den berechtigten Anwendungen anmeldet.

Abbildungsverzeichnis

Abbildung 1: Struktur der hagebau-Gruppe

Abbildung 2: DIB und DIT

Abbildung 3: Directory Information Tree

Abbildung 4: Semantische Position von Meta Directories

Abbildung 5: Synchronisationsmechanismus von Meta Directories

Abbildung 6: Performanz und Präsenz auf dem LDAP-Markt

Abbildung 7: MAD-Datenbank-Architektur

Abbildung 8: MAD-Domänenwald

Abbildung 9: Architektur der OpenSource-Dämonen

Abbildung 10: Struktur des eDirectory

Abbildung 11: eDirectory-Architektur

Abbildung 12: Architektur des Portals

Abbildung 13: Speicherhierarchie

Abbildung 14: Oberste Ebenen der Baumstruktur

Abbildung 15: Mittlere Ebenen der Baumstruktur

Abbildung 16: Untere Ebenen der Baumstruktur

Abbildung 17: Synchonisation der Basisverzeichnisse

Abbildung 18: Synchronisation von NT-Domäne und eDirectory

Abbildung 19: Lotus Notes Subscriber Channel

Abbildung 20: Lotus Notes Publisher Channel

Abbildung 21: SAP HR-System Publisher Channel

Abbildung 22: SAP HR-System Subscriber Channel

Abbildung 23: SAP Basis Publisher-Channel 1. Variante

Abbildung 24: SAP Basis Publisher-Channel 2. Variante

Abbildung 25: SAP Basis Subscriber-Channel

Abbildung 26: NT-Domäne im eDirectory

Abbildung 27: Datenfluss-Entwurf zwischen NT-Domäne und eDirectory

Abbildung 28: Kommunikation zwischen NT-Domäne und eDirectory

Abbildung 29: hagebau-LDAP-Baum

Tabellenverzeichnis

Tabelle 1: X.500-Dokumente

Tabelle 2: LDAPv3-Spezifikation

Tabelle 3: Marktanbieter von Verzeichnisdiensten

Tabelle 4: Anbieter von Meta Directory Services

Tabelle 5: Gewichteverteilung

Tabelle 6: Vergleich von primären Kriterien Teil I

Tabelle 7: Vergleich von primären Kriterien Teil II

Tabelle 8: Vergleich von primären Kriterien Teil III

Tabelle 9: Lizenzkosten der Microsoft-Lösung

Tabelle 10: Lizenzkosten der Novell-Lösung

Tabelle 11: Vergleich der sekundären Kriterien

Tabelle 12: Vergleich der tertiären Kriterien

Tabelle 13: Bewertete Lösungen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Für viele angebotene Dienstleistungen wird mittlerweile ein eigenständiger Ausweis zur Identifikation benötigt. Denken wir an die vielen Rabatt-, Kunden-, Mitglieds-, Kredit-, EC- und Bankkontokarten und -Ausweisen und den jeweiligen dazugehörigen PIN. Die Sammlung solcher Ausweise wuchs in den letzten Jahren für jeden Inhaber und damit stieg auch der Aufwand für deren Verwaltung.

Gleichermaßen verhält es sich in elektronischen und heterogenen Netzwerken. Bei jeder Anwendung, jedem Netzwerkdienst und jedem Verzeichnis muss sich jeweils separat authentifiziert und identifiziert werden. Dies stellt einen Aufwand für jeden Benutzer und Administrator dar. Jeder Benutzer muss sich seine Kennwörter merken und pflegen. Bei jeder Anwendung muss sich der Anwender anmelden. Jeder Systemadministrator hat einen Aufwand an Verwaltung seiner Benutzer. Jede Redundanz in der Pflege verursacht Aufwände in der Infrastruktur und in der Implementation. Diesen Missstand gilt es zu beseitigen.

1.1 Die Firmengruppe

Die dem Netzwerk hagebau angeschlossenen Firmen haben ihre Zentrale in Soltau. Die hagebau-Gemeinschaft ist primär eine Einkaufs- und Marketingkooperation. Insgesamt sind der Kette ungefähr 250 Gesellschafterbetriebe angeschlossen. Diese sind an über 1.100 Standorten mit etwa 310 hagebaumärkten aktiv. Die übrigen Standorte sind Baustoffhandlungen, Holzhandlungen und Grossisten. Dies und der Erfahrungsaustausch zwischen den Gesellschaftern sowie die gegenseitige praktische Hilfe tragen zur Leistungsfähigkeit der einzelnen Gesellschafterbetriebe bei. So wird durch diese mittelständischen Betriebe eine gesunde Vielfalt am Baustoffmarkt erhalten, die letztendlich den Kunden zugute kommt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Struktur der hagebau-Gruppe (eigener Entwurf) hagebau KG

Die Gesellschafterunternehmen sind die Kommanditisten der hagebau GmbH & Co. KG. Die hagebau GmbH & Co. KG wickelt das Warenmanagement ab und entwickelt praxisgerechte Marketing- und Organisations-Konzepte. Weiterhin wird eine breite Palette anderer Leistungen angeboten, die von allen Betrieben genutzt werden können. Dazu gehören Aufgaben wie der zentrale Einkauf, Werbung, Marketing, Vertrieb, Zentralfakturierung, die Entwicklung von Marketing-, Vertriebs- und anderen Konzepten, die Planung neuer Betriebe, Beratung.

Datendienst

Der hagebau Datendienst GmbH & Co. KG ist der IT-Dienstleister dieser Gemeinschaft. Er ist eine vollständige Tochter der hagebau KG. Seine Aufgaben sind unter anderem Betrieb der internen und externen Netzwerke, Dienste und Anwendungen, sowie die Entwicklung, Wartung und Vertrieb der Software hibis (hagebau integriertes Baustoffhandels Informationssystem) an die Gesellschafterfirmen der hagebau KG.

Versicherungsdienst

Der hagebau Versicherungsdienst GmbH & Co. KG arbeitet als Versicherungsmakler der Gemeinschaft und ist auch eine vollständige Tochter der hagebau KG. Seine Aufgaben sind die Sondierung des Versicherungsmarkts und Bündelung von Policen durch Selektion von Versicherungsgesellschaften. Durch vorteilhafte Rahmen-Vereinbarungen mit ausgewählten Versicherungsgesellschaften kann der Versicherungsdienst seinen Kunden günstige Prämien zu optimalen Bedingungen anbieten. Dieser Service steht aber nicht nur hagebau Gesellschaftern und deren Mitarbeitern offen, sondern ist für jeden zugänglich.

ZEUS

Die ZEUS (Zentrale für Einkauf und Service GmbH) ist ein Joint Venture zwischen der hagebau GmbH & Co. KG, E/D/E GmbH (Einkaufsbüro deutscher Eisenwarenhändler) in Wuppertal und EK-Großeinkauf eG in Bielefeld. Über die ZEUS wird der Einkauf von Einzelhandelswaren für die Einzelhandelssparten hagebaumarkt, gartencenter, Werkmarkt, Bauklotz und Floraland realisiert, sowie die Gestaltung von Rahmenvereinbarungen mit den Lieferanten.

Weitere Firmen und Beteiligungen

Die hagebau KG hält Anteile an weiteren Firmen. Eine Schwesterfirma, die Zentrale für den österreichischen Markt, befindet sich in Brunn am Gebirge. Es gibt die Beratungs- und Beteiligungs-KG für die Sicherung strategisch wichtiger Standorte. Weiterhin gibt sind fünf Zentralläger vorhanden: hagebau nord in Neumünster, hagebau weser-ems in Westerkappeln, hagebau west in Herten, hagebau süd-ost in Schleinitz und hagebau süd in Burgau.

1.2 Motivation

In den letzten Jahren haben sich homogene Netzwerke in heterogene Netzwerke verändert. Diese Situation hat dazu geführt, dass in Netzwerken immer mehr Dienste und Anwendungen angeboten werden. Jede Anwendung und jeder Dienst erfordert derzeit eine eigenständige Authentifizierung. Die am meisten verwendete Methode ist eine Kombination aus Benutzername und Kennwort. Dieser Umstand bedeutet, dass der Anwender sich viele Benutzernamen und viele Kennwörter beschaffen und merken muss. Das birgt die Gefahr, dass die Anwender, um den Überblick zu behalten, immer simplere Kombinationen wählen. Außerdem eröffnen sich bei notwendigen, regelmäßigen Kennwortänderungen Gefahren eines Sicherheitsdefizits, dass einige Kennwörter geändert werden und andere gar nicht.

Idealerweise würde wie beim Personalausweis die Identifikation eines Benutzers zusammengefasst werden. Eine Schaffung einer solchen zentralen Identität für alle im Netzwerk befindlichen Dienste wird gemeinhin auch als Single Sign-On (SSO) und die Verwaltung der Identitäten als Single Point of Administration (SPOA) bezeichnet. Ein Verzeichnisdienst gleicht transparent im Hintergrund zwischen den unterschiedlichen Systemen die jeweiligen Benutzerdaten ab. Ein SSO-System enthält Informationen über den Anwender, wie z.B. Privilegien, sowie auch Informationen für berechtigte Dienste.

2 Grundlagen

Der hagebau Datendienst betreibt in der Zentrale ein heterogenes lokales Netzwerk. In diesem Netzwerk werden vielerlei Dienste angeboten: ein File-Sharing-Dienst, ein ERP- und Data-Warehouse-Dienst, ein eMail- und Groupware-Dienst. Das Netzwerk wird durch eine Demilitarisierte Zone (DMZ) gegenüber Zugriff aus dem Internet oder von Wählverbindungen geschützt. Vor und hinter der DMZ befinden sich Firewalls.

2.1 Strukturen

Durch ständigen Wandel hat sich eine heterogene Serverlandschaft ergeben. Sie ist dominiert von Microsoft- und Unix-Betriebssystemen, sowie Anwendungen, die darauf angeboten werden. Jedes System ist eine Insellösung in Bezug auf Identifizierung und hat eine separate Authentifizierungs- und Autorisierungs-Struktur. Nachfolgend werden die wichtigsten Systeme vorgestellt.

2.1.1 Domäne und File-Sharing

Der Domänen-Dienst ist ein Verwaltungsdienst für Namen und Rechte für die an das lokale Netzwerk angeschlossenen Clients. Es werden Privilegien für die File-Sharing-Ordner überwacht.

Dieser Dienst wird durch eine Funktion des Betriebssystems Microsoft Windows NT 4.0 Server realisiert. Er besteht aus den Servern Primary Domaincontroller (PDC) als Hauptinstanz und dem Backup Domaincontroller (BDC) als Sicherungsinstanz. Die Dateien zu diesen Freigaben liegen auf einem Storage Area Network (SAN). Der PDC und der BDC basieren auf Microsoft Windows NT 4.0 Server. Das SAN basiert auf den EMC²-Komponenten Celerra, Connectrix und Symmetrix. Die Anmeldung erfolgt durch Eingabe einer gültigen Kombination aus Benutzername und Kennwort.

2.1.2 eMail- und Groupware

Die Mitglieder der Gruppe eMail- und Groupware sind der Mail-Server, Fax-Server, Helpdesk-Server, Foren-Server und Zeiterfassungs-Server sowie der Workflow-Server. Alle jeweiligen Datenbanken werden in dieser Gruppe verwaltet. Die Gruppe basiert auf dem IBM Lotus Domino/Notes 6.5 System, welches auf Microsoft Windows NT 4.0 Server läuft. Die Anmeldung erfolgt über ein gültiges Paar aus einer Identifikations-Datei und Kennwort.

2.1.3 ERP-System

Die ERP-Server für das System SAP R/3 Version 4.6d dieser Gruppe stellen das klassische Dreiteilungskonzept der SAP AG dar. Es besteht aus Produktiv-, Test- und Entwicklungssystemen. Es werden die Module FI (Financials), RT (Retail), CO (Controlling), MM (Material Management) und HR (Human Ressources) eingesetzt. Die Module FI, RT, CO und MM werden auf zwei Servern in einer gemeinsamen Instanz verwendet. Diese beiden Server erlauben eine Lastverteilung bei sehr hoher Auslastung. Lediglich das HR-Modul wird in einer eigenen Instanz auf einem separaten Server betrieben. Zwischen dem HR-System und der restlichen ERP-Gruppe besteht eine Vertrauensstellung. Diese Gruppe basiert auf dem Betriebssystem HP-UX 11.0 und dem Datenbank-System Oracle 8.1.7. Der primäre Zweck dieses ERP-Systems ist die Zentralfakturierung der Gesellschafter.

2.1.4 Data Warehouse

Das MIS-EH-System (Management Informations-System Einzelhandel) ist ein einzelnes System für ein Data Warehouse, welches auf einem Unix-System mit dem Datenbanksystem Progress läuft. Es ist ein System, das in der Releaseplanung nicht mehr vorgesehen ist. Als Ablösung für dieses System ist ein SAP BW (Business Warehouse) geplant. In diesem System werden z.B. die Verkaufsumsätze vom Point-of-Sales der gesamten Einzelhandelssparte analysiert und typische Artikelprofile erstellt.

2.1.5 Archiv

Es wird ein Archiv, basierend auf der Software EASY-Archiv 3.30, eingesetzt, welches aus mehreren Servern besteht. In diesen Systemen werden die Belege aus der ERP-Systemgruppe direkt archiviert. COLD-Dokumente (Computer Output on Laser Disc) sowie Eingangsrechnungen und Reklamationen per Scanning werden auch archiviert. Das EASY-System fußt auf einer Microsoft-Windows-2000-Server-Umgebung.

2.1.6 Entwicklungsplattformen hibis

Auf diesem System wird die gruppeneigene Warenwirtschaft „hibis“ in den verschiedenen Versionen für den hagebau Baustoffhandel, Baumarkt und das Zentrallager entwickelt. Auf einem separaten Server befindet sich Entwicklungsplattform für die Nachfolge-Warenwirtschaft „prohibis“. Sie verfügen über das Unix-Derivat HP-UX 11.0 und eine Progress-Datenbank in der Version 9.0 mit der dazugehörigen integrierten Entwicklungsumgebung.

2.1.7 Qualitätssicherungssystem hibis

Auf diesem System werden neue Programme und Module der Software hibis getestet und evaluiert, bevor sie an den Gesellschafter oder das Zentrallager ausgeliefert werden. Weiterhin wird es auch für Tests aus dem Second-Level-Support für die Hotline benötigt.

2.1.8 Portalsystem

Das Portalsystem hagebau Extranet (https://extranet.hagebau.de) dient der Kommunikation zwischen der Zentrale in Soltau und den Gesellschafterbetrieben. Zurzeit wird es von einem externen Dienstleister gehostet. Von diesem Portalsystem ausgehend sind Verknüpfungen zu speziellen weiteren Webdiensten gesetzt, die im Haus gehostet werden.

Genau an diesem Portalsystem wird es ein Problem geben, ein Single Sign-On zu implementieren, da es extern gehostet wird und nicht unter voller Verfügungsgewalt steht. Hier wäre eventuell eine politische oder technische Entscheidung zugunsten eines Insourcing notwendig.

2.1.9 Weitere Webservices

Weitere Webservices, die in der hagebau-Zentrale gehostet werden, sind die hagebau-Gefahrstoffdatenbank (http://gwu.hagebau.de), den Abruf der Zahlungsavisen (https://service.hagebau.de), die Archiv-Webrecherche (https://archiv.hagebau.de), der zentrale Artikelstamm (https://zart.hagebau.de), die Warenkorbanalyse (https://webedi.hagebau.de) und die hagebau ftp-Services (ftp://ftp.hagebau.de). Die Server für die aufgeführten Webservices befinden sich in der DMZ des hagebau-Rechenzentrums.

2.2 Zielsetzung

Durch die Einführung eines Verzeichnisdienstes mit dem dazugehörigen SSO-System wird eine Erhöhung von Sicherheit, Stabilität und Produktivität angestrebt. Es müssen vorhandene Systeme integriert und gewachsene Strukturen migriert und umstrukturiert werden. Weiterhin soll das Konzept offen und wiederverwendbar sein, um neue, noch unbekannte, Systeme zu integrieren bzw. auf andere Systeme übertragbar zu machen. Es wird ein Prototyp dargestellt, der eine Migration von einer alten und gewachsenen Struktur mit einem flachen Namensraum auf eine moderne hierarchische Struktur umfasst.

2.3 Organisation der Arbeit

Diese Diplomarbeit konzentriert sich auf den Entwurf eines Verzeichnisdiensts für das interne lokale hagebau-Netzwerk. Es gibt drei Kerngedanken: die detaillierte Vorstellung vorselektierter Verzeichnisdienst-Systeme für heterogene Netzwerke, die Entscheidung für eines der vorgestellten Systeme und dessen prototypische Implementation. Desweiteren werden die Konzepte eines Single Sign-On und eines Verzeichnisdienstes mit dem dazugehörigen Meta Directory dargeboten. In der detaillierten Vorstellung vorselektierter Systeme werden Verzeichnisdienste von drei unterschiedlichen Ansätzen vorgestellt: ein reines proprietäres System, ein quelloffenes System und ein proprietäres System, welches die offenen Standards unterstützt. Ferner wird das Problem analysiert und der Verzeichnisdienst mit den dazugehörigen Richtlinien dazu konzipiert. Ein Migrationskonzept für die hagebau wird entwickelt und dabei unterschiedliche Konzepte abgewogen. Schließlich wird der Prototyp mit einer Namenskonvention entworfen und implementiert.

2.4 Definition Single Sign-On

“A system that enables a user to access multiple computer platforms (usually a set of hosts on the same network) or application systems after being authenticated just one time.

Typically, a user logs in just once, and then is transparently granted access to a variety of permitted resources with no further login being required until after the user logs out. Such a system has the advantages of being user friendly and enabling authentication to be managed consistently across an entire enterprise, and has the disadvantage of requiring all hosts and applications to trust the same authentication mechanism.” [RFC-2828]

Das Konzept Single Sign-On (SSO) wird im Generellen als ein einmaliges, zentrales Anmelden eines Anwenders in einer IT-Struktur verstanden, vgl. [REI02]. Als Synonyme werden auch häufig Single Sign-In und Single Log-On verwendet. Der Anwender muss sich nur einmal identifizieren und wird an allen angeschlossenen Systemen und Diensten authentifiziert. Diese Konstellation ermöglicht eine uniforme Benutzer- und Rechtestruktur in einem Unternehmen.

2.4.1 Vorteile des Single Sign-On

Single Sign-On bietet Vorzüge für Anwender und Unternehmen. Beiden kommt eine Erhöhung der Sicherheit im Sinne von „safety“ und „security“ zu Gute. Für den Anwender speziell bedeutet SSO einen einfacheren Zugriff auf die Ressourcen, sowie eine Deflation von Zugangsdaten, die sich gemerkt werden müssen, vgl. [REI02].

Die Vorteile für das Unternehmen haben eine weitreichende Bedeutung. Durch die Vereinfachung der Anmeldevorgänge wird eine Produktivitätssteigerung erwartet. Die Zentralisierung der Authentifizierungsdaten ermöglicht die Anwendung einer Authentifizierungsrichtlinie für die gesamte Firmenumgebung und ist einfacher abzusichern, als eine verteilte Infrastruktur. Menschliche Fehler, die Hauptursache von Systemfehlern, minimieren sich. Ein weiterer Vorteil sind mögliche Kostenreduktionen im administrativen Bereich. Administrationsaufgaben können zusammengefasst werden. Dadurch können Personalkosten bei gleichzeitiger Erhöhung der Produktivität gespart werden.

Das nachfolgende Zahlenbeispiel verdeutlicht diesen Sachverhalt, in Anlehnung an [MET02]: ein durchschnittliches und beim ersten Versuch erfolgreiches Anmelden dauert ca. fünf Minuten pro Tag. Das durchschnittliche Jahr hat unter Berücksichtigung von Urlaub und Krankheit ungefähr 200 Arbeitstage pro Mitarbeiter (MA). Bei einem Anwender wird ein durchschnittlicher interner Verrechnungssatz von 30 € pro Stunde unterstellt. Dadurch ergeben sich reine Kosten nur für die Anmeldung im Jahr bei einem Unternehmen mit 500 MA von 200 Arbeitstage/Jahr x 5 Min./Tag x 30 €/h x 500 MA = 250.000 €/Jahr, die durch ein SSO gespart werden können.

Ein anderes Beispiel ist das vom Anwender vergessene Kennwort für die Anmeldung an den Systemen. Um die Kosten für diesen Zeitverlust zu überschlagen, werden folgende Annahmen getroffen: der eigentliche Vorgang „Kennwort zurücksetzen“ dauert durchschnittlich drei Minuten pro Anwendung.

Die Administratoren warten aber nicht nur darauf, dass ein Anwender anruft, weil er sein Kennwort vergessen hat. Die Wartezeit bis der Anwender wieder produktiv arbeiten kann, beträgt durchschnittlich eine halbe Stunde. Dem Anwender und dem Administrator werden ein interner Verrechnungssatz von je 30 € unterstellt. Wenn nun vorausgesetzt wird, dass der durchschnittliche Anwender zweimal im Jahr sein Kennwort vergisst, ergibt sich ein Arbeitsausfall des Anwenders bei vier Anwendungen und einem Unternehmen von 500 MA von 2 vergessenen Kennwörtern/Jahr x 30 €/h x 0,5 h Wartezeit x 500 Änderungen = 15.000 €/Jahr. Die Administrationskosten betragen 4 Anwendungen x 500 Änderungen x 2 vergessene Kennwörter/Jahr x 4 Minuten pro Änderung x 30 €/h = 8.000 €/Jahr. Das ergibt einen Aufwand von 23.000 €/Jahr nur für vergessene Kennwörter.

2.4.2 Risiken von Single Sign-On

Das Konzept von SSO birgt selbstverständlich auch Risiken. Falls eine Person es schafft, die Authentifizierungsdaten einer anderen zu erhalten, hätte sie Zugriff auf alle gesicherten Ressourcen dieses Anwenders. Diesen Fall gilt es zu vermeiden.

Ein Lösungsansatz wäre ein Authentifizierungssystem, welches nicht auf Paaren von Benutzername und Kennwort beruht, sondern durch eine nicht-wissensbasierte Identifikation durch z.B. biometrische Merkmale oder Smartcards, vgl. [COX02].

Wenn eine SSO-Komponente ein Sicherheitsleck besitzt oder verursacht, bedingt dies das ganze System. Eine Kette ist nur so stark wie ihr schwächstes Glied. Diese alte Volksweisheit gilt auch für diesen Bereich. Durch SSO können leicht Profile über die Anwender erstellt werden. Wenn eine zentrale SSO-Komponente vorhanden ist, kann es zentrales Ziel von Angriffen sein und ein Engpass bei hoher Last. Ein Ausfall dieser zentralen Komponente belastet die gesamte Infrastruktur und nicht nur ein System.

Aus diesem Grund ist ein Lösungsansatz nur dann optimal, wenn er die einzelnen Systeme beinahe unangetastet lässt und versucht sich über spezielle Konnektoren oder Agenten im Hintergrund zu synchronisieren und die Systeme zu verbinden. Diese geschaffene Redundanz der Systeme ermöglicht eine Ausfallsicherung und erzeugt eine SSO-Umgebung.

2.4.3 Gründe für Single Sign-On

Die Informationstechnologie hat sich in den letzten Jahren von monolithischen zentralen Computern mit angeschlossenen Terminals zu netzwerkartigen Strukturen mit Servern und Clients entwickelt.

So werden dieselben Benutzerdaten in verschiedenen Verzeichnissen und Datenbanken redundant gespeichert und administriert. Diese redundante Pflege ist kosten- und zeitintensiv. Mit einem Single Sign-On und einer Benutzerdaten-Synchronisation können ständig wiederkehrende administrative Aufgaben reduziert werden.

Die Procom Inc. hat einen Return-On-Investment-Kalkulator zur Verfügung gestellt, der auf den von Marktforschungsunternehmen METAgroup, Gartner und IDC ermittelten Daten errechnet, wie hoch der Return-On-Investment wäre, wenn Single Sign-On eingesetzt würde. Im Anhang A befinden sich Bildschirmkopien über eine Return-On-Investment-Kalkulation für die hagebau. Für die hagebau-Zentrale ist ein Einsparpotential von ungefähr 138.791 € (167.521 US-$) ermittelt worden und nach ungefähr acht Monaten amortisiere sich ein Single Sign-On mit Kennwort- und Benutzerdaten-Synchronisation.

2.5 Single Point of Administration

SPOA bedeutet, dass Änderungen an der Autorisations- und Authentifizierungs-Struktur nur an einer einzigen Stelle eingegeben werden und in allen angeschlossenen Verzeichnissen sofort oder nach definierten Intervallen synchronisiert werden. Der Administrator hat eine Schnittstelle zur Administration für alle angeschlossenen Systeme und Dienste. Diese Konstellation ermöglicht eine einheitliche Benutzer- und Rechtestruktur in einem Unternehmen.

2.6 Verzeichnisdienste

Der treffendste Vergleich von Verzeichnisdiensten kann mit den Gelben Seiten gezogen werden. Ein Verzeichnisdienst ist eine im Netzwerk verteilte Datenbank die auf dem Client-Server-Prinzip basiert, vgl. [REI02]. In dieser Datenbank können beliebige Informationen gespeichert werden. Die Einträge in der Datenbank können verglichen, gesucht, erstellt, modifiziert und gelöscht werden. Meistens wird lesend auf die Daten eines Verzeichnisdienstes zugegriffen. Veränderungen an den Einträgen dieser Datenbank sind sehr selten. Aus diesem Grund bieten Verzeichnisdienste lesend eine wesentlich schnellere Zugriffszeit als andere Datenbanken. Einem Namen oder Objekt werden Attribute mit Werten zugewiesen. Verzeichnisdienste sind Informationsquelle für Objekte, Anwendungen und Anwender um gerade die zu lokalisieren. Verzeichnisdienste stellen daher Informationen bereit, die durch Maschinen und Menschen lesbar sind.

2.6.1 Abgrenzung zu relationalen Datenbanken

Ein Verzeichnisdienst ist eine Datenbank mit speziellen Funktionen. Relationale Datenbanken sind nicht für die Aufgaben eines Verzeichnisdienstes konzipiert worden.

Ein besonderer Vorteil der Verzeichnisdienste liegt auf:

- Daten, die längere Zeit unverändert bleiben
- Optimierungen für schnelle Abfragen
- Optimierungen für viele Lesezugriffe
- Duplikate bzw. doppelte oder fehlende Attribute sind möglich
- Einfaches Abfrageprotokoll

Verzeichnisdienste sind nicht für folgende Aufgaben konzipiert:

- Unstrukturierte Informationen verarbeiten
- Informationen in Echtzeit verarbeiten
- Viele Schreiboperationen
- Transaktionen
- Dokumentenbasierte Datenhaltung

2.6.2 X.500-Empfehlungen

Erstmals ist 1988 von der International Telecommunication Union (ITU-T) eine Spezifikation unter der Bezeichnung X.500 ein Verzeichnisdienst vorgestellt und standardisiert worden. Eine Überarbeitung von X.500 ist 1993, 1997 und 2001 noch einmal erfolgt. Weiterhin ist X.500 ein Bestandteil der Open Software Foundation, Distributed Computing Environment (OSF/DCE) und wird dadurch von der Industrie aufgegriffen und unterstützt. X.500 ist nur eine Empfehlung. Eine Implementation des Standards gibt es derzeit nicht, aber es existiert lediglich eine Empfehlung für die Implementation, vgl. [X.Imp500]. In der nachfolgenden Tabelle sind die Dokumente der X.500-Empfehlung aufgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: X.500-Dokumente (Quellen: [X-Series], [ISO9594])

X.500 basiert auf der Anwendungsschicht des ISO-/OSI-Referenzmodells und ist leseoptimiert, vgl. [HOF97]. Für das X.500 Directory Access Protokoll (DAP) ist der vollständige ISO-/OSI-Protokollstapel notwendig. Der Namensbaum wird Directory Information Tree (DIT) genannt. Die gesamte Datenstruktur wird als Directory Information Base (DIB) bezeichnet.

Jeder Name und jedes Attribut wird einer Objektklasse bzw. einem Typ zugeordnet, vgl. [TAN01]. Es können neben den vordefinierten Objektklassen auch eigene Objektklassen im Sinne der objektorientierten Vererbungshierarchie in der Abstract Syntax Notation One (ASN.1) definiert werden. Jeder Eintrag in der DIB besteht aus einem Namen und einer Menge von Attributen. Absolute Namen beschreiben den Weg von der namenlosen Wurzel (root) zum Objekt. Weiterhin sind relative Namen unter Berücksichtigung des Objektkontexts möglich.

Per Definition gibt es weltweit nur einen DIT mit einer DIB verteilt auf mehrere Server. Der DIT beginnt mit dem Wurzelobjekt. Die nachfolgende Abbildung zeigt den Zusammenhang zwischen DIB und DIT. Die zweite Ebene sind die Länder und die dritte Hierarchiestufe sind die Organisationen wie z.B. Firmen, Behörden etc.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: DIB und DIT (eigener Entwurf)

Die verteilten Server heißen Directory Service Agent (DSA). Die zu den DSA gehörigen Clients heißen Directory User Agents (DUA). X.500 greift über das X.500 DAP zu.

2.6.3 Lightweight Directory Access Protocol

Das Lightweight Directory Access Protocol (LDAP) ist 1995 an der University of Michigan entwickelt worden und ist eine Teilmenge der X.500-Spezifikation. Das Projekt LDAP ist 1998 von der University of Michigan der OpenLDAP Foundation zur Weiterentwicklung übergeben worden. LDAP Version 3 (LDAPv3) wird den RFC 2251 - 2256, 2307 und 2829 - 2830 der Internet Engineering Task Force (IETF) beschrieben. Die nachfolgende Tabelle zeigt einen Überblick über die LDAPv3-Spezifikation.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: LDAPv3-Spezifikation (Quelle: [RFCLDAP])

LDAP nutzt nicht wie X.500 den vollständigen ISO-/OSI-Protokollstapel, sondern setzt auf dem TCP/IP-Protokoll auf. In LDAP sind weniger Operationen als in X.500 enthalten. Weiterhin wird eine vereinfachte Syntax in Zeichenkettenform (string) verwendet. LDAP ist wie X.500 optimiert für Lesezugriffe, vgl. [RFC-2251].

Struktur von LDAP-Verzeichnissen

LDAP-Verzeichnisse haben wie X.500 auch eine baumartige Struktur. An der Spitze steht das so genannte Wurzelelement (directory root). Es ist ein leerer Knoten. Jeder Eintrag besteht aus Attributen und einem Attributtyp. Jedem Attribut sind ein oder mehrere Werte zugeordnet. Zur Charakterisierung erhält jeder Eintrag ein Objektklassen-Attribut, über das auch optionale übrige Attribute definiert werden können, vgl. [RFC-2251]. Die folgende Abbildung zeigt einen solchen Baum.

Abbildung 3: Directory Information Tree (eigener Entwurf)

Abbildung in dieser Leseprobe nicht enthalten

Die Vererbung wird über das Objektklassen-Attribut geregelt, vgl. [GIE03]. Die Wissensebene nach [FOW00] der Objekte der Attribute wird über Regeln und erlaubte Typkombinationen bzw. Vergleichsregeln (matching rules) dargestellt. Diese Wissensebene wird in einer fest definierten Syntax notiert.
Diese Werte bilden ein Schema, welches den gesamten Baum
definiert, vgl. [HAB04], [RFC-3703].

Die wichtigsten vordefinierten Objektklassen des LDAPv3-Standards sind:

- country = das Attribut c oder countryName
- organization = das Attribut o oder organizationName
- organizational unit = das Attribut ou oder organizationalUnit
- person = das Attribut cn oder common name

Diese vordefinierten und standardisierten Schemata bilden eine Basis auf der sich alle LDAP-Systeme verständigen können. Bei selbst-definierten Schemata müssen die zugreifenden Anwendungen angepasst werden.

Datenaustausch

LDAP-Server tauschen ihre Daten mit dem LDAP Data Interchange Format (LDIF), vgl. [RFC-2849], oder DSML (Directory Services Markup Language), vgl. [DSML99], aus. Bei dem LDIF handelt es sich um ein ASCII-Format, mit dem der gesamte Baum oder auch Teile davon dargestellt werden können. Via LDIF wird auch der Austausch der Daten mit anderen Anwendungen realisiert. DSML ist eine Auszeichnungssprache, die von XML abgeleitet worden ist. Sie ist 2001 von der OASIS (Organization for the Advancement of Structured Information Standards) standardisiert worden. DSML liegt in der Version 2 vor. Mit dem LDUP (LDAP Duplication Replication Update Protocol) des LDAPv3 können Informationen zwischen den LDAP-Servern repliziert, dupliziert oder aktualisiert werden. LDUP hat zurzeit den Status „Informational“ [RFC-3384] der IETF. LDAP ist ein offener Standard und nimmt immer weiter an Bedeutung und Verwendung zu. Alle größeren Softwareanwendungen aus dem Bereich Verzeichnisdienste unterstützen bereits LDAP zumindest rudimentär.

Marktübersicht

Der Markt der LDAP-konformen Verzeichnisdienstanbieter ist recht überschaubar, wie die nachfolgende Tabelle zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Marktanbieter von Verzeichnisdiensten

(Quellen: [MET04], [DER03], [GAR03])

2.6.4 Meta Directories

In jedem größeren Unternehmen gibt es Verzeichnisse und Datenbanken der unterschiedlichsten Art. Es gibt eMail-Verzeichnisse und -Verteiler, Telefonverzeichnisse, ERP-Anwendungen und Data Warehouses. Gemeinsam an allen ist die redundante Speicherung von Anwenderinformationen. Jede einzelne Anwendung erfordert eine eigene Administration. Durch die manuelle Synchronisation der einzelnen Verzeichnisse können Inkonsistenzen und Zeitverzögerungen entstehen, insbesondere dann, wenn sehr lebendige Strukturen verwaltet werden müssen. Diese signifikanten Unterschiede in der Datenhaltung erlauben keine Entwicklung von Applikationen, die auf der gesamten Datenbasis operieren.

Für die Lösung solcher und ähnlicher Probleme sind Meta Directories, also globale Verzeichnisse, entwickelt worden, die ein einheitliches durch standardisierte (bspw. LDAP, DSML) oder proprietäre (z.B. ADSI) Schnittstellen gemeinsames Verzeichnis repräsentieren. Das Problem beim Einsatz eines Meta Directorys ist darum der Austausch der Informationen. Das Protokoll ist definiert, jedoch das Format nicht. Dieser Sachverhalt wirft einen Konflikt der konkurrierenden Ziele Sicherheit und offene Standards auf. Ein Lösungsansatz wäre ein Datenaustausch durch einen offenen Standard wie XML über eine gesicherte, getunnelte und verschlüsselte Verbindung über SSL.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Semantische Position von Meta Directories (eigener Entwurf)

Über spezielle Konnektoren oder Agenten werden die vorhandenen Verzeichnisse und deren Objekte in ein DAP-Server-Verzeichnis repliziert und von dort aus über bspw. eine LDAP-Schnittstelle zur Verfügung gestellt. Die meisten Hersteller verwenden zur Speicherung der DIB ein eigenes Format, insofern ist selten eine Integration möglich. Meta Directories übernehmen in Umgebungen mit vielen Verzeichnissen und Datenbanken den zentralen lesenden und schreibenden Zugriff auf das Gesamtverzeichnis und sie bilden einen transparenten Zugriff auf die Basisverzeichnisse ab. Für den Zugriff auf eine Applikation bedeutet das, dass nur an einer Stelle zugegriffen werden muss und nicht an mehreren. Hiermit wird der administrative Aufwand für die Datenpflege minimiert.

Beispielsweise müssen bei Eintritt eines neuen Mitarbeiters in das Unternehmen alle Rechte, Privilegien und Ressourcen vergeben werden. Bei einem Meta Directory ergibt sich der Vorteil, dass die Vergabe nur einmal erfolgen muss. Durch die Struktur des Meta Directory als übergeordnete Instanz synchronisieren sich alle untergeordneten Verzeichnisse und Datenbanken. Andere Beispiele sind die Versetzung eines Mitarbeiters oder der Austritt eines Mitarbeiters aus dem Unternehmen. In beiden Fällen ändert sich der Status des Mitarbeiters. So können dem austretenden oder wechselnden Mitarbeiter wie die Privilegien und Rechte automatisch entzogen werden.

Ein Meta Directory als übergeordnete Instanz synchronisiert die anhängigen Verzeichnisse, wie z.B. eMail-Verzeichnisse oder Telefonlisten. Ein passendes Beispiel hierfür ist der Vergleich der Zeitspannen des Anlegens neuer Anmeldekonten eines neuen Mitarbeiters bzw. die manuelle Synchronisation ohne Meta Directory und derselbe Vorgang mit Meta-Directory-Unterstützung. So vergehen ohne Meta-Directory-Unterstützung ca. 1 bis 14 Tage bis der neue Mitarbeiter alle für ihn wichtigen Anmeldedaten hat und voll produktiv arbeiten kann, vgl. [MET02]. Die Gründe dafür sind Medienbrüche und eine manuelle Verbreitung über z.B. interne Postsysteme und fehlende Unterschriften. Mit einem Meta Directory lässt sich diese Zeitspanne auf maximal zwei Stunden verkürzen.

Implementierung

Viele Meta Directories basieren auf dem X.500-Standard, dessen Implementierungsweise nicht standardisiert ist. Es gibt nur Implementierungs-Empfehlungen. Aus diesem Grund gibt es keine exakte Definition für ein Meta Directory. Das ist auch der Grund für abweichende Implementierungen seitens der Hersteller.

Die heutigen Meta Directories verwenden einen DSA zur Replikation der untergeordneten Verzeichnisse. Der DIB und der DIT sind Implementationen eines LDAP- oder X.500-Servers des jeweiligen Herstellers. Sie können also auf die X.500-Spezifikation zurückgeführt werden. Die Koordination des Datenflusses zwischen den einzelnen Verzeichnissen wird über Regeln als Wissensebene (knowledge level) definiert. Die Objekte selbst entsprechen der operativen Ebene, vgl. [FOW00].

Synchronisationsmechanismus von Meta Directories

Meta Directories nutzen zwei Kanäle zur Synchronisation zwischen ihrer eigenen DIB und dem Quellverzeichnis. Das Funktionsmuster ist dem Abonnementenverfahren (subscribe & publish) ähnlich, wie die folgende Abbildung zeigt. Der erste Kanal ist der Abonnementen-Kanal (subscriber channel), über den sich der Empfänger bei dem Quellverzeichnis einschreibt und auf Änderungen wartet. Der Herausgeber-Kanal (publisher channel) synchronisiert die Daten der Meta-DIB mit den Quelldaten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Synchronisationsmechanismus von Meta Directories (eigener Entwurf, angelehnt an [DAU02])

Weiterhin ist ein Konnektor zum Quellsystem notwendig, damit der Meta-Directory-Dienst Daten bei dem Quellsystem abonnieren und synchronisieren kann. Über Regeln wird die so genannte Wissensebene abgebildet. In dieser Wissensebene werden Informationen gespeichert, die für die einzelnen Synchronisationsläufe zur Validierung wichtig sind.

Die wichtigsten Regeltypen sind:

- Zuordnung von Attributtypen vom Quellverzeichnis

und Attributtypen vom Zielverzeichnis

- Gültigkeitsbereiche der Attributwerte
- Schaffung von qualitativen Aussagen basierend

auf quantitativen Werten

Stärken und Schwächen von Meta Directories

Meta Directories können beliebig viele Verzeichnisse uniform repräsentieren. Weiterhin ermöglichen Meta Directories einen einheitlichen Zugriff auf die Daten und bieten eine breite Palette von Schnittstellen an. Die Stärken kommen besonders zur Geltung, wenn Konnektoren zu X.500- oder LDAP-Diensten vorhanden sind. Eine Schwäche von Meta Directories insbesondere X.500 oder LDAP sind schreiblastige Anfragen. Hierfür sind Verzeichnisse nicht ausgelegt.

Marktüberblick

Der Markt der Meta-Directory-Anbieter ist relativ klein und überschaubar, wie die nachfolgende Tabelle zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Anbieter von Meta Directory Services

(Quellen: [MET04], [DER03], [GAR03])

3 Auswahl eines Verzeichnisdienstes

Wie eingangs beschrieben, betreibt die hagebau-Zentrale ein heterogenes Netzwerk, bestehend aus Windows- und Unix-basierenden Systemen, Diensten und Verzeichnissen. Ein Hauptproblem ist die Integration der Dienste und Verzeichnisse. Diese unterschiedlichen Softwaresysteme und Verwaltungs-bereiche führen zu einer Verteilung der Daten und Verzeichnisse in elektronischer und gedruckter Form. So werden z.B. Adresslisten für Serienbriefe manuell generiert und weiterverarbeitet. Solche manuellen Kopien dieser Listen sind meistens schon zum Generierungszeitpunkt veraltet. Die meisten Mitarbeiter erzeugen zusätzlich private Kopien auf Basis von veralteten Verzeichnissen und Listen. Außerdem werden auf diesen Daten Operationen ausgeführt, die nicht korrekt sind. Diese Probleme resultieren aus einer gewachsenen Struktur, in der die einzelnen Insellösungen möglichst schnell implementiert worden sind. Die Interoperabilität zwischen den Systemen ist bisher nicht berücksichtigt worden und bei den verwaltenden Instanzen sind Bereichsegoismen vorhanden.

3.1 Analyse der Situation

Heterogene Netze, die aus Insellösungen bestehen, haben vielfältige Probleme in der Verwaltbarkeit. Diese Vielfalt an Systemen im hagebau-Netzwerk, die durch verschiedene Gruppen administriert werden, erschweren ein gemeinsames Konzept für Privilegien, Authentifizierung und Autorisierung. Jede Gruppe hat ihre eigenen Bereichsegoismen und möchte weiterhin vollständig über ihre Systeme verfügen. Diese Kleinstaaterei stellt sich so dar, dass die einzelnen Abteilungen, die die Server und Dienste administrieren, diese Macht ausnutzen, um sich von den anderen Gruppen abzugrenzen.

Jedes System beinhaltet einen eigenen Dienst zur Rechtevergabe und Authentifizierung. So kann es vorkommen, dass Informationen bereits zum Eingabezeitpunkt veraltet sind. Diese Zeitverzögerung kann ein Sicherheitsrisiko darstellen. Die Berechtigungen in allen Systemen bis auf SAP R/3 werden an Personen oder Gruppen, denen Personen angehören verankert. Dies bedeutet, dass bei Ausfall eines Mitarbeiters sein Kennwort bekannt sein muss, um z.B. auf die benötigten Daten zuzugreifen. Dadurch hat sich ein sehr weit vermaschtes Berechtigungs-Netzwerk ergeben. Eine Struktur lässt sich nicht mehr nachvollziehen. Diese fehlenden Rollen lassen diesen
Wildwuchs weiter gedeihen. Das HR-System verwaltet die Mitarbeiter und Benutzer separat.

Bei der Verwaltung der Berechtigung der Dateifreigaben des Windows NT Servers ist nicht zu erkennen, welche effektiven Rechte der Anwender speziell hat. Bei den R/3-Systemen werden Rollen definiert, um die Privilegien zu verwalten. Jeder Geschäftsprozess und jedes Recht wird in jeweils eine Rolle integriert. Das Benutzerprofil ergibt sich aus der Kombination der Rollen.

3.2 Probleme

Die Administration eines solchen Netzwerks wirft vielfältige Probleme auf. Der Internet-Zugang der einzelnen Mitarbeiter wird zum einen über den Proxy-Eintrag im Browser und zum anderen in einer Sperrliste von IP-Adressen gesteuert. Bei der Suche einer internen Telefonnummer werden zwei Listen konsultiert, von denen ein oder beide Einträge richtig oder falsch sind. Die Nummer der Telefon- und Netzwerkdose wird gar nicht verwaltet. Für jeden Netzwerkdienst und für jede Anwendung existiert eine eigene Oberfläche für die Administration und Anmeldung. Im Speziellen existieren Probleme durch Mehrfachpflege der Daten.

Die häufigsten Problemfälle werden im Folgenden aufgezeigt:

- Wenn ein neuer Mitarbeiter in das Unternehmen eintritt, gibt es durch die Administration verschiedenster Listen und Verzeichnisse Zeitverzögerungen. Diese Zeitverzögerungen lassen den Mitarbeiter nicht voll produktiv arbeiten.
- Ein weiterer Fall sind Namensänderungen von Personen und Organisationseinheiten oder Wechsel von Mitarbeitern von einer Organisationseinheit in eine andere.
- Probleme in den Verzeichnissen und Listen treten auch bei Fusionen, Übernahmen und Abspaltungen von Unternehmen auf.
- Bei Austritt eines Mitarbeiters aus dem Unternehmen müssen die Zugriffe auf alle Verzeichnisse und Dienste gesperrt werden, um kein Sicherheitsrisiko einzugehen.
- Redundante Zuordnung von Ressourcen
- Mangelhafte oder fehlende Zuordnung von Ressourcen

3.3 Globaler Lösungsansatz

Um den beschrieben Problemfällen zu begegnen, ist ein System notwendig, welches transparent im Hintergrund administrative Aufgaben den Administratoren abnimmt. Diese administrativen Aufgaben sind z.B. Benutzer hinzufügen, Benutzer ändern, Benutzer löschen, Rechte anpassen und Kennwörter zurücksetzen. Werden diese administrativen Aufgaben zentralisiert, ergeben sich weniger Redundanzen in den Aufgaben der einzelnen Administratoren.

Dieser Verbund der einzelnen Systeme gleicht im Hintergrund die Kennwörter und Rechte zwischen den einzelnen Anwendungen ab und kann bei Bedarf dem Anwender ein Single Sign-On ermöglichen. Idealerweise würde bei Anlage eines neuen Mitarbeiters in dem System für das Personalwesen automatisch ein neue Benutzerkonto in den über das Meta Directory verbundenen Systemen erstellt werden. Ein analoges Verhalten bei Kündigungen und Versetzungen ist zu empfehlen. Ein Single Sign-On wird somit zu einem ergonomischen Aufsatz für den Anwender in diesem beschriebenen Systemverbund.

3.4 Kriterienkatalog

Für die Evaluation eines auf die hagebau passenden Verzeichnisdienstes und Meta Directorys ist ein gewichteter Kriterienkatalog aufgestellt worden, welcher nachfolgend näher definiert wird. Es gibt drei Klassen von Kriterien:

Primäre Kriterien

Diese Gruppe stellt die Güte und Funktionalität des Systems dar. Hier sind Plattformunabhängigkeit, Interoperabilität und Skalierbarkeit enthalten. Die Plattformunabhängigkeit spiegelt die Flexibilität des einzusetzenden Systems wider. Mit Interoperabilität ist der Austausch von Daten mit Basissystemen gemeint. Sie ist eng mit der Integrationsfähigkeit verwandt. Die Skalierbarkeit ist ein weiterer relevanter Faktor. Es ist bei der Systemauswahl auch auf Erweiterungsfähigkeit zu achten. Wichtige Kriterien sind auch Operationen auf den Verzeichnisbäumen oder der Preis und die Nutzung von offenen Standards und Open-Source-Strategien.

Sekundäre Kriterien

Die sekundären Faktoren spiegeln Administrierbarkeit, Stabilität und Management wider. Administrierbarkeit bedeutet den Umfang der Administration mit den dazugehörigen Benutzeroberflächen. Management ist die Schwierigkeit der Administration. Weitere Faktoren sind zusätzliche Features, wie z.B. vorkonfektionierte Treiber, hierarchische Speichersysteme.

Tertiäre Kriterien

Diese weichen Faktoren spiegeln die eingesetzte Technologie, die strategische Entwicklung des Produktes und des Herstellers und die Unterstützung durch den Hersteller wider. Weitere Kriterien sind Hardwareanforderungen.

Gewichtsverteilung

Um der Bedeutung der Kriteriengruppen gerecht zu werden, wird eine Gewichtung fixiert. Es wird grob eine Gewichtung von 1/2 für die primären Kriterien, 1/3 für die sekundären Kriterien und 1/6 für die tertiären Kriterien zugrunde gelegt. Anhand der nachfolgenden Tabelle können die Gewichte für die einzelnen Kriterien abgelesen werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Gewichteverteilung (eigener Entwurf)

3.5 Marktposition der Verzeichnisdienstanbieter

Der Verzeichnisdienstemarkt ist von den Marktforschern METAgroup in drei Bereiche aufgeteilt worden, vgl. [MET04]: Marktführer, Herausforderer und Verfolger. Verteilt sind die Anbieter nach der klassischen Normalverteilung: wenige oder gar keine Marktführer und Verfolger und viele Herausforderer.

Nachfolgend werden die Gruppen vorgestellt:

Die Gruppe der Marktführer ist eine Gruppe, die Implementierungen von Produktivumgebungen in Hinblick auf die Dimensionen Menge, Breite, Tiefe und Volumen vorweisen kann. Marktführer haben Kunden in den wichtigsten Marktsegmenten. Bei diesen Kunden sind komplexe, verteilte Verzeichnisdienste implementiert worden, die herstellerübergreifende Systeme integriert haben.

Die Gruppe der Herausforderer hat signifikant weniger Installationen hinsichtlich der bei der Marktführer-Gruppe vorgestellten vier Dimensionen. Die Skalierbarkeit ist von untergeordneter Priorität im Vergleich mit der Marktführer-Gruppe. Bei gemäßigten Anforderungen hinsichtlich der Performance sollte dies durchaus nicht vernachlässigbar sein. Dennoch sind diese Dienste sehr
robust. Selbst die Gruppe der Verfolger liefert in begrenzten
Umgebungen ein performantes Ergebnis. Es besteht hier ein größerer Nutzen als Mangel an Leistungsfähigkeit.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Performanz und Präsenz auf dem LDAP-Markt (Quelle: [MET04])

Anhand obiger Abbildung ist erkennbar, wie leistungsfähig und präsent die jeweiligen Anbieter sind. Für die Vor-Selektion kommen nur typische Repräsentanten ihres Ansatzes in Frage, wie z.B. OpenLDAP als reiner Open-Source-Anbieter, Microsoft als überwiegend proprietärer Anbieter und Novell als proprietärer Anbieter, der Open-Source-Strategien nutzt und unterstützt.

Die Gartner-Group ist im Herbst 2003 zu einer ähnlichen Einschätzung wie die METAgroup gekommen, vgl. [GAR03]. Eine signifikante Änderung ist lediglich, dass das Microsoft Active Directory zusätzlich in die Gruppe der Marktführer mit eingeordnet worden ist. Ein Grund für die bessere Einschätzung
gegenüber der METAgroup könne die kurz vor Veröffentlichung der Studie gekommene Markteinführung des Produkts MIIS 2003 auf dem US-amerikanischen Markt sein.

3.6 Beschreibung der Produkte

In diesem Teil werden exemplarisch ein proprietäres Closed-Source-System, ein reines Open-Source-System und ein Closed-Source-System mit Open-Source-Unterstützung vorgestellt. In dieser Auswahl wird der stärkste, mittlere und schwächste Anbieter auf dem Verzeichnisdienste-Markt aufgenommen, um auch dieser Position gerecht zu werden.

3.6.1 Proprietäres Closed-Source System

Ein proprietäres Closed-Source System und Lösungsansatz ist das Microsoft Active Directory (MAD) in Verbindung mit dem Microsoft Identity Integration Server 2003 (MIIS, ehemals Microsoft Metadirectory Services (MMS)). Das MAD fungiert als Verzeichnisdienst und das MIIS als Meta-Verzeichnisdienst. Beide Dienste basieren auf dem Betriebssystem Microsoft Windows Server 2003 Enterprise Edition. Die nachfolgende Abbildung zeigt die Architektur dieses Verzeichnisdienstes.

[...]