Verfahren zur einheitlichen Benutzerverwaltung. Sven Maurmann

Transkript

1 Sven Maurmann

2 Rev. B WP kippdata informationstechnologie gmbh Bornheimer Straße 33a D Bonn Tel.: info@kippdata.de , Rev. B Seite 2 / 15

3 Inhaltsverzeichnis 1 EINLEITUNG ZIEL DES DOKUMENTES ALLGEMEINER ÜBERBLICK BEGRIFFSKLÄRUNGEN PROBLEMSTELLUNG EINFÜHRUNG ANFORDERUNGEN PROBLEMATIK VON LÖSUNGSANSÄTZEN KONSEQUENZEN ORGANISATORISCHE THEMEN DATENERFASSUNG UND DATENPFLEGE INTEGRATION VON FREMDDATEN INTEGRATION VON ARBEITSABLÄUFEN ACCOUNTING / AUDITING TECHNISCHE FRAGEN ALLGEMEINE FRAGESTELLUNGEN EINFACHE SYSTEME Directory-Strukturen Plattformunterstützung Eingriffe in die Endsysteme Anwendungsintegration HOMOGENE UMGEBUNGEN HETEROGENE UMGEBUNGEN Windows-Systeme GINA Vorhandene Domains ADS MIGRATION DER VORHANDENEN DATEN FREMDSYSTEME UND FREMDDATEN Integration von Anwendungen PAM ERWEITERTE NUTZUNGSMÖGLICHKEITEN AUSBLICK WEITERGEHENDE LÖSUNGSANSÄTZE , Rev. B Seite 3 / 15

4 1 Einleitung 1.1 Ziel des Dokumentes Das vorliegende Dokument beschreibt die Anforderungen, die sich im Rahmen eines Projektes zur Einführung einer vereinheitlichten Benutzerverwaltung ergeben. Hierbei wird neben den typischen technischen Aspekten, die sich in einer heterogenen Umgebung ergeben, insbesondere auch auf die organisatorischen Anforderungen in diesem Umfeld eingegangen. Das Dokument soll den Personen, die ein Projekt zur Einführung einer vereinheitlichten Benutzerverwaltung planen, Hinweise an die Hand geben und eine Richtschnur bei der Vorbereitung sein. Es wird keine detaillierten technischen Betrachtungen enthalten, die sich erst im Rahmen der konkreten Durchführung sinnvoll anstellen lassen. Obwohl im Titel sowohl der Begriff Benutzer-Management als auch Identity-Management enthalten ist, beschränkt sich das Dokument in seinem Hauptteil auf erstere Fragestellung. Auf Identity-Management wird nur in dem Maße eingegangen, das zu Abgrenzung oder zur Klärung von Problemen erforderlich ist. 1.2 Allgemeiner Überblick Seit in den IT-Organisationen Rechner nicht mehr als isoliert zu verwaltende Systeme organisiert sind, sondern in Netzwerken unter gemeinsamer Nutzung verschiedener zentraler Ressourcen miteinander verbunden sind, stellt sich die Frage der zentralen Verwaltung der entsprechenden Zugangsinformationen. Im Bereich der UNIX-Systeme hat sich seit langem das Network Information System (NIS) etabliert, das Sun Microsystems eingeführt hat. Zunehmend wird aber zum einen die Integration von Systemen wichtig, die nicht über eine NIS-Implementierung verfügen. Außerdem ist selbst in kleinen und gut abgeschirmten Netzen der Sicherheitsaspekt von immer größerer Bedeutung. Da NIS hier nur in bescheidenem Umfang hilfreich ist, muß man sich auf die Suche nach Alternativen machen. In modernen Arbeitsumgebungen wird eine Vielzahl von Anwendungen unterschiedlicher Herkunft zur Durchführung von Arbeitsaufgaben verwendet. Diese Anwendungen und die sie tragenden Plattformen verfügen über unterschiedliche Verfahren zur Zugangskontrolle und Vergabe von Berechtigungen. Zunehmend wird die Forderung gestellt, daß diese Berechtigungen zusammengefaßt und wenn möglich durch eine einheitliche Zugangskontrolle organisiert werden. Auch hierfür sind im UNIX-Umfeld in der Vergangenheit Lösungen entstanden, die sich durchaus auch auf Systeme wie NIS abstützen können. Der heute gebräuchliche allgemeine Zugang zu den bislang skizzierten Fragestellungen beruht auf der Verwendung von Directory-Services, die sowohl unterschiedliche Systeme als auch Anwendungen bedienen können. Seit einigen Jahren erfreut sich LDAP als Protokoll für derartige Dienste immer größerer Beliebtheit, was zunächst erstaunlich ist, denn es handelt sich durchaus um eine ältere Lösung für das Problem des Dircetory-Services. Es handelt sich hierbei keineswegs um die einzige Lösung, die am Markt verfügbar ist; es ist aber ohne Zweifel die flexibelste wegen der inzwischen weiten Verbreitung und der Akzeptanz als Standard. In diesem Dokument werden daher sämtliche technischen Verfahren und Lösungen auf der Basis von LDAP dargestellt. Die technische Sichtweise auf die Benutzerverwaltung ist die aus der UNIX-Welt. Es werden Integrationsmöglichkeiten von Windows-Systemen ausgiebig behandelt; jedoch ist die Integration eine in Richtung LDAP-Directory und nicht in Richtung ADS. Dieser Ansatz ist für die meisten Systemlandschaften sinnvoll, da die Bereitstellung der entsprechenden Services auf UNIX-Systemen besser zu UNIX-basierten Serverumgebungen paßt. 1.3 Begriffsklärungen Im Titel des vorliegenden Dokumentes werden bereits die beiden kritischen Begriffe in diesem Umfeld gemeinsam verwendet: Benutzer-Management und Identity-Management. Unter Benutzer-Management versteht man allgemein die Verfahren zur organisationsweiten Bereitstellung von organisatorischen und technischen Benutzerinformationen. Häufig beschränken sich diese Verfahren auf die Bereitstellung von Zugangsinformationen für Benutzer, also beispielsweise die klassischen Login , Rev. B Seite 4 / 15

5 Informationen. Grundsätzlich sollte man aber auch die Zuordnung organisatorischer Informationen wie zum Beispiel Telefonnummern darunter fassen. Das klassische GCOS-Feld in der UNIX-Passwortdatei kann unter anderem diesen Zweck erfüllen. Unter Identity-Management versteht man hingegen Verfahren, die versuchen, Identitäten innerhalb einer Organisation so zu identifizieren, daß sie einander zugeordnet werden können. Das bedeutet unter anderem die Möglichkeit, unterschiedliche Sätze von Informationen, die an unterschiedlichen Stellen in einer Organisation vorgehalten werden, zueinander in Beziehung zu setzen. In der Regel bezieht man sich hierbei auf Informationen über Menschen in der betreffenden Organisation, also beispielsweise auf die Verbindung unterschiedlicher Zugangsinformationen für verschiedene Systeme. Im Umfeld dieser Begriffe tauchen weiterhin die Begriffe Directory, Meta-Directory und Provisioning auf. Während man unter Directory noch allgemein eine Anwendung versteht, die Informationen anhand eindeutiger Schlüssel bereitstellen kann, wird die Definitionslage bei den beiden anderen Begriffen ein wenig unschärfer, da es sich hier nicht zuletzt auch um Marketingbegriffe handelt. Keinen Fehler macht man, wenn man ein Meta-Directory als eine vereinheitlichte Sicht auf Informationen definiert, die aus verschiedenen Quellen (typischerweise Directories) stammen. Technische Implementierungen sehen darüberhinaus vor, daß die Zusammenfassung der Informationen mit einer Bewertung einher geht. Dies wird weiter unten eingehender erläutert. Provisioning grenzt sich gegen Meta-Directory so ab, daß hier auch Workflow enthalten ist. Etwas konkreter bedeutet das, daß Provisioning ebenfalls eine vereinheitlichte Sicht auf Informationen liefern will, dies aber mit der Möglichkeit verbindet, daß Änderungen in der Informationsstruktur regelbasiert interpretiert werden und Aktionen zur Folge haben können. Es handelt sich also in gewisser Weise um die aktivierte Form des Meta-Directories. Schließlich muß noch gesagt werden, daß in diesem Dokument auch Linux unter dem Begriff UNIX subsummiert wird. Das ist nicht strikt korrekt, erleichtert aber sowohl die Arbeit als auch das Lesen, wenn nicht ständig UNIX/Linux geschrieben werden muß. Für alle technischen Aussagen sind beide Plattformen ohnehin identisch zu behandeln. 2 Problemstellung Nachdem in der Einleitung eine grobe Einordnung des Themas erfolgt ist, sollen in diesem Kapitel die allgemeinen Problemstellungen, die sich im Umfeld des Benutzer-Managements ergeben, dargestellt, bewertet und kommentiert werden. 2.1 Einführung Die grundsätzliche Aufgabe ist bereits in Kapitel 1.2 umrissen worden: Ziel einer einheitlichen Benutzerverwaltung soll die zentrale Bereitstellung von Zugangsinformationen zu allen Systemen einer Organisation sein. Unabhängig von der Bereitstellung ist es häufig erforderlich, daß die Verwaltung und Pflege dieser Informationen dezentral erfolgt. Beispielsweise kann die Verwaltung der Informationen jeweils auf Verwaltungsebene sinnvoll sein. Darüberhinaus ist es vorstellbar, daß die Informationen nicht ganzheitlich erfaßt und gepflegt werden. So ist es durchaus ein typischer Fall, daß gewisse Stammdaten der Benutzer zentral von einer Personalstelle erfaßt und bereitgestellt werden, während detaillierte Berechtigungen für Systeme und Anwendungen auf Abteilungsebene vergeben werden. Man sieht aufgrund dieser wenigen Beispiele bereits, daß eine moderne Benutzerverwaltung nicht nur aus der Bereitstellung eines zentralen Directories und einem geeigneten Bedienwerkzeug für die Administratoren besteht. 2.2 Anforderungen Klassische Benutzerverwaltungen auf der Basis von NIS oder einem ähnlichen System können in der Regel nur sehr grob Zugangsberechtigungen verwalten: Eine effektive Unterscheidung zwischen Authentisierung und Autorisierung findet in der Regel nicht statt, sondern wird an die Einzelsysteme delegiert, die jeweils lokale Lösungen implementieren. Im UNIX-Umfeld werden häufig modifizierte Login-Binaries , Rev. B Seite 5 / 15

6 eingesetzt, die Zugangskontrollen unabhängig von einer erfolgten Authentisierung implementieren. Die zugehörigen Informationen werden in der Regel in lokalen Files gehalten. Wenn man die Verwaltung sämtlicher IT-Ressourcen unter einem einheitlichen Konzept betreiben will, ist ein solcher Ansatz problematisch. Es ist vielmehr erforderlich, daß sämtliche Informationen, die zur Entscheidung über die Nutzungsberechtigung einer Ressource erforderlich sind, systemunabhängig gehalten werden. Auf diese Weise kann die Verwaltung und Pflege der Informationen innerhalb der Organisation verteilt werden, ohne daß dazu jeweils konkrete Kenntnisse über konkrete Systeme erforderlich sind. Häufig sind die vorhandenen Systeme wie NIS ergänzt durch weitere Repositories, die Informationen zu den Zugangsberechtigungen zu bestimmten Ressourcen wie Compute-Servern, gewissen Informationsquellen (Web-Server) oder speziellen Anwendungen enthalten. Diese Repositories werden dann mittels eigens geschriebener Scripten ausgelesen und die Informationen auf die betreffenden Systeme verbracht. Dort werden sie geeignet interpretiert und in Informationen für die entsprechende Ressource umgesetzt. Eine moderne Benutzerverwaltung muß diese Anforderung ebenfalls erfüllen. In der Regel gehen zunächst alle Anforderungen davon aus, daß möglichst effiziente und differenzierte Verfahren zur Bereitstellung von Zugangsinformationen implementiert werden müssen, damit neue Benutzer auch in komplexen Umgebungen schnell mit sämtlichen Arbeitsmitteln ausgestattet werden können. Eine wichtige Anforderung besteht darüberhinaus in der Implementierung eines effizienten Verfahrens zum Widerruf dieser Berechtigungen. Da zunehmend Zugänge zu sensiblen Bereichen einer Organisation nicht mehr vom physischen Zugang zu einem Gebäude abhängig sind, muß dieser Anforderung besondere Aufmerksamkeit gelten. Schließlich sind mit der Verwaltung von Benutzern häufig auch Accounting- und Auditing-Anforderungen verbunden. Sei es, daß die Nutzung von gewissen Ressourcen kostenpflichtig ist, oder daß der Zugang zu Ressourcen jedenfalls in jedem Einzelfall mitprotokolliert werden soll, immer müssen die entsprechenden Informationen zu diesen Anforderungen irgendwo vorgehalten werden. 2.3 Problematik von Lösungsansätzen Es ist bereits angeklungen, daß Lösungen häufig aus einer Ansammlung von Scripten bestehen, die jeweils konkrete Anforderungen implementieren. Dies ist ein Ansatz, der in der Regel historisch begründet ist: Ausgehend von der einfachen zentralen Verwaltung von Login-Informationen sind weitere Anforderungen hinzugekommen, die zunächst die Bereitstellung zentraler Repositories für die Daten und dann die Erstellung von Scripten zur Interpretation der dortgehaltenen Informationen erforderlich machten. So entstehen komplexe Ketten von Arbeitsabläufen, die in der Regel nur unzureichend dokumentiert sind und im Fall einer Änderung mit schwer zu quantifizierenden Risiken verbunden sind. Insbesondere stellt die Einführung neuer Systeme oder die Migration von Ressourcen auf andere Systeme nicht selten die gesamte Konstruktion auf die Probe. 2.4 Konsequenzen Aus dem bisher Gesagten ergibt sich eine Reihe von Konsequenzen, die bei der Realisierung einer einheitlichen Benutzerverwaltung beachtet werden sollten. Um die konkrete Implementierung einer Lösung möglichst einfach zu halten, sollte die Menge der Eingriffe in die einzelnen Systeme gering gehalten werden. Es ist klar, daß man in der Regel nicht ohne irgendwelche Eingriffe auskommen wird, doch müssen diese gut standardisierbar sein, so daß neu hinzukommende Systeme leicht mit den erforderlichen Anpassungen versehen werden können. Was auf dem Niveau der Systeme gilt, muß ebenso für die einzubeziehenden Ressourcen gelten: Die Anpassungen, die zur Implementierung von Zugangskontrollen erforderlich sind, müssen minimiert werden. Die Forderung ist hier noch entscheidender, denn wenn es auf der Ebene des Betriebssystems schwierig und risikoreich ist, lokale Anpassungen vorzunehmen, so ist es auf der Ebene der einzelnen Anwendung in der Regel unmöglich, falls man sich nicht an Standards hält: Es ist nicht zu erwarten, daß eine beliebige Anwendung die Abfrage eines lokalen Files oder einer selbst erfundenen Datenbanktabelle unterstützt. Hier muß man sich auf etablierte Verfahren abstützen, und LDAP bietet zumindest eine gewisse Gewähr dafür, daß man bei Anwendungsentwicklern Gehör findet, wenn man entsprechende Schnittstellen nachfragt , Rev. B Seite 6 / 15

7 3 Organisatorische Themen Im Rahmen eines Projektes zur Einführung eines vereinheitlichten Benutzer-Managements ergeben sich lange vor Beginn der Implementierung wichtige organisatorische Fragen, die angemessen beantwortet werden müssen, damit keine Projektrisiken in die Implementierungsphase hineingetragen werden. Die folgende Liste gibt eine erste Übersicht über die Fragen, die im Rahmen eines solchen Projektes bedacht werden sollten: 1. Sollten die Benutzerdaten zentral oder dezentral gepflegt werden? 2. Gibt es andere Stellen innerhalb der Organisation, die bereits Daten erfassen? 3. Sollen diese bereits erfaßten Daten in die Benutzerverwaltung integriert werden? 4. Gibt es Arbeitsabläufe, die im Rahmen der Benutzerverwaltung zu berücksichtigen sind? 5. Gibt es Abrechnungs- oder Zugangskontrollverfahren? Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sie zeigt aber typische mögliche Facetten auf, die ein Projekt zur Einführung einer einheitlichen Benutzerverwaltung haben kann. Die folgenden Abschnitte dieses Kapitels gehen auf die aufgeführten Fragen exemplarisch genauer ein und geben darüberhinaus einen Ausblick auf weitere Aspekte, die zu bedenken sind. Natürlich kann in jedem Einzelfall die Einführung einer LDAP-basierten Benutzerverwaltung erheblich einfacher sein: Wenn nur die bislang mittels NIS oder ähnlicher Verfahren zentral vorgehaltenen Informationen für die Standard-Services beim Login migriert werden sollen, können in der Regel sämtliche genannten Fragen ignoriert werden. Aber selbst in diesem Fall empfiehlt sich eine kurze Prüfung, denn die Migration kann ja Anlaß für die Erweiterung der Funktionalität sein. 3.1 Datenerfassung und Datenpflege Im einfachsten Fall findet die Datenerfassung und Pflege zentral statt. Alle erforderlichen Daten zur Verwaltung der Benutzer werden an einer Stelle organisatorisch und möglichst auch technisch erfaßt. In diesem Fall sind wenige Dinge zu bedenken, alle Daten können formal als vollständig angenommen werden, fehlerhafte oder unvollständige Daten können direkt erkannt und bearbeitet werden. Sowohl die Einrichtung neuer Benutzer als auch das Entfernen alter Benutzer erfolgt in einem Arbeitsschritt als eine abgeschlossene Transaktion. Diese Situation ist allerdings nur in kleinen Organisationen gegeben. Selbst bei nur wenigen hundert Benutzern kann die Verteilung von Aufgaben bereits sinnvoll sein. In einem solchen Fall wird immer noch jeder Benutzer vollständig an einer Stelle erfaßt, jedoch kann die Erfassung an verschiedenen Stellen erfolgen, die jeweils diese Berechtigung für einen wohldefinierten Teil der Organisation übertragen bekommen haben. In einem solchen Fall ist es erforderlich, sich vor Beginn der Implementierung Gedanken über die Struktur zu machen, damit der Aufbau des Directories entsprechend erfolgen kann. Die Verteilung administrativer Berechtigungen kann erheblich einfacher erfolgen, wenn die Struktur des Directories hier bereits unterstützend wirkt. Falls die Erfassung und Pflege der Daten in der Weise dezentral erfolgt, daß Teile der jeweiligen Benutzerinformationen an verschiedenen Stellen erfaßt und gepflegt werden (Personalabteilung, Fachabteilungen), so sind andere Ansätze erforderlich. Traditionell wird dieses Problem bei der Benutzerverwaltung ignoriert: Die technisch relevanten Informationen werden, meist manuell, übernommen, danach existiert der neue Datensatz autonom. Dies führt zu dem Problem, daß die Pflege ebenfalls weitgehend manuell erfolgt beziehungsweise häufig unterbleibt: Der Benutzer Meier, der seinen Namen durch Heirat ändert, wird zwar in der Personalabteilung mit neuem Namen geführt, das entsprechende GCOS-Feld der Benutzerverwaltung enthält aber weiterhin die alten Informationen. Um derartige Anforderungen im Rahmen der Benutzerverwaltung abzudecken, sind weitergehende Konstruktionen erforderlich. Hier hört das einfache User-Mangement auf und das Identity-Management beginnt. In den einfacheren Fällen läßt sich allerdings bereits mit wenig Aufwand eine Lösung implementie , Rev. B Seite 7 / 15

8 ren. Entscheidend ist nur, daß bereits in der Planungsphase alle Datenquellen mit den von ihnen jeweils verantworteten Daten identifiziert werden. Schließlich stellt die Einbindung von weiteren Ressourcen, die bislang über eine eigene Benutzerverwaltung verfügt haben, in die zentrale Benutzerverwaltung eine Herausforderung dar. Typische Beispiele für diese Situation sind sowohl Datenbanken als auch Webserver mit geschützten Bereichen. Ein Spezialfall ist die Zusammenführung verschiedener Benutzerverwaltungen aus UNIX- und Windows-Netzen. Hier ist zu entscheiden, ob die Einführung einer zentralen Benutzerverwaltung gleichzeitig Anlaß für die Zusammenführung von Benutzernamen und anderen Daten sein soll; in diesem Fall hat man sich das Leben für die Implementierungsphase erheblich erleichtert. Es wird jedoch auch Situationen geben, in denen ein derartiger Neuanfang nicht möglich ist oder nicht in Frage kommt. Dann wird man, falls dennoch die einzelnen Identiäten zusammengefaßt und einheitlich verwaltet werden sollen, wiederum auf eine Lösung aus dem Bereich des Identity-Managements zurückgreifen müssen. Man sollte sich für den Fall, daß das Projekt vor einer derartigen Aufgabe steht, klar darüber sein, daß diese Aufgabe schwer ist: Die verschiedenen Identitäten müssen dynamisch miteinander identifiziert werden. Änderungen an einer Stelle dürfen die Konsistenz der Gesamtsystems nicht zerstören, und die Kopplung der Einzelsysteme darf nicht als starr angenommen werden. 3.2 Integration von Fremddaten Nicht selten werden bereits an verschiedenen Stellen Daten verwaltet, die in irgendeiner Beziehung zum Benutzer-Management stehen. Das können Informationen über Zugangsberechtigungen zu Compute- Servern ebenso sein wie die Passwort-Abfragen von Webservern oder auch die Abrechnungsinformationen von Druckern oder Plottern. Diese Informationen müssen in irgendeiner Weise Berücksichtigung finden, wenn eine einheitliche Benutzerverwaltung etabliert werden soll. Organisatorisch bedeutet dies, daß festgelegt werden muß, welche der bereits erfaßten Daten künftig zentral und direkt im Zusammenhang mit den Benutzerinformationen verwaltet werden sollen. Insbesondere sind hier wiederum Zuständigkeiten zu beachten, denn die Fremddaten stehen in der Regel in einem Zusammenhang mit fachlichen Abläufen. Damit wirken die in diesem Kontext getroffenen Entscheidungen ein auf die Frage der zentralen oder dezentralen Pflege der Benutzerdaten selbst. 3.3 Integration von Arbeitsabläufen Die Integration von Arbeitsabläufen ist bereits an einigen Stellen der vorigen Abschnitte angesprochen worden. In größeren Organisationen wird nicht selten die eigentliche Benutzerverwaltung mit der allgemeinen Personaldatenerfassung, der Integration in organisationsinterne Informationssysteme wie Telephonbücher oder elektronische Organigramme sowie der Anbindung an weitere externe Systeme verknüpft. In einem solchen Fall ist wiederum die Struktur der erfaßten Daten und die Verteilung der Zuständigkeiten von Bedeutung. Wenn darüberhinaus die Arbeitsabläufe bereits elektronisch implementiert sind, dann ist eine Entscheidung über die Abbildung der Arbeitsabläufe in den betreffenden Systemen bereits zu Beginn des Projektes sinnvoll. 3.4 Accounting / Auditing Ein häufig anzutreffender Spezialfall der oben diskutierten Themen sind Abrechnung und Überwachung der Nutzung spezieller Ressourcen. Insbesondere die Nutzung von Druckern oder teuren Hochleistungsrechnern wird sehr oft betrieben, indem die systemseitig vorhandenen Mittel zur Datenerfassung genutzt werden. Die erfaßten Daten werden dann extern mit den Benutzerdaten verknüpft und zu einer entsprechenden Rechnungsstellung genutzt. Wenn ein solches Verfahren im Rahmen des Projektes übernommen werden soll, so ist zu prüfen, welche Prozesse damit verbunden sind. Eine eingehendere Diskussion dieses Themenkomplexes muß hier leider unterbleiben , Rev. B Seite 8 / 15

9 4 Technische Fragen Gleichwertig zu der Beantwortung der organisatorischen Fragen, die im Kapitel 3 dargestellt worden sind, müssen technische Fragen beantwortet werden, damit die Einführung eines vereinheitlichten Benutzer- Managements erfolgreich durchgeführt werden kann. Im folgenden werden einige der im vorigen Kapitel angesprochenen Fragen nochmals unter technischen Aspekten beleuchtet. Insbesondere die Verknüpfung der Benutzerdaten im engeren Sinne mit weitergehenden Informationen einerseits und die Einbindung weiterer Komponenten, die Daten bereitstellen oder konsumieren, stellt unterschiedlich komplexe Anforderungen an die Technik, die im Projekt zum Einsatz kommen soll. Schließlich muß auch der (Regel-)Fall betrachtet werden, daß Benutzerdaten für eine heterogene Systemlandschaft mit unterschiedlichen Betriebssystemen bereitgestellt werden sollen. Wie bereits in der Einleitung gesagt, werden hier bei der technischen Realisierung ausschließlich LDAPbasierte Lösungen behandelt. Das bedeutet nicht, daß es sich hier um die einzig denkbare Lösung handelt. Sie wird aber zunehmend zu einem Standard, die bereits weite Verbreitung und Akzeptanz gefunden hat. 4.1 Allgemeine Fragestellungen Die erste entscheidende Frage, die sich bei der Einführung einer Benutzerverwaltung stellt, betrifft die zu erfassenden Systemtypen. In der Regel sind die Umgebungen seit Jahren gewachsen und zeichnen sich durch eine Vielzahl von unterschiedlichen Plattformen aus. Es ist entscheidend für den Erfolg des Projektes, daß man sich sehr früh über die zu unterstützenden Plattformen verständigt und gegebenenfalls Verfahren vorsieht, die die nicht unterstützten Systeme bis zu ihrer Ausmusterung einbindet. Wenn bereits in Teilen der Systemumgebung eine Benutzerverwaltung vorhanden ist, so wird man diese nicht ohne weiteres entfernen können. Neben praktischen Problemen, die in der Abdeckung weitergehender Funktionen begründet sein können, spielt auch die Akzeptanz einer solchen Aktion eine große Rolle, denn der Wegfall von Funktionalität wird von den Benutzern direkt wahrgenommen. Ein typischer Fall ist die Benutzerverwaltung von Windows-Systemen mittels ADS. Hier werden über die eigentliche Verwaltung von Benutzerinformationen weitergehende Funktionen bereitgestellt, die zwar nichts mit der Benutzerverwaltung zu tun haben, sich aber nicht von ihr trennen lassen. In einem solchen Fall ist die Ablösung von ADS in der Regel nicht zu empfehlen. Vielmehr müssen Mittel und Wege gefunden werden, damit die Daten im ADS auch außerhalb genutzt und gegebenenfalls mit anderen Informationen abgeglichen werden können. Falls unter den Systemen solche sind, die sich überhaupt nicht in die neue Lösung integrieren lassen, so müssen auf jeden Fall Gateway-Funktionen bereitgestellt werden, damit solche Systeme weiterhin voll integriert bleiben. Es ist in aller Regel unakzeptabel, wenn gewisse Systeme nicht mehr den Integrationsgrad von früher haben. Für die Gateway-Implementierung ist zu beachten, daß alle manuellen oder quasimanuellen Verfahren erhebliche Probleme mit sich bringen. Insbesondere gilt das für Verfahren, die asynchron Abgleiche von Datensätzen durchführen, um Altsysteme mit den erforderlichen Informationen zu versorgen. 4.2 Einfache Systeme Einfache Systemumgebungen sind solche, die bislang über keinerlei zentrale Verwaltung von Benutzerinformationen verfügen. Das können sowohl UNIX-Systeme mit lokalen Passwort-Informationen als auch Windows-Systeme ohne Domain-Struktur mit nur lokalen Authentisierungsverfahren sein. In einem solchen Fall hat man natürlich den Vorteil, daß man keinerlei Rücksicht auf bestehende Strukturen nehmen muß. Man kann von Anfang an planen, was aber durchaus auch Gefahren in sich birgt: Umgebungen sind selten so statisch, daß man den aktuellen Zustand zum alleinigen Maßstab der Planungen machen kann. Für den Fall der Benutzerverwaltung heißt das, daß man Überlegungen zur künftigen Struktur der Verwaltung anstellen und die erforderlichen technischen Vorkehrungen treffen sollte. Konkret sind exemplarisch folgende Punkte beachtenswert: 1. Werden Abteilungs- oder andere Strukturen in der Benutzerverwaltung benötigt? 2. Welche Plattformen sollen unterstützt werden? , Rev. B Seite 9 / 15

10 3. Welche Eingriffe in die Endsysteme werden akzeptiert? 4. Sollen Anwendungen ebenfalls integriert werden? Man sieht, daß die hier aufgeführten Fragen einen engen Bezug zu denen in Kapitel 3 haben. Im folgenden sollen die Konsequenzen der möglichen Antworten diskutiert werden Directory-Strukturen Da die in der Vergangenheit hauptsächlich verwendeten Verfahren wie NIS nur flache Strukturen kennen, liegt eine Übertragung einer derartigen Struktur auf ein LDAP-Directory zunächst nahe. Auf der einen Seite hat man mit einem solch einfachen Layout wenig Probleme, denn alle Informationen sind einfach zugänglich. Das wirkt sich zunächst positiv auf die Übersichtlichkeit aus. Falls jedoch die Notwendigkeit einer verteilten Benutzerverwaltung später auftritt, so sind Reorganisationen der Directory-Struktur unausweichlich: Die einzelnen Verwaltungsbereiche müssen in Teilbäume organisiert werden, damit die Sicherheitsmechanismen auf der Directory-Seite einfach implementiert werden können. Falls zu diesem Zeitpunkt bereits weitere Ressourcen das Directory nutzen, so ist mit ziemlicher Sicherheit auch dort eine Anpassung erforderlich, damit die Benutzerinformationen weiterhin gefunden werden. Bei der Wahl des Datenmodells für das Directory sollte jedoch nicht zu aufwendig strukturiert werden. Auf Vorrat Strukturen einzuführen, von denen man nicht weiß, ob sie jemals Verwendung finden werden, führt umgekehrt zu erheblichem Mehraufwand bei der Integration von Anwendungen. Es ist sinnvoll, daß man nur Strukturen einführt, die voraussichtlich innerhalb der kommenden 12 bis 18 Monate auch Verwendung finden werden Plattformunterstützung In der Regel stellt sich die Frage nach den zu unterstützenden Plattformen erstmalig in der hier betachteten Situation: Bislang waren alle Systeme mehr oder weniger auf sich allein gestellt, jetzt gibt es die Möglichkeit, endlich alle vorhandenen Plattformen einzubinden schließlich ist das ja auch ein wesentlicher Grund für das Projekt. Damit gerade bei einem vollständigen Neuaufbau einer zentralen Benutzerverwaltung nicht sofort eine Vielzahl von Problemen auftaucht, die den Projekterfolg entscheidend gefährden können, sollte aber eine sorgfältige Auswahl getroffen werden: Nicht jede alte Plattform kann überhaupt LDAP-fähig gemacht werden, nicht jede Betriebssystem-Version unterstützt die erwarteten Sicherheitsstandards. Hier sollte man sich beschränken und nur solche Plattformen direkt integrieren, die auch wirklich eine direkte Unterstützung von LDAP mitbringen. Gegebenenfalls müssen Betriebssysteme vorher aktualisiert werden. Es ist auf keinen Fall ein gute Idee, wenn man sich mit aufwendigen Manipulationen an den verschiedenen Endsystemen sofort zusätzliche Komplexität sowohl für die Einführungsphase als auch für den Betrieb aufbürdet. Auf jeden Fall ist es jedoch nützlich, ein NIS-Gateway vorzusehen, das die Informationen aus dem LDAP-Directory für NIS-Clients nutzbar macht: NIS wird von nahezu allen derzeit vorhandenen UNIX-Derivaten verstanden und kann somit zur Anbindung auch älterer Systeme dienen. In der Regel werden neben den UNIX-Systemen auch Windows-Systeme vorhanden sein. Da die Voraussetzung für die Diskussion in diesem Abschnitt ist, daß noch keine Domain-Struktur vorhanden ist, handelt es sich also auch bei diesen Systemen um solche, die ihre Benutzerinformationen lokal halten. Diese Systeme werden gleich noch einmal im Abschnitt behandelt werden. Aus Sicht der zentralen Benutzerverwaltung ist festzustellen, daß in der Regel die einfachste und schnellste Lösung in diesem Fall darin besteht, daß ein System mit Samba 3.x ausgestattet und als Domain-Controller verwendet wird. Dieses Verfahren hat den entscheidenden Vorteil, daß es einfach zu implementieren ist und keine weiteren Lizenzkosten anfallen. Demgegenüber ist der Aufbau einer echten Domain mit einem Window-System als Domain-Controller erheblich aufwendiger, da eine Integration in das Directory zusätzlich implementiert werden muß Eingriffe in die Endsysteme Die Frage nach den erforderlichen oder sinnvollen Eingriffen in die Endsysteme ist von großer Bedeutung, da ihre Beantwortung über die Komplexität des späteren Betriebes mitentscheidet. Die Grundregel lautet, daß die geringstmögliche Menge an Veränderungen anzustreben ist. Gerade in der hier diskutierten Ausgangssituation besteht aber durchaus die Neigung, Systeme dadurch an das zentrale Directory anzu , Rev. B Seite 10 / 15

11 binden, daß man entsprechende Erweiterungen am Betriebssystem vornimmt. Ganz abgesehen von der Frage des Spports solcher Lösungen führen sie aber auch im täglichen Betrieb zu Problemen: Sämtliche Installationen von Systemen werden durch die Anpassung komplexer. Es müssen technische Verfahren implementiert werden, die diese Anpassungen auf neu installierten Systemen durchführen, damit keine Inkonsistenzen entstehen. Alle Änderungen an Endsystemen müssen zwingend so implementiert sein, daß sie automatisch durchg e- führt werden können. Sie müssen also technisch in den Installationsprozess eines Systems integriert werden. Für gewisse Plattformen ist das leichter als für andere. In jedem Fall ist dafür aber eine Infrastruktur erforderlich, deren Vorhandensein nicht immer gegeben ist. Es ist kein Argument, daß die Anzahl der Systeme verhältnismäßig klein sei und außerdem die Systeme sich nicht stark veränderten. Gerade in einer solchen Situation ist ein manueller Eingriff in ein System besonders problematisch, weil er vermutlich nicht häufig geübt werden kann. Ein notwendiger Austausch von Hardware infolge eines Defektes wird dann noch lästiger Anwendungsintegration Für die Integration von Anwendungen in einer einfachen Systemumgebung gibt es technisch erheblich weniger zu sagen. In der Regel wird man schon aus Komplexitätsgründen die Auswahl der in die Benutzerverwaltung zu integrierenden Anwendungen sorgfältig treffen. Falls es ein klar dokumentiertes Verfahren zur Anbindung an ein LDAP-Directory gibt, ist gegen eine sofortige Integration nichts einzuwenden. Es ist eher im Gegenteil so, daß eine derartige Integration die Akzeptanz deutlich verbessern kann, weil die Benutzer sofort einen klaren Vorteil der neuen Benutzerverwaltung wahrnehmen. Da in diesem Abschnitt davon ausgegangen wird, daß es noch keine einschlägigen Erfahrungen mit LDAP als Grundlage der Benutzerverwaltung gibt, sollte in allen anderen Fällen sehr sorgfältig abgewogen werden, ob eine Anwendung in die Benutzerverwaltung integriert wird. Weiter unten wird auf das Thema der Anwendungsintegration im Allgemeinen nochmals genauer eingegangen. 4.3 Homogene Umgebungen Homogene Umgebungen sind selten. Es handelt sich dabei um Umgebungen, die entweder ausschließlich aus Systemen mit einem UNIX-Derivat als Betriebssystem oder aus Windows-Systemen bestehen. Da der letztere Fall hier nicht behandelt wird, muß darauf nicht intensiv eingegangen werden. Es soll aber unbedingt gesagt werden, daß in einem solchen Fall in der Regel die sinnvollste Lösung darin besteht, die vorhandene Infrastruktur für die Benutzerverwaltung zu nutzen. Eine typische Ausnahmesituation ist dann gegeben, wenn es klar ist, daß in absehbarer Zukunft die Integration von Anwendungen eine erhebliche Rolle bei der Benutzerverwaltung spielen wird. Im anderen Fall beschränkt sich das Dokument auf die Betrachtung der Situation, daß es sich um Solaris, HP UX oder Linux als Plattform handelt. In jedem dieser Fälle wird LDAP mehr oder weniger direkt auf der Ebene des Betriebssystems unterstützt. Wenn also ausschließlich die Authentisierung der Benutzer in einem zentralen Directory realisiert werden soll, so kann man direkt vorgehen und eine Standardlösung implementieren. Wichtig ist die Beantwortung der organisatorischen Fragen, die im letzten Kapitel diskutiert worden sind. Die eigentliche technische Realisierung erfolgt dadurch, daß je nach Verfügbarkeits- und Strukturanforderung ein oder mehrere LDAP-Server bereitgestellt werden, die jeweils Teile oder die Gesamtheit aller Informationen bereitstellen. Die Diskussion der konkreten Lösungsansätze in jedem dieser Fälle wird weiter unten (Kapitel 5) erfolgen. Falls keine Besonderheiten realisiert werden müssen, können die Eingriffe auf den Endsystemen auf ein Minimum beschränkt werden. Zwingend erforderlich ist in jedem Fall nur, daß konfiguratorisch die Endsysteme ihre Benutzerinformationen von einem LDAP-Server erhalten. Dies ist bei den betrachteten Plattformen in der Regel bereits vorgesehen und kann unbedingt als unkritisch angesehen werden. Zu beachten ist aber auch in dieser Situation, daß die Migration der Daten aus den vorhandenen Systemen erfolgen muß. Dies wird weiter unten (Abschnitt 4.5) exemplarisch diskutiert , Rev. B Seite 11 / 15

12 4.4 Heterogene Umgebungen Die hier betrachteten heterogenen Umgebungen zeichnen sich dadurch aus, daß sie neben den oben beschriebenen UNIX-Systemen auch Windows-Systeme enthalten. Dies ist sicher der Normalfall, da sehr viele Installationen Windows-Systeme am Arbeitsplatz einsetzen Windows-Systeme GINA Entscheidend ist in dieser Situation die Integration der Windows-Systeme, wobei darunter hier ausschließlich die Integration der Benutzer-Anmeldung zu verstehen ist. Grundsätzlich besteht die Möglichkeit der Integration durch Anpassen der Endsysteme, wofür es einige Ansätze gibt, die alle von einer Änderung des GINA-Moduls auf dem Endsystem ausgehen. Diese Verfahren sind in der Regel für Windows 2000 und Windows XP entwickelt worden, funktionieren jedoch wegen der engen Verwandschaft auch auf NT- Systemen. Wenn es einzeln stehende Windows-Systeme in einer UNIX-Umgebung gibt, deren Benutzer-Authentisierung über ein UNIX-Verfahren erfolgen soll, so bietet sich ein solches Vorgehen an. Es erfordert allerdings einen Eingriff in die Endsysteme, was wohl bedacht sein will, aber dafür erhält man beispielsweise eine klare LDAP-Authentisierung dieser Systeme ohne weitere Services. Da die GINA-Anpassungen sich an dem PAM 1 -Schema orientieren, ermöglich die Verwendung einer solchen Anpassung dann auch, daß andere oder mehrere Authentisierungsverfahren auf dem Endsystem implementiert werden. Das kann in Umgebungen mit speziellen Rahmenbedingungen sehr nützlich sein. Falls man sich vor einem solchen Schritt scheut oder aber Gründe für die Nicht-Antastung der Endsysteme bestehen, so kann man auf ein anderes inzwischen etabliertes Verfahren zurückgreifen: Die Verwendung von Samba als Domain-Controller für eine NT-Domain. Die Ursprünge für diese Möglichkeit liegen inzwischen einige Jahre zurück, der entsprechende Samba-Code ist nunmehr Bestandteil des Produktionscodes und kann als stabil gelten. Da außerdem Samba seit längerem in der Lage ist, seine Informationen auch in einem LDAP-Verzeichnis abzulegen, kann man auf diese Weise die Benutzer-Informationen zentral ablegen und für UNIX- und Windwos-Systeme gleichermaßen zugänglich machen. Das hier skizierte Verfahren, dessen Details den Rahmen dieser Übersicht sprengen, ist von kippdata in Projekten erfolgreich zur Integration von Windows- und UNIX-Umgebungen eingesetzt worden. Es sei angemerkt, daß man sowohl kommerzielle LDAP-Server als auch OpenLDAP für den Directory-Server verwenden kann. In den allermeisten Fällen wird letzterer ausreichend sein, so daß keine weiteren Lizenzkosten an dieser Stelle anfallen Vorhandene Domains ADS Falls bereits eine Windows-Domain existiert, so kann man grundsätzlich dennoch die Umstellung des Domain-Controllers auf Samba in Erwägung ziehen. Man kann mittlerweile auch die neben der Benutzerverwaltung häufig verwendete Druckerverwaltung in der Domain mit Samba realisieren. Zu bedenken ist in diesem Fall nur, daß mit der Umstellung gewisse Verfahren der Verwaltung eher UNIX-artig werden, was in einer heterogenen Umgebung aber möglicherweise toleriert werden kann. Da sich ein Domain-Controller unter Samba sehr gut in einer UNIX-Umgebung administrieren und überwachen läßt, können sich sogar Vorteile für den vereinheitlichten Betrieb ergeben. Da sich, wie bereits erwähnt, möglicherweise nicht alle Systeme direkt auf LDAP umstellen lassen, ist ein Verfahren erforderlich, das auch die typischerweise vorhandenen NIS-basierten Dienste weiterhin unterstützt. Man kann hier natürlich auf ein selbstgebautes Verfahren zurückgreifen, das im wesentlichen die relevanten Informationen aus dem LDAP-Server exportiert und einem NIS-Server zur Verfügung stellt, aber in allen nicht-trivialen Fällen wird dieses Verfahren nur mit großem Aufwand produktionssicher zu implementieren sein. Die bidirektionale Kommunikation zwischen NIS und LDAP erfordert die Implementierung von Services, die sich nicht mehr ohne weiteres als Shell-Script realisieren lassen. 1 PAM steht für Pluggable Authentication Module es handelt sich um ein Verfahren zur modularen Konfigurierbarkeit von Authentisierung, das auf diversen UNIX-Systemen, unter anderem auf Linux und Solaris, Anwendung findet und Pate gestanden hat für die Modellierung von JAAS, dem Java Authentication an Authorisation System , Rev. B Seite 12 / 15

13 In der Regel bietet sich hier die Verwendung eines Gateways an, das als bereits fertiger Baustein eingestzt werden kann. Hierfür gibt es verschiedene Lösungen, unter denen diejenige von PADL einige Bekanntheit erlangt und sich bewährt hat. Abschließend sei hier noch kurz auf die ADS-Problematik eingegangen. Es ist grundsätzlich möglich, eine ADS-Domain von einem Samba-Server aus zu bedienen. Man verliert dabei allerdings derzeit noch alle Besonderheiten, die ADS über die reine Benutzer-Authentisierung noch bietet. Es bestehen grundsätzlich zwei Möglichkeiten: Man kann den ADS-Server mit einer Erweiterung als LDAP-Server für die UNIX- Systeme nutzen oder aber ein Gateway implementieren, das einen bidirektionalen Austausch zwischen ADS und LDAP ermöglicht. Während die erste Variante nur in Ausnahmefällen sinnvoll ist, wird die zweite Variante gerade in komplexen Umgebungen einen realen Ausweg ermöglichen. Man begibt sich dann allerdings auf das Gebiet des Identity-Managements, das hier zunächst ausgeklammert bleibt. 4.5 Migration der vorhandenen Daten Ein eigener Abschnitt muß dem Problem der Datenmigration gewidmet werden. Gemeint ist hiermit die Übernahme der Benutzerdaten aus den bisherigen Systemen in das neue LDAP-Verzeichnis. Da es sich häufig um mehr als eine einfache Liste aus einer Passwort-Datei handelt, muß man sich überlegen, ob die Übernahme mit der Errichtung einer neuen Struktur einhergehen soll oder ob man die gewohnte, in der Regel flache, Struktur beibehalten will. Neben diesen Überlegungen muß der reine Ex- und Import erledigt werden. Angenehmerweise werden hier normalerweise keine Probleme auftreten. Für das Directory exisiteren Standard-Schemata, die verwendet werden können; die Daten selbst können mit entsprechenden Werkzeugen aus den bisherigen Repositories ausgelesen und in das neue Directory eingelesen werden. Selbst für große Benutzerzahlen entstehen hier keinerlei Probleme, solange nicht die Zusammenführung mehrerer Repositories Probleme der Eindeutigkeit von Benutzer-Credentials aufwirft. Diese Probleme sind dann aber nicht mehr technisch zu lösen, sondern müssen organisatorisch angegangen werden. 4.6 Fremdsysteme und Fremddaten Fremdsysteme im Sinne dieses Abschnittes sind Ressourcen, also in der Regel Anwendungen, die entw e- der als Quelle oder als Ziel für Benutzerdaten auftreten. Damit handelt es sich konzeptionell um ein von den bislang diskutierten Problemen verschiedenes. Da eine erschöpfende Behandlung der damit verbundenen Problematik hier nicht erfolgen soll, wird nur kurz auf die Thematik eingegangen, und es werden insbesondere die folgenden Punkte kurz beleuchtet: Anwendungen und Authentisierung PAM Verfahren zur Authentisierung und Autorisierung unter UNIX Integration von Anwendungen Ein naheliegender Schritt bei der Einführung von zentralem Benutzer-Management auf Systemebene ist die Ausdehnung auf Anwendungen, die den Benutzern auf den Systemen zur Verfügung gestellt werden. Dies kann sowohl Datenbanken oder andere systemnahe Bereiche als auch beispielsweise Webserver umfassen. Es ist klar, daß ein allgemeiner Zugang zu diesem Problemkreis nicht möglich ist: Da eine Vielzahl von unterschiedlichen Login-Verfahren existiert, muß man in jedem Einzelfall die vorhandenen Optionen prüfen. Diese können Hilfsmittel wie Expect umfassen oder im angenehmen Fall die bereits vorhandenen LDAP-Schnittstellen der Anwendung nutzen. Ein sehr gutes Beispiel für eine Anwendung der angenehmen Sorte ist der Apache-Webserver, der um einen LDAP-Modul erweitert werden kann und dann die einer Zugangskontrolle unterworfenen Teile eines Dokumentenbaumes vermittels LDAP authentisiert PAM Zwar handelt es sich bei PAM weder um ein Fremdsystem noch um Fremddaten, aber seiner Bedeutung für das gesamte Konzept wegen sollen hier einige Bemerkungen gemacht werden. Wie bereits erwähnt wurde, handelt es sich bei PAM um ein Verfahren zur modularen Implementierung von Authentisierung und Autorisierung. Es bietet die Möglichkeit, diverse derartige Services den entsprechenden Clients zur Verfügung zu stellen, ohne daß hierfür die Clientanwendungen jeweils geändert und , Rev. B Seite 13 / 15

14 neu übersetzt werden müssen. Die verwendeten Verfahren sind wohlbekannt und nutzen das Binden von Funktionsbibliotheken zur Laufzeit aus. Grundsätzlich kann jede Anwendung diesen Mechanismus nutzen; in der Praxis handelt es sich aber meist um die Systemservices und einige wenige andere Nutzer. Im Kontext der Realisierung einer Benutzerverwaltung kann PAM auf mehrfache Weise nützlich sein. Zunächst bietet es die Möglichkeit, die Authentisierungsverfahren, die einem Endsystem zur Verfügung stehen, zu erweitern. Dazu muß man entweder einen entsprechenden PAM selbst erstellen oder einen von dritter Seite verfügbar gemachten Modul einsetzen. Insbesondere für LDAP gibt es hier diverse Möglichkeiten, die über die reine Implementierung eines Login hinausgehen. Da es explizit vorgesehen ist, daß das PAM-System lokal in einer Einrichtung ergänzt wird, hat man es hier auch nicht mit einem eigenmächtigen Eingriff zu tun, der in Produktionsumgebungen oft nicht statthaft ist. Über diese schlichte Erweiterung der Authentisierungsverfahren lassen sich weitere Einsatzmöglichkeiten aufzeigen. Da PAM zwischen Authentisierung und Autorisierung unterscheidet, kann man individuelle Autorisierungsverfahren implementieren, die wiederum Informationen aus einem LDAP-Verzeichnis auslesen. Für weitergehende Informationen sei auf die jeweilige Systemdokumentation oder auf diverse Online-Dokumente im Web verwiesen. Dort finden sich natürlich auch weitere Beispiele zu Einsatzmöglichkeiten. 4.7 Erweiterte Nutzungsmöglichkeiten Im Rahmen der Diskussionen in den vorigen Abschnitten sind bereits einige erweiterte Nutzungsmöglichkeiten für einen LDAP-Verzeichnisdienst dargestellt worden. Zum Abschluß des Kapitels sollen kurz typische reale Nutzungsprofile für einen derartigen Dienst aufgeführt werden. Zunächst bietet es sich an, die Tatsache zu nutzen, daß die Standard-Schemata für die Erfassung der Daten eines Benutzers über die minimale Menge an Attributen hinaus die Möglichkeit zur Speicherung weiterer Informationen bieten. Auf diese Weise kann man leicht den Dienst auch als Adressbuch und als Auskunftssystem für die Mitarbeiter nutzen. Um die Bedienung unproblematisch zu gestalten, bietet sich hier ein Web-Frontend an, das den Benutzern als Teil des Intranets angeboten werden kann. Entsprechende Implementierungen sind in der Regel nicht aufwendig. Daß weitere Anwendungen an den Verzeichnisdienst angeschlossen werden können, ist weiter oben bereits hinlänglich erwähnt worden. Hier soll nur noch einmal auf eine wichtige Klasse solcher Anwendungen hingewiesen werden: Die Web-Anwendungen. Dabei handelt es sich um Anwendungen, die entweder selbst direkt ein Web-Interface besitzen oder aber als Service in einem Portal integriert sind. In einer solchen Situation werden Single Sign On-Themen eine wichtige Rolle spielen. Natürlich kann man ein LDAP-Directory nutzen, um auch die übrigen klassischen UNIX-Systemdienste wie den Automounter oder andere traditionell via NIS bereitgestellte Informationen mit Informationen zu beliefern. Dies setzt allerdings eine entsprechende Unterstützung auf Systemseite voraus. Man muß hier jeweils im Detail genau hinschauen, denn in diesem Bereich stellt man schnell fest, daß die standardisierung noch nicht das wünschenswerte Maß erreicht hat. 5 Ausblick Weitergehende Lösungsansätze Zum Abschluß des Dokumentes sollen noch einige Anmerkungen zum Ausbau einer LDAP-Lösung gemacht werden. Die direkte weitergehende Nutzung ist im Abschnitt 4.7 skiziert worden, so daß in diesem Kapitel auf Möglichkeiten der Erweiterung in Richtung Datenströme und deren Konsolidierung eingegangen werden soll. Ein wichtiger Baustein einer solchen Betrachtung ist die Fähigkeit eines LDAP-Servers, auf die Änderung von Daten aktiv zu reagieren. Bei relationalen Datenbanken ist diese Fähigkeit unter dem Namen Trigger bekannt und wird in vielen Umgebungen eingesetzt. Moderne LDAP-Server bieten eine analoge Möglichkeit, durch Plugins Aktionen zu definieren, die bei jeder Änderung des Datenbestandes ausgeführt werden. Auf diese Weise kann man beispielsweise Daten an andere Systeme versenden, wenn sich Eintragungen im LDAP geändert haben. Für den Abgleich zwischen Directories ist das ein großer Vorteil, weil sich auf diese Weise eine direkte Verknüpfung des auslösenden Ereignisses (Datenänderung) mit der Aktion (Benachrichtigung / Abgleich) erreichen läßt. Man kann also auf die sonst üblichen Verfahren eines externen Monitoring mit all seinen Nachteilen verzichten , Rev. B Seite 14 / 15

15 Da das Thema des Datenaustausches schon angesprochen worden ist, soll auch die andere Richtung Erwähnung finden. Typischerweise liegen größere Mengen an relevanten Daten in relationalen Datenbanken und sollten zumindest teilweise jeweils in Deckung mit den entsprechenden Informationen des LDAP- Directories sein. Damit dies zuverlässig gelingt, müssen nun in umgekehrter Richtung Datenabgleiche durchgeführt werden. Schließlich gelangt man, wenn man die Gedanken der vorigen Absätze weiterdenkt, zu dem Komplex der Integration beliebiger Datenquellen und der Nutzung von Gateways zur Datenprovisionierung. In einem sehr einfachen Spezialfall ist das bereits vorgestellt worden, nämlich am Beispiel des NIS-Gateways. Dies führt wie bereits früher ausgeführt in den Bereich des Identity-Managements. Hier ist der entscheidende Aspekt, daß der Datenabgleich zwischen mehreren Datenquellen, die grundsätzlich gleichb e- rechtigt Teile von Datensätzen verwalten, sowohl eine organisatorische als auch eine technische Aufgabe darstellt. Um den technischen Teil in den Griff zu bekommen, sind Gateways, die über die Möglichkeit einer regelbasierten Zwischenverarbeitung und Weiterleitung von Datenströmen verfügen, ein sinnvoller Ansatz. Um dieses Thema technisch adäquat anzugehen, müssen allerdings weitergehende Betrachtungen angestellt werden. Eine Möglichkeit besteht in der Nutzung eines Gateways, das Datenströme entgegennimmt und entsprechend vordefinierten Regeln umwandelt und weiterleitet. Hierzu gibt es diverse Lösungen, die unter anderem unter dem Begriff Provisioning laufen , Rev. B Seite 15 / 15