Microsoft Metadirectory Services Betriebssystem Konzepte und Architektur Version 1.0 Zusammenfassung Dieses Dokument stellt einen kurzen Überblick über die Merkmale und Konzepte der Microsoft Metadirectory Services und deren Beziehung zur Identitätsverwaltung bereit. Das Problem der Identitätsverwaltung Das Metaverzeichnis stellt eine Lösung für das Problem der Identitätsverwaltung bereit. Abbildung 1: Die Schwierigkeit der Identitätsverwaltung Wie in Abbildung 1 gezeigt, stellt die Identität die Zusammenfassung der Informationen über Personen, Anwendungen und Ressourcen dar, die in den meisten IT-Unternehmen über mehrere Verzeichnisse und Datenbanken verstreut sind. Als Beispiele für Identitätsdaten von Personen seien Namen, Postfächer, Gehälter und Berufsbezeichnungen genannt. Anwendungsidentitätsinformationen umfassen die Netzwerkadressen, unter denen Clients Server erreichen können. Dazu gehören auch Listen der Dienste, die von den Anwendungen bereitgestellt werden können. Netzwerkressourcen, wie z. B. Drucker, besitzen ebenfalls Identitätsattribute: beispielsweise Standort und die unterstützen Druckeigenschaften. Die Problematik der Identitätsverwaltung Die Verschiedenheit der Identitätsdaten und die Anzahl der Stellen, an denen sich solche Daten befinden, führen zu einer Vielzahl von Anforderungen an die Verwaltung: Nicht alle Identitätsdaten sind in Verzeichnissen gespeichert oder über eine Verzeichnisdienstschnittstelle wie LDAP (Lightweight Directory Access Protocol) erreichbar. Viele Systeme stellen beispielsweise Identitätsinformationen nur über spezielle Schnittstellen für Anwendungsprogrammierung (Application Programming Interface, API) zur Verfügung. Identitätsinformationen sind häufig an mehreren Stellen doppelt vorhanden. Die einzelnen Versionen tendieren dazu, im Laufe der Zeit die Synchronisierung zu verlieren, wenn sie nicht regelmäßig überprüft werden. Normalerweise gibt es nicht nur eine einzige Stelle, an der Administratoren und Anwendungen eine aggregierte Sicht (auch Verknüpfung genannt) der Identitätsinformationen eines Unternehmens erreichen oder verwalten können. Die Anzahl der Stellen, an denen Firmen Identitätsdaten verwalten müssen, steigt mit jeder weiteren Anwendung und Plattform. Diese Problematik erschwert es Firmen, umfassende und integrierte Lösungen für die Identitätsverwaltung zu implementieren. Bleibt eine Unternehmensumgebung in diesem Zustand, steigen Kosten und Komplexität. Häufige Szenarien der Identitätsverwaltung Die meisten Großunternehmen beginnen bereits damit, in irgendeiner Form Projekte für die Identitätsverwaltung aufzusetzen. Die Anstrengungen betreffen: Globale Adressbuchanwendungen. Das Synchronisieren der Postfachinformationen zwischen den unterschiedlichen E-Mail-Verzeichnissen in einer Firma ermöglicht Benutzern die Suche anderer Benutzer und das Senden von E-MailNachrichten über verschiedene System hinweg. Lösungen für Mitarbeiterdaten. Das Verbreiten von Informationen über neu angestellte Mitarbeiter, wie z. B. Titel, Funktion und Zugriffsrechte, auf alle Systeme, die Identitätsdaten benötigen, ermöglicht die schnelle Einrichtung von Diensten. Die Systeme müssen darüber hinaus dieselben Prozesse schnell in umgekehrter Reihenfolge durchführen, wenn Mitarbeiter die Firma verlassen, um Sicherheitslücken zu vermeiden. E-Commerce-Anwendungen. Das Synchronisieren von unternehmensweiten Identitätsinformationen, wie z. B. digitale Zertifikate für Lieferanten und Extranetbenutzer, wird mithilfe von Verzeichnissen ermöglicht, die sich außerhalb der Firewalls befinden. Initiativen für Einzelanmeldungen. Das Verwalten von Benutzername, Kennwort und Informationen über Zugriffsrechte wird über eine Vielzahl unterschiedlicher Plattformen und Anwendungen hinweg ermöglicht, die eine Vielzahl unterschiedlicher Verfahren für Zugriffssteuerung und Kryptografie verwenden. Anforderungen an die Lösungen In der Vergangenheit haben viele Firmen versucht, ein einziges Verzeichnis zu erstellen, in dem alle Identitätsinformationen des Unternehmens gespeichert sind. Die meisten Versuche sind aus mehreren einfachen Gründen gescheitert: Viele Anwendungen lassen sich nicht einfach für die Verwendung von Verzeichnissen ändern. Es gibt gute Gründe, wie z. B. mehrere Anforderungen hinsichtlich Replikation und Sicherheit, warum einige Anwendungen Identitätsdaten in einem eigenen Format speichern müssen. Politische Grenzen verhindern eine vollständige Konsolidierung, ungeachtet dessen, was technisch möglich ist. Dies führt zu der Vermutung, dass Identitätsdaten weiterhin an vielen Stellen vorhanden sind und Firmen Möglichkeiten finden müssen, um die Zusammenarbeit der verschiedenen Verzeichnisdienste und Anwendungsrepositories realisieren zu können. Ausgehend davon, dass viele Identitätsrepositories vorhanden sind, müssen Lösungen folgende Funktionen bereitstellen: Verbindungsmöglichkeiten zu einer Vielzahl von Identitätsdaten. Verwaltung der Identitätsübertragung zwischen Repositories. Mechanismen für das Verwalten der Datenintegrität in der gesamten Infrastruktur für die Identitätsverwaltung. Diese Themen werden nachfolgend ausführlicher behandelt. Verbindungen Abbildung 2: Verbindungsanforderungen Die Verbindungsanforderungen sind einfach: je mehr Verzeichnisdienste, Datenbanken und Anwendungen vorhanden sind, zu denen Identitätsverwaltungslösungen Verbindungen herstellen können, desto größer wird die Wertsteigerung. Wie oben in Abbildung 2 gezeigt, können in einem Repository unbekannte Daten von einem anderen erhalten werden. Eine Identitätsverwaltungslösung kann Verbindungen zu einem bestimmten Repository herstellen, wenn die folgenden Möglichkeiten gegeben sind: Erhalten von Informationen über Änderungen im Repository. Hinzufügen neuer Objekte zum Repository. Löschen von Objekten aus dem Repository. Ändern vorhandener Objektattribute in andere Werte. Für eine umfassende Lösung müssen Technologien in der Lage sein, Verbindungen zu Daten in den folgenden Repositories herzustellen: Standardisierte Verzeichnisdienste über LDAP, Version 3. Verbreitete vorhandene E-Mail-Anwendungen und Nicht-LDAP-Verzeichnisdienste. ERP (Enterprise Resource Planning)-Anwendungen. Datenbanken über Zugriffsverfahren wie SQL. Anwendungen, in denen die einzige Schnittstelle zu Identitätsinformationen über Schnittstellen für Anwendungsprogrammierung (API) realisiert ist und keine Verzeichnisschnittstelle zur Verfügung steht. Informationsverwaltungsfluss Bei dem Informationsverwaltungsfluss handelt es sich um die Verwaltung des Flusses von Identitätsinformationen zwischen Repositories. Der Informationsverwaltungsfluss muss die folgenden Funktionen erfüllen können: Erkennen der Änderungen von Identitätsdaten und das Verbreiten von Aktualisierungen an andere Repositories. Zusammentragen von Daten anderer Repositories in Metaverzeichnisse, die eine ganzheitliche Sicht der Identitätsdaten im gesamten Unternehmen ermöglichen. Verfolgen verwandter Objekte, wenn sich deren Positionen in den Verzeichnisstrukturen und anderen Repositories aufgrund regelmäßiger Neuorganisation ändern. Abbildung 3: Verarbeitung von Änderungsereignissen Verarbeitung von Änderungsereignissen Änderungsereignisse treten immer dann auf, wenn Administratoren, Benutzer oder Anwendungen Teile von Identitätsdaten in einem Repository hinzufügen, löschen oder ändern. Ohne Verwaltung geht der Überblick über Änderungen von Identitätsdaten schnell verloren. Lösungen für die Identitätsverwaltung müssen daher Funktionen bereitstellen, um Änderungen zu erkennen, die erforderlichen Übersetzungen der Datenformate durchzuführen und anschließend alle Repositories zu aktualisieren, die die Änderungen enthalten sollen. Wenn ein Administrator beispielsweise einen neuen Mitarbeiter zu der Personaldatenbank hinzufügt, müssen die von der jeweiligen Person verwendeten Systeme durch dieses Änderungsereignis entsprechend aktualisiert werden. In der oben gezeigten Abbildung 3 wird die Änderung an andere Verzeichnisse und Anwendungen verbreitet. Abbildung 4: Datenaggregation in einem Metaverzeichnis Eigenschaften der Datenaggregation Da Identitätsinformationen in den meisten Unternehmen vorhanden sind, können Verzeichnisse, die eine Aggregation von Identitätsdaten vieler anderer Repositories enthalten, von großem Nutzen sein. Dieses Konzept eines Metaverzeichnisses wurde zuerst von The Burton Group vorgestellt, die den Begriff Verknüpfung verwendete, um eine aggregierte Sicht der Identitätsdaten eines Unternehmens darzustellen. Bei einem Metaverzeichnis können Anwendungen mithilfe eines einzelnen Zugriffsverfahrens und Sicherheitsmodells auf eine Vielzahl von Informationen an einer Stelle zugreifen, anstatt mit den einzelnen Quellrepositories zusammenzuarbeiten. Metaverzeichnisse maximieren außerdem die Leistung, da die Daten in indizierter Form gespeichert werden können. Es besteht keine Notwendigkeit, die Daten zur Laufzeit von den Quellen abzurufen, die möglicherweise nur über WAN-Verbindungen erreichbar sind. Für optimalen Nutzen muss die Datenaggregation die folgenden Aufgaben erfüllen: Erfassen und Integrieren von Informationen von vielen Quellen wie Verzeichnissen, Datenbanken und Anwendungen. Gruppieren verwandter Informationen, auch wenn sie an verschiedenen Stellen auf unterschiedliche Weise gespeichert sind. Daten über einen Benutzer mit dem Namen "Jeff Smith" können beispielsweise in verschiedenen Systemen unter Namen wie "Jeff Smith", "jsmith" und "smithj" gespeichert sein (siehe dazu Abbildung 4 oben). Übertragen von Änderungen zurück an die Quelle, wenn Benutzer oder Anwendungen die aggregierte Sicht ändern. Metaverzeichnisse müssen also in die Verarbeitungsinfrastruktur für Änderungsereignisse integriert werden. Abbildung 5: Verfolgen verwandter Objekte Verfolgen verwandter Objekte Wenn Administratoren Lösungen für die Identitätsverwaltung bereitstellen, müssen sie dem Modul für den Identitätsverwaltungsfluss mitteilen können, dass es sich bei "Jeff Smith", "jsmith" und "smithj" um dieselbe Person handelt. Wie in Abbildung 5 gezeigt, muss das Modul dann in der Lage sein, die Beziehungen zu verfolgen, da die Identitätsdaten regelmäßig geändert werden. Die Lösungen dürfen die Spur eines Benutzers nicht verlieren, dessen Position in einer Verzeichnisstruktur sich ändert, weil der Benutzer beispielsweise aus der Buchhaltungsabteilung in den Vertrieb wechselt. Integritätsverwaltung Die Integritätsverwaltung stellt den Prozess dar, der sicherstellt, dass die Identitätsdaten bei Änderungen nicht beschädigt werden oder die Synchronisation zwischen den Repositories verloren geht. Die Integritätsverwaltung muss die folgenden Funktionen erfüllen können: Verwalten der Besitzrechte an Identitätsdaten. Entsprechendes Reagieren beim Auftreten von Fehlern. Aufrechterhalten der referenziellen Integrität innerhalb der Identitätsdaten. Abbildung 6: Verwalten der Besitzrechte Besitzrechte Ein wesentlicher Gesichtspunkt bei der Identitätsverwaltung von Unternehmen besteht darin, die Besitzrechte zu erkennen, die zwischen Anwendungen und Daten aufrechterhalten werden müssen. Der Postfachname einer Person befindet sich z. B. im Besitz des E-MailSystems, auf dem sich das Postfach befindet. In den meisten Firmen besitzt das Personalsystem die Rechte an den Daten im Hinblick darauf, ob es sich bei einer Person um einen aktiven Mitarbeiter handelt oder nicht. Ohne Identitätsverwaltungsinfrastruktur in einem Unternehmen bleiben diese Besitzrechte normalerweise unverändert, da andere Anwendungen nicht auf E-Mail- und Personaldaten zugreifen und diese ändern können. Mit dem Bereitstellen von Synchronisationsconnectors und Informationsflussverwaltung ändert sich jedoch die Situation. Betrachten Sie einen Fall, bei dem die Postfachinformationen über einen Connector mit dem Personalverzeichnis synchronisiert werden (siehe Abbildung 6 oben). Bei nicht einwandfrei konfiguriertem Connector kann ein Benutzer das Postfachattribut im Personalsystem ändern, und der Connector überschreibt den Postfachwert im E-Mail-Verzeichnis, was zu einer erheblichen Verwirrung führt. Die Lösung des Problems ist komplexer, als lediglich zu verhindern, dass keine Änderungen an das E-Mail-Verzeichnis gelangen. Das Personalsystem kann beispielsweise über Informationen verfügen, wie z. B der Name des Vorgesetzten einer Person, der an das E-Mail-Verzeichnis fließen muss. Andere Attribute, wie z. B. die Büronummer einer Person, verfügen möglicherweise über keinen eindeutig festgelegten Besitzer. Diese Daten sollten daher von allen aktualisiert werden können. Eine Voraussetzung für die Lösung besteht darin, dass Administratoren in der Lage sein müssen, Besitzrechte auf Attributebene festzulegen und zu erzwingen. Erfolgt eine Änderung in Übereinstimmung mit den Regeln für die Besitzrechte, wird sie durchgelassen. Ansonsten wird sie blockiert oder zurückgewiesen. Wenn beispielsweise eine Person ein Postfachattribut im Personalverzeichnis ändert, setzt die Identitätsverwaltungslösung lediglich das Attribut auf den Wert zurück, der im E-Mail-Verzeichnis enthalten ist. Fehlerverwaltung Die Möglichkeit, eine Änderung auf mehrere Repositories zu verbreiten, bildet eine Hauptanforderung von Technologien für die Identitätsflussverwaltung. Wenn ein Modul mehrere Aktualisierungen vornimmt, besteht immer die Möglichkeit, dass eine Aktualisierung fehlschlägt und die Daten in verschiedenen Repositories inkonsistent werden (siehe Abbildung 7 unten). Werden beispielsweise Titel, Gehalt und Ausgabenlimit geändert, aber das Metaverzeichnis kann den Titel des Benutzers in Anwendungen nicht aktualisieren, befinden sich die Identitätsdaten in einem ungeordneten Zustand. Normalerweise muss dann ein Administrator die Situation untersuchen und Korrekturen vornehmen. Abbildung 7: Verwalten von Fehlern und Aufrechterhalten der referenziellen Integrität In Datenbanksystemen wird diese Problematik normalerweise durch Transaktionen gelöst, um sicherzustellen, dass alle Änderungen erfolgreich durchgeführt oder insgesamt rückgängig gemacht werden. Leider unterstützen die meisten Verzeichnisdienste und Schnittstellen für Anwendungsprogrammierung keine Transaktionen. Die Lösungen für eine Identitätsverwaltung müssen daher andere Wege beschreiten, wie z. B. protokollbasierte Mechanismen, die laufend Änderungen anfordern, bis der gewünschte Zustand bestätigt wird, damit die Änderungen schließlich in allen Repositories gelten. Referenzielle Integrität Eine weitere gemeinsame Problematik von Identitätsverwaltungslösungen und Datenbanken, besteht im Aufrechterhalten der referenziellen Integrität zwischen Repositories. Die referenzielle Integrität bezieht sich auf die Notwendigkeit, Beziehungen zwischen den verwandten Datenteilen an verschiedenen Standorten aufrechtzuerhalten. Identitätsverwaltungslösungen müssen beispielsweise sicherstellen, dass der Titel einer Person im Personalsystem dem Ausgabenlimit der Person im Beschaffungssystem entspricht. Datenbanken lösen dieses Problem durch gespeicherte Prozeduren und Trigger, die es Administratoren ermöglichen, bei jeder Datenänderung eine Geschäftsregel auszuführen. Verzeichnisdienste stellen heute noch keine vergleichbaren Funktionen bereit. Aus diesem Grund müssen Identitätsverwaltungslösungen die Möglichkeit bieten, Geschäftsregeln auszuführen, die Änderungen verweigern, die den Anforderungen an die referenzielle Integrität widersprechen. Nur eine Metaverzeichnislösung löst alle diese Probleme. Die Metaverzeichnislösung Während Internet/Intranet-, proprietäre E-Mail- und andere Verzeichnisse Identitätsinformationen nur über einige Personen an einigen Stellen enthalten, kann das Metaverzeichnis Identitätsinformationen über alle Personen an allen Stellen enthalten. In einem Metaverzeichnis können Sie eine beliebige Anzahl getrennter Identitätsrepositories in nahezu jedem Format integrieren. Das Metaverzeichnis wird so zum Objektstamm für Identitätsinformationen im Unternehmen. Das Metaverzeichnis stellt eine rationalisierte und einheitliche Sicht der Identitätsobjekte bereit, die aus den Attributen vieler Verzeichnisse bestehen. Diese Integration ermöglicht die Reduzierung der Verwaltungskosten, das Ausschließen von Duplikaten sowie das Reduzieren von Widersprüchen und stellt Identitätsinformationen auf breiter Basis zur Verfügung. Das Metaverzeichnis ist flexibel genug, um sich der Organisation, Struktur, Politik und dem Stil der Geschäftsführung des Unternehmens anzupassen, und dynamisch genug, sich jeweiligen Änderungen anzupassen. Quellen Das Metaverzeichnis sammelt seine Identitätsinformationen aus den verbundenen Verzeichnissen und Repositories im Unternehmen. Fast alle E-Mail-, Datenbank- und sonstigen Verzeichnisanwendungen können ihren Inhalt in einer bestimmten Form exportieren. Das Metaverzeichnis kann diese Daten über Dateiaustausch, in einer E-MailNachricht oder über eine protokollgesteuerte Onlineübertragung erfassen. Verzeichnisadministrator oder Endbenutzer können weitere Identitätsinformationen zum Metaverzeichnis hinzufügen. Inhalt Normalerweise wird davon ausgegangen, dass Verzeichnisse Identitätsinformationen über Personen enthalten, wie z. B. E-Mail-Adressen. Diese Sichtweise ist jedoch beschränkt. Das Metaverzeichnis kann wesentlich mehr Informationen über beliebige reale Objekte enthalten. Bei den Objekten kann es sich handeln um: Physische Objekte, wie z. B. Personen oder Computer. Begriffliche Objekte, wie z. B. Organisationen oder Abteilungen. Geografische Objekte, wie z. B. Länder oder Städte. Digitale Objekte, wie z. B. Dokumentdateien für eine Onlineanzeige. Die einzige Anforderung an das Metaverzeichnis besteht darin, dass diese Objekte in irgendeiner hierarchischen Struktur angeordnet werden können. Eine Person kann beispielsweise als Bestandteil einer Abteilung beschrieben werden, die zu einer Organisation gehört, die sich in einer Internetdomäne oder einem Land befindet. In einer multinationalen Firma kann ein Mitarbeiter zu einen Geschäftsbereich in einem Land gehören, der in der Organisationsstruktur einen Bestandteil der Firma bildet. Die unterste Ebene der Hierarchie muss nicht unbedingt eine Person sein. Ein Dokument oder ein tragbarer Computer, der zu der betreffenden Person gehört, kann z. B. in der Struktur unter dem Eintrag für die Person ebenfalls durch einen Verzeichniseintrag dargestellt werden. Verwaltung Die Verwaltung der Metaverzeichnisinhalte und -sicherheit kann zentral und/oder verteilt erfolgen. Das Metaverzeichnis kann so aufgebaut werden, dass bestimmte Einträge nur in dem verbundenen Verzeichnis vorgenommen werden können und dann in das Metaverzeichnis importiert werden. Änderungen anderer Einträge können nur im Metaverzeichnis erfolgen und werden dann zum verbundenen Verzeichnis übertragen. Unterschiedliche Personen können unterschiedliche Teile des Metaverzeichnisses verwalten. Diese Steuerungsebene kann auch auf die einzelnen Attribute erweitert werden und gilt nicht nur für die Einträge selbst. Endbenutzer können daher Teile ihrer eigenen Identitätsinformationen verwalten, z. B. Telefonnummern oder Adressen. Das Metaverzeichnis zwingt zu keinem bestimmten Verwaltungsmodell. Sie können ein Verzeichnis erstellen, dessen Verwaltung den Gegebenheiten Ihrer Organisation, ihrer Sicherheits- und Zugriffssteuerungsanforderungen entspricht. Das Metaverzeichnis von Microsoft Microsoft verfügt über eine Metaverzeichnislösung, die bereits weit verbreitet verwendet wird, um schwierige Aufgaben bei der Identitätsverwaltung in Unternehmen zu erfüllen. Die Ursprünge Im Juli 1999 wurde die ZOOMIT Corporation von Microsoft erworben, die als Branchenführer für Metaverzeichnislösungen gilt. Über diesen Kauf ist Microsoft in der Lage, eine umfassende Plattform für verteilte Systeme unter Microsoft® Windows® 2000 Server bereitzustellen, die Windows-Sicherheit, den Active Directory™-Dienst und Metaverzeichnisdienste enthält. Die Metaverzeichnislösung von ZOOMIT löst die weiter oben in diesem Dokument erläuterten Probleme. Mit der Zeit wird die Metaverzeichnislösung von Microsoft, Microsoft Metadirectory Services, vollständig in verteilte Windows-Systeme integriert, so dass ein äußerst leitungsfähiges Tool für die Identitätsverwaltung zur Verfügung steht. Die geschichtliche Entwicklung Bei Microsoft Metadirectory Services handelt es sich daher um ein etabliertes Produkt mit einer langen Geschichte sowie einer ausgedehnten und vielfältigen Kundenbasis. Die ZOOMIT Corporation begann im Oktober 1996 mit der Auslieferung des Produkts ZOOMIT VIA 1.0. Abbildung 8: Zeitlicher Entwicklungsverlauf von ZOOMIT VIA Während der Übernahme durch Microsoft im August 1999 wurde eine Betaversion von ZOOMIT VIA 2.1 an mehrere Kunden ausgeliefert. Zurzeit wird ZOOMIT VIA von vielen großen Organisationen auf der ganzen Welt in komplexen und anspruchsvollen Situationen verwendet. Im restlichen Teil dieses Dokuments wird das aktuelle ZOOMIT VIA 2.1 beschrieben. Behandelt werden die grundlegenden Begriffe des Metaverzeichnisses in einer flexiblen und leistungsfähigen Architektur und die Verwendungsmöglichkeiten zur Lösung komplexer, realer Probleme der Identitätsverwaltung. ZOOMIT VIA 2.1 steht Microsoft-Kunden in einer eingeschränkten Version zur Verfügung. Diese und nachfolgende Versionen werden als Microsoft Metadirectory Services oder MMS bezeichnet. Microsoft Metadirectory Services MMS stellt eine branchenführende Lösung für Probleme der Identitätsverwaltung bereit, wie z. B. Unternehmensadressbuch und Personalbestand. Konzeptionell betrachtet besteht der Metaverzeichnisdienst aus den folgenden Komponenten: verbundenes Verzeichnis, Metaengine, Connectornamespace, Metaverse und Client (siehe Abbildung 9). Abbildung 9: Komponenten von Microsoft Metadirectory Services In dieser Abbildung bildet der Client Compass die Verwaltungsbenutzeroberfläche, die über LDAP mit dem Metaverzeichnis kommuniziert. MMS unterstützt außerdem das HTTPProtokoll, damit Endbenutzer bequem über Webbrowser zugreifen können. Die Namespaces des Metaverzeichnisses Das Metaverzeichnis ist in zwei Namespaces unterteilt. Bei dem Connectorspace handelt es sich um den Bereich, in den die Einträge des verbundenen Verzeichnisses zuerst importiert werden. Jedes verbundene Verzeichnis verfügt im Connectorspace über einen eigenen Bereich. Der Connectorspace ist eine Ansammlung spezieller Objekte, die Connectors und Disconnectors genannt werden. Diese beiden Objektklassen unterscheiden sich dadurch, dass ein Connector über ein Attribut verfügt, das den DN (Distinguished Name) des verbundenen Metaverseobjekts enthält. Bei einem Disconnector ist dieses Attribut nicht vorhanden, so dass der Disconnector im Connectorspace lediglich als Platzhalter existiert, der einen Eintrag im verbundenen Verzeichnis darstellt. Es kann einen entsprechenden Metaverseeintrag geben oder nicht. Die Connectors stellen eine Verbindung zwischen einem Objekt im Metaverse und einem Objekt im verbundenen Verzeichnis her, so dass Synchronisation und Attributübertragung möglich ist. Disconnectors blockieren eine solche Synchronisation. Objekte im Connectorspace werden in der Verzeichnisstruktur immer unter Management-Agenten angezeigt. Normalerweise sind nur wenige Attribute mit Daten gefüllt. Sie fungieren hauptsächlich als Verbindungsglied zwischen dem Metaverse und einem bestimmten verbundenen Verzeichnis. Das Metaverse bildet den Teil des Verzeichnisses, das die integrierte Sicht verknüpfter Objekte mehrerer verbundener Verzeichnisse darstellt. Der meiste Metaverseinhalt kommt von verbundenen Verzeichnissen. Es ist jedoch auch möglich, Metaverseobjekte ohne Verbindung zu einem Objekt im Connectorspace oder zu einem verbundenen Verzeichnis hinzuzufügen. Betrachten Sie den in der folgenden Abbildung dargestellten Namespace: Abbildung 10: Der Namespace In Abbildung 10 enthält das Objekt, das "John Smith" im Metaverse darstellt, Eigenschaften der Objekte, die "John Smith" in Microsoft Exchange und dem Betriebssystem Windows NT® darstellen. An einer Stelle erweiterte das Objekt, das "John Smith" in Lotus Notes darstellt, die Metaversedarstellung; dieses Objekt ist seitdem ohne Verbindung. "John Smith" gibt es in "Banyan Vines" nicht. Außerdem ist "John Smith" nicht in Mitarbeiterdaten vorhanden, die über TAMA (Together Administration Management Agent) zugänglich sind. TAMA wird weiter unten in diesem Dokument ausführlicher beschrieben. In der Abbildung 11 unten zeigen die Compass-Bildschirmabbilder die beiden Namespaces nebeneinander. Bei dem ersten handelt es sich um eine Teilansicht des Metaverse. Sie beginnt oben mit "The Known Universe" und zeigt mehrere Verzweigungen der Metaversestruktur nach unten bis zu dem Eintrag "Daniel Penn". Der letzte sichtbare Eintrag im Bildschirmabbild ist "mdserver", der den Metaverzeichnisserver darstellt. Das zweite Bildschirmabbild zeigt die Hierarchie unter dem Eintrag "mdserver" detaillierter. An dieser Stelle befinden sich die Management-Agenten und der dazugehörige Connectorspace. An dieser Stelle ist auch das Schema für das Metaverzeichnis definiert, in dem Replikationsund Zeitplaninformationen gespeichert sind und der Standardadministratoreintrag erstellt wird, der das ganze Metaverzeichnis steuert. Abbildung 11: Bildschirmabbild des Namespace In der Abbildung existieren Objekte mit der Bezeichnung "Autos" (eine Abteilung) oder "Daniel Penn" (eine Person) im Connectorspace und im Metaverse. Bei den Objekten im Connectorspace handelt es sich um Connectors, die von den dazugehörigen integrierten Metaverseobjekten durch ein spezielles Symbol unterschieden werden. Der Connectorspace für dieses verbundene Verzeichnis ist der Bereich unter dem Management-Agenten "The Humongous Insurance HR MA". Andere Management-Agenten, z. B. für das E-Mail-System, können in ihrem Connectorspace auch einen Connector für "Daniel Penn" enthalten. Das Metaverseobjekt "Daniel Penn" kann Attributinformationen aller betreffenden Quellen enthalten. Management-Agenten Das Metamodul steuert das Zusammenspiel zwischen verbundenem Verzeichnis und dem Metaverzeichnis. Es enthält alle erforderlichen Anweisungen, um das Erstellen und Löschen von Objekten sowie Integrität und Verlauf von Eigenschaften zu verwalten. Es löst die Besitzrechte von Eigenschaften bei Konflikten. Die Metamodulanweisungen sind im Metaverzeichnis als Management-Agenten implementiert. Dabei handelt es sich um spezielle Objekte, die Konfigurationsparameter, Steuerungsskripts, Transformationsregeln, Besitzrechte und Flussregeln für Attribute enthalten und definieren, wie die Integration eines verbundenen Verzeichnisses in das Metaverzeichnis erfolgt. Die MA verwalten die Beziehungen zwischen den verbundenen Verzeichnissen, dem Connectornamespace des Metaverzeichnisses und dem Metaverse auf Objekt- und Attributebene. Sie befinden sich auf dem MMS-Server und werden verzeichnisspezifisch angeschlossen. Die interne Konfiguration der MA unterscheidet sich also für jedes verbundene Verzeichnis. An dieser Stele muss betont werden, dass MMS keine Installation zusätzlicher Software auf einem der verbundenen Verzeichnisse oder anderen Systemen erfordert. Der Synchronisationszyklus Bei einem MA handelt es sich um ein Verzeichnisobjekt und einen Dienst, der die Verzeichnissynchronisation einrichtet. Er definiert, wie die Synchronisation durchgeführt wird, und er führt die Synchronisation durch. Ein Steuerungsskript steuert die drei unabhängigen Phasen des MA-Betriebs: Erkennung, Synchronisation und Aktualisierung. Diese Phasen sind in der folgenden Abbildung 12 dargestellt. Abbildung 12: Synchronisationsphasen des Management-Agenten Die Erkennungs- und Aktualisierungsphasen nutzen normalerweise Code gemeinsam, um die Bindung mit einem verbundenen Verzeichnis herzustellen und Verzeichnisinformationen zu lesen und zu schrieben. Die Synchronisationsphase bildet den eigentlichen Kern des MA. Die Synchronisationsphase verwendet Import- und Exportvorlagen sowie Attributflussregeln (die als Eigenschaften des MA-Objekts gespeichert sind), um Ausmaß und Bereich von Änderungen zu bestimmen, die in das verbundene Verzeichnis und in das Metaverzeichnis übernommen werden müssen. MMS wird mit MA für die am häufigsten anzutreffenden Arten von Identitätsinformationsrepositories bereitgestellt, wie z. B. ein LDAP-Verzeichnis, Windows NT, Microsoft Exchange, Banyan VINES, Verzeichnis von Netscape, Novell NDS und NetWare, Lotus Notes und cc:Mail. Eine optimierte Unterstützung für Active Directory wird in Kürze hinzugefügt. Normalerweise verarbeiten die mit MMS bereitgestellten MA die meisten gebräuchlichen Attribute, die zum Verzeichnis eines bestimmten Herstellers gehören. Der Lotus Notes-MA ordnet beispielsweise das Notes-Attribut "OfficeTelephoneNumber" dem LDAP-Attribut "telephoneNumber" zu, verwendet die NotesOrganisationsstruktur, um eine Standardhierarchie aufzubauen, usw. Durch Ändern der Skripts und Vorlagen können Sie auf einfache Weise die bereitgestellten MA anpassen, um geringfügige Unterschiede in der Implementierung eines verbundenen Verzeichnisses auszugleichen. Exchange-Standorte verwenden beispielsweise häufig benutzerdefinierte Exchange-Attribute, um bestimmte Informationen aufzuzeichnen, die nicht im Standardverzeichnisschema von Exchange enthalten sind. Es ist relativ einfach, einen MA so anzupassen, dass Exchange das benutzerdefinierte Attribut 1 im Metaverzeichnis als "specialTelephoneNumber" interpretiert und entsprechend verwaltet. Neue MA-Typen können anhand der Informationen im Management Agent Toolkit-Handbuch erstellt werden. Neue Quellen von Verzeichnisinformationen, von denen sich viele außerhalb des herkömmlichen Bereichs von Netzwerkbetriebssystemen und E-Mail-Verzeichnissen befinden, können in MMS integriert und von MMS verwaltet werden. Solange das Repository, z. B. eine Datenbank, Informationen in eine Datei exportieren kann, können Sie leicht einen MA erstellen, der die betreffende Datei liest sowie Repository und Metaverzeichnis synchronisiert. Verwalten sich ändernder Informationen Wenn Identitätsinformationen über eine Person (oder ein anderes Objekt) in einem oder in mehreren verbundenen Verzeichnissen und an einer oder mehreren Stellen im Metaverzeichnis existieren, stellt sich die Frage, wer diese Informationen verwaltet. Werden Änderungen sowohl im Metaverzeichnis als auch im verbundenen Verzeichnis durchgeführt, geht die Synchronisation der Objekte in kurzer Zeit verloren. MMS ermöglicht nicht nur festzulegen, wo Objekte erstellt und gelöscht werden können, sondern auch, in welchem Verzeichnis einzelne Attribute vorhandener Objekte geändert werden können. Die MA vergleichen anhand eines Zeitplans in regelmäßigen Abständen den Inhalt des verbundenen Verzeichnisses mit dem Inhalt des Metaverzeichnisses. Unterscheiden sich die Inhalte, werden sie vom MA synchronisiert. Das verbundene Verzeichnis und das Metaverzeichnis können sich auf zweierlei Weise unterscheiden: In einem Verzeichnis gibt es Objekte, die im anderen nicht vorhanden sind. Objekte, die in beiden Verzeichnissen vorhanden sind, verfügen über unterschiedliche Attributwerte. Der MA bringt diese Unterschiede miteinander in Einklang und hält die Synchronisation der beiden Verzeichnisse gemäß den eingerichteten Konfigurations- und Synchronisationsregeln aufrecht. Verwalten von Objekten Die Betriebsart des MA legt fest, wo das Erstellen und Löschen eines Metaverzeichnisobjekts verwaltet wird: entweder im verbundenen Verzeichnis (lokale Verwaltung) oder im Metaverzeichnis (zentrale Verwaltung). Wie unten in Abbildung 13 gezeigt, gibt es folgende Betriebsarten: Reflektor. Das Hinzufügen und Löschen im verbundenen Verzeichnis spiegelt sich im Namespace und Metaverse wider. Ersteller. Das Hinzufügen und Löschen im Metaverse spiegelt sich im Namespace und verbundenen Verzeichnis wider. Assoziation. Das Hinzufügen und Löschen im verbundenen Verzeichnis spiegelt sich im Namespace wider, wird aber nicht in das Metaverse übernommen. Abbildung 13: Betriebsarten der Management-Agenten Lokale Verwaltung Arbeitet der MA im Reflektormodus, spiegelt das Metaverzeichnis lediglich das Hinzufügen und Löschen wider, das im verbundenen Verzeichnis vorgenommen wurde. Beim Assoziationsmodus handelt es sich um eine spezielle Form des Reflektormodus, bei dem die beiden Verzeichnisse zwar miteinander verknüpft aber nicht integriert sind. Die Identitätsinformationen des verbundenen Verzeichnisses sind im Connectornamespace enthalten, werden aber nicht mit Objektinformationen im Metaverse zusammengeführt. Bei dem Assoziationsmodus handelt es sich in der Regel um einen Übergangsschritt zum Reflektor- oder Erstellermodus, da Sie die importierten Daten überprüfen können, bevor Sie versuchen, die Objekte des verbundenen Verzeichnisses in das Metaverse zu übernehmen. Zentrale Verwaltung Arbeitet der MA im Erstellermodus, können Objekte nur im Metaverzeichnis erstellt oder gelöscht werden. Das Hinzufügen und Löschen wird anschließend automatisch im verbundenen Verzeichnis durchgeführt. Verliert das verbundene Verzeichnis die Synchronisation mit dem Metaverzeichnis, führt der MA automatisch eine Neusynchronisation durch, indem Objekte im verbundenen Verzeichnis je nach Bedarf hinzugefügt oder gelöscht werden. Verwalten von Attributen Die MA-Betriebsarten bestimmen lediglich, wo Objekte erstellt oder gelöscht werden können. Die Attribute vorhandener Objekte können unabhängig von der MA-Betriebsart im Metaverzeichnis oder im verbundenen Verzeichnis geändert werden. Bei unterschiedlichen Attributwerten legt eine Attributflussregel fest, ob das Metaverzeichnis oder das verbundene Verzeichnis maßgebend ist. Bevor jedoch Attributflussregeln wirksam werden können, muss das Objekt in dem verbundenen Verzeichnis über den dazugehörigen Eintrag im Connectorspace mit dem Metaverseeintrag verknüpft werden. Die Verknüpfung Die Verknüpfung stellt eine Verbindung zwischen einem Metaverseobjekt und einem bestimmten Objekt im Connectorspace her. Durch die Verbindung von Metaverseobjekt und Connectorspaceobjekt stellt die Verknüpfung somit auch indirekt eine Verbindung zu dem verbundenen Verzeichnis her. Objekte können anhand von vordefinierten Verknüpfungskriterien automatisch oder interaktiv durch den Administrator verknüpft werden. Aus zweierlei Gründen sind mehrere Verknüpfungsoptionen erforderlich. Zuerst kann es verbundene Verzeichnisse geben, deren Einträge vorzugsweise nicht in einem gemeinsamen Metaverseobjekt zusammengefasst werden. Zweitens besteht möglicherweise keine sichere Möglichkeit, festzustellen, ob ein Metaverseeintrag und ein bestimmter Connectorspaceeintrag dasselbe Objekt beschreiben. Es kann in einer Organisation beispielsweise mehrere "Jeff Smith" geben, die jeweils in einem anderen verbundenen Verzeichnis dargestellt werden. Eine Person kann in den betreffenden Verzeichnissen unter mehreren Namen vorkommen, wie z. B. "Jeff Smith", "J. Smith", "Jsmith" oder "Smith, Jeff Q". Oftmals muss der Administrator eingreifen, um diese Mehrdeutigkeiten aufzulösen. In vielen Fällen gibt es jedoch solche Mehrdeutigkeiten nicht. Sie können Einträge einfach anhand des Namens oder eines anderen Attributs (beispielsweise Mitarbeiternummer) zuordnen. De facto gibt es drei verschiedene Möglichkeiten, Objekte zu verknüpfen. Mit der Verknüpfungsaktion im Compass-Client können Sie eine automatisierte Verknüpfung im Stapelbetrieb definieren, die auf vorbestimmten Verknüpfungskriterien basiert, und zu jeder gewünschten Zeit ausführen. Diese Stapelverarbeitungsverknüpfung wird normalerweise verwendet, wenn Sie ein neues verbundenes Verzeichnis in das Metaverzeichnis integrieren, eventuell im Assoziationsmodus. Ausnahmen (diejenigen Einträge im verbundenen Verzeichnis, die durch die Verknüpfungskriterien fallen) sind dabei unvermeidlich. Diese Einträge werden nicht verknüpft und bleiben Disconnectors anstatt Connectors. Sie können diese Ausnahmen anschließend mit der Anwendung Account Joiner verarbeiten, indem Sie im Metaverse nach einer Übereinstimmung suchen oder ein neues Metaverseobjekt erstellen, das dem Disconnector entspricht. Im verbundenen Verzeichnis können jedoch jederzeit neue Objekte auftreten. Unter Umständen müssen sie auch mit Metaverseobjekten verknüpft werden. Für diese Art einer ständigen Verwaltung können Sie den MA so konfigurieren, dass automatisch Verknüpfungskriterien verwendet werden, wenn ein neuer Disconnector erstellt wird (ein Objekt im Connectorspace ohne Verknüpfung). Ohne Mehrdeutigkeit kann die Verknüpfung zum Zeitpunkt der Erstellung durchgeführt werden. Wenn Sie zulassen möchten, dass Verknüpfungen automatisch durchgeführt werden, müssen Sie zuerst die Regeln, die Verknüpfungskriterien, definieren. Verknüpfungsaktion und MA-Verknüpfung bieten die Möglichkeit, die Verknüpfung auf der Benutzeroberfläche zu konfigurieren. Ein Beispiel dazu finden Sie in Abbildung 14. Abbildung 14: Konfigurieren von Verknüpfungsregeln Die Verknüpfungsaktion sucht im Connectorspace anhand der festgelegten Suchattribute jeden Disconnector und mögliche Übereinstimmungen im Metaverse. Diese Suche kann mehrere Übereinstimmungen liefern. Die Verknüpfungsaktion stellt anschließend mithilfe mehrerer Inklusionsregeln ggf. fest, ob die möglichen Verknüpfungen übernommen werden sollen. Wenn eine geeignete Übereinstimmung gefunden wird, wird automatisch eine Verbindung zwischen den beiden Einträgen hergestellt. Die Option Try to join before reflecting new entries weist einen MA im Reflektormodus an, dieselben Verknüpfungskriterien (zusätzlich zu den normalen Verfahren) zu verwenden, um ein vorhandenes passendes Metaverseobjekt zu suchen, bevor ein neues Objekt erstellt (widergespiegelt) wird. Mit dem Account Joiner andererseits können Sie interaktiv Regeln definieren und verschiedene Suchkriterien ausprobieren, bis Sie ein passendes Objekt finden oder sich entschließen, ein neues Objekt zu erstellen. Anschließend können Sie einige dieser Suchverfahren in Ihre Verknüpfungsregeln integrieren, damit solche Fälle in Zukunft automatisch verarbeitet werden. Attributflussregeln Wenn mehrere MA dasselbe Metaverseobjekt aktualisieren, müssen die dazugehörigen Attributflussregeln festlegen, welches verbundene Verzeichnis die einzelnen Attribute steuert. Andernfalls werden die Änderungen gegenseitig überschrieben. Sie müssen festlegen, welches verbundene Verzeichnis die maßgebliche Quelle für ein einzelnes Attribut darstellt. Abbildung 15: Attributfluss im Metaverzeichnis In der oben gezeigten Abbildung 15 bildet das Telefonsystem die maßgebliche Quelle für die Telefonnummer einer Person. Daher wird MMS so eingerichtet, dass lediglich das verbundene Verzeichnis des Telefonsystems die Telefonnummer ändern darf. Änderungen der Telefonnummer, die im Telefonsystem vorgenommen werden, werden mit anderen verbundenen Verzeichnissen wie Exchange und Notes synchronisiert. Versucht ein Benutzer oder Administrator in diesen verbundenen Verzeichnissen die Telefonnummer zu ändern, überschreibt der vom Telefonsystem erhaltene Wert die Änderungen. Die Festlegung des Attributflusses kann in einer einfach zu bedienenden Point & ClickOberfläche durchgeführt werden. (Siehe folgende Abbildung 16.) Abbildung 16: Festlegen des Attributflusses Sie brauchen lediglich die beteiligten Attribute auszuwählen und auf eine Schaltfläche für den Richtungsfluss zu klicken, um eine einfache Regel für den Telefonsystem-MA einzurichten: $mv.telephoneNumber = $cd.telephoneNumber Diese Aussage legt fest, dass das Attribut für die Telefonnummer im Metaverse auf das Telefonnummernattribut aus dem verbundenen Verzeichnis des Telefonsystems gesetzt wird. In dem MA für Exchange und Notes sieht die entsprechende Attributflussregel dann ungefähr so aus: $cd.telephoneNumber = $mv.telephoneNumber Diese Aussage legt fest, dass das Attribut für die Telefonnummer im verbundenen Verzeichnis auf den Wert des Telefonnummernattributs im Metaverse gesetzt wird. Mithilfe von bedingten Aussagen in erweiterten Flussskripts können Sie kompliziertere Flussregeln erstellen. Diese Steuerungsebene des Attributflusses erweitert die verteilten Verwaltungsmöglichkeiten des Metaverzeichnisses erheblich. Dadurch wird es möglich, die Identitätsinformationen an der sinnvollsten Stelle zu verwalten. Globale Informationen (z. B. Mitarbeiternummern) können zentral verwaltet werden. Lokale Informationen (z. B. Telefonnummern) können lokal verwaltet werden. Datentransformationen Die MA importieren Dateien für die Verzeichnisaktualisierung von den verbundenen Verzeichnissen und senden Aktualisierungsdateien an sie zurück. Lediglich in den einfachsten MA reicht eine direkte Attributübertragung aus. Folgende Faktoren komplizieren den Datenaustausch: Unter Umständen gibt es kein exaktes Äquivalent im Metaverzeichnis für bestimmte Attribute in verbundenen Verzeichnissen. Die Informationen des verbundenen Verzeichnisses liegen in einem anderen Format vor, als vom Metaverzeichnis benötigt wird. Möglicherweise setzen sich Attribute im Metaverzeichnis aus mehreren Attributen im verbundenen Verzeichnis zusammen (und umgekehrt). Höchstwahrscheinlich sind zusätzliche Attributinformationen für das Metaverzeichnis erforderlich, um sicherzustellen, dass das Objekt im gesamten Metaverzeichnis eindeutig ist. Das verbundene Verzeichnis kann Objekte enthalten, die nicht in das Metaverzeichnis importiert werden sollen (und umgekehrt). MA bestimmen anhand von Vorlagen, wie die Ein- und Ausgabe von Attributwerten erfolgt. Vorlagen sind in einer höheren Interpretersprache geschrieben, die das Programm Importt interpretiert und beim Importieren oder Exportieren von Metaverzeichnisdaten entsprechend berücksichtigt. Die Sprache für MA-Vorlagen bietet daher die folgenden Möglichkeiten: Durchführen einfacher direkter Änderungen von Attributen. Verwenden integrierter Funktionen zum Transformieren von Attributen. Erhalten zusätzlicher Informationen von Objekten im Metaverzeichnis. Steuern der Vorlagenausführung über bedingte Kontrollstrukturen. Definieren von Metaverzeichnisobjekten, die bei einer Verzeichnisaktualisierung einoder ausgeschlossen werden. Der linke Teil in nachstehender Tabelle 1 zeigt einen Datensatz, der mit dem cc:MailExport/Importprogramm während der Erkennungsphase für den Import in das Metaverzeichnis exportiert wurde. Auf der rechten Seite befindet sich die Analysevorlage, die den Datensatz in Attributen des verbundenen Verzeichnisses und temporären Variablen beschreibt. Sie können allgemeingültig erkennen, wie die Attributsubstitution definiert wird. Tabelle 1 Wenn Ihr Browser keine Inlineframes unterstützt, klicken Sie hier, um eine separate Seite anzuzeigen. Offensichtlich exportiert dieses verbundene Verzeichnis nur wenige Attributinformationen. Um einen vollständigen Metaverzeichniseintrag zu erstellen, sind mehr Identitätsdaten erforderlich. Benötigt werden Werte für alle Attribute, aus denen sich beispielsweise der DN (Distinguished Name) des Eintrags zusammensetzt, sowie die dazugehörige Objektklasse. Diese anderen Attribute müssen aus Identitätsinformationen in dem Eingabedatensatz und anderen dem MA bekannten Informationen aufgebaut werden. Jeder MA verfügt daher weiterhin über mehrere Konstruktionsvorlagen, die die Analysevorlagen ergänzen. Der folgende Auszug aus einer Konstruktionsvorlage gibt eine Vorstellung, wie diese Informationen erstellt werden. Tabelle 2 If $cd.zcCcLocation = P (d. h., es handelt sich um einen PostOffice-Eintrag) then $mv.zcoc = organizationalUnit (Objektklasse) $cs.zcoc = zcCcMailPostOffice,zcAliasThing,Top $mv.organizationalUnitName = $v_surname(,$v_givenName) ... else $mv.zcoc = zcPerson $cs.zcoc = zcCcMailBox,zcAliasThing,Top $mv.commonName = $get_substring("$v_givenName\ (^ $v_surname)", "", "@" ... endIf Die Kenntnis der Einzelheiten der Vorlage in Tabelle 2 sind unwesentlich, um eine Vorstellung darüber zu erhalten, wie damit die Übertragung von Attributinformationen in das und aus dem Metaverzeichnis gesteuert werden kann. Einige Informationen stammen direkt aus dem verbundenen Verzeichnis, einige von anderen Quellen. Es ist klar, dass ein Reflektor-MA, der ein neues Metaverseobjekt erstellt, dazu die Konstruktionsvorlage verwendet. Was aber, wenn ein entsprechendes Metaverseobjekt bereits vorhanden ist und mit dem Connector verknüpft wird? Was ist mit Attributflussregeln? Die Antwort lautet: Die Konstruktionsvorlagen definieren voraussichtliche oder mögliche Attributwerte, die eventuell festgelegt werden müssen. Die Attributflussregeln bestimmen die Werte, die von dem jeweiligen MA tatsächlich festgelegt werden. Die Flussregeln ergänzen so die Vorlagen. Die Konstruktionsvorlage in unserem Beispiel weist dem Attribut "Common Name" des Metaverseobjekts ("$mv.commonName") einen Wert zu, der auf Informationen aus dem verbundenen Verzeichnis basiert. Dies ist für einen neuen Metaverseeintrag notwendig. In dieser Situation kommen Attributflussregeln zur Geltung. Sie sind nicht von den Vorlagen unabhängig, sondern ergänzen sie. Bei einem Metaverseobjekt handelt es sich jedoch nicht nur um eine Ansammlung aller Attribute aller verbundenen Verzeichnisse. Im Metaverse werden den anderen Benutzern lediglich die benötigten Informationen zur Verfügung gestellt. Einfach änderbare Vorlagen und Flussregeln ermöglichen eine Selektion und Unterscheidung. Die Metaverseobjekte werden abhängig von der Verwendung des Metaverzeichnisses erstellt. Die verbundenen Verzeichnisse bleiben davon unberührt und erfüllen ihre ursprünglichen Funktionen. Das Metaverzeichnis geht über die verbundenen Verzeichnisse hinaus, ersetzt sie aber nicht (es sei denn, es ist so ausgewählt). Verwalten des Personalbestands Die Hauptfunktion eines Metaverzeichnisdienstes für Unternehmenskunden besteht in der programmgesteuerten Aktualisierung des Zugriffs auf Dienste und Ressourcen, solange ein Mitarbeiter in einer Firma beschäftigt ist. Bei der Einstellung eines Mitarbeiters muss er auf bestimmte Ressourcen zugreifen können, wie z. B. Dateien und Drucker. Der Mitarbeiter benötigt außerdem Dienste wie E-Mail. Wenn der Mitarbeiter befördert oder versetzt wird, werden möglicherweise andere Rechte und Dienste benötigt. MMS unterstützt dieses Szenario über Together Administration Management Agent (TAMA). Bei TAMA handelt es sich um einen bestimmten MA-Typ, der die Aktivitäten verschiedener anderer Standard-MA verwalten und koordinieren kann. Diese Eigenschaft ermöglicht TAMA die Steuerung mehrerer verbundener Namespaces, um sicherzustellen, dass Connectors und bei Erweiterung Konten in den verbundenen Verzeichnissen erstellt werden. Normalerweise wird die Aktivität von TAMA ausgelöst, wenn in einem bestimmten Connectornamespace neue Einträge erstellt werden. TAMA erstellt dann die entsprechenden Connectors unter verschiedenen MA, um die Konten in verschiedenen verbundenen Verzeichnissen bereitzustellen. Ein neuer Eintrag im Personalconnector kann beispielsweise dazu führen, dass ein neues Windows NT-Konto, ein Exchange-Postfach und eventuell auch eine Lotus Notes-ID erstellt wird. Mithilfe derselben Skriptsprache wie bei anderen MA ermöglicht TAMA eine sehr präzise Steuerung darüber, wann und wo diese neuen Konten erstellt werden. Wenn umgekehrt ein Mitarbeiter die Organisation verlässt (d. h. aus dem Personalsystem entfernt wird), kann TAMA sicherstellen, dass alle dazugehörigen Konten in den verbundenen Verzeichnissen aufgelöst und gelöscht werden. Inbetriebnahme der Metaverzeichnisdienste Die folgenden Beispiele zeigen den Einsatz von MMS in der Realität, um bestehende Probleme in Unternehmen zu lösen. Jedes Beispiel verdeutlicht, wie mit dem Metaverzeichnis die beiden Hauptszenarien für MMS implementiert wurden: Änderungskontrolle und Personalbestandsverwaltung. Die in den Beispielen verwendeten Firmen, sonstigen Namen und Daten sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit bestehenden Firmen, Organisationen, Produkten, Personen oder Ereignissen ist rein zufällig. Northwind Traders Bei Northwind Traders handelt es sich um mehrere große und kleine Firmen in einer weltweiten Holdinggesellschaft. Die einzelnen Firmen verwenden unterschiedliche Arten von Systemen, wie z. B. Lotus Notes, Netscape, GroupWise und Exchange. In der Metaverzeichnislösung sind diese Systeme über WAN und Internet mit dem Metaverzeichnisserver am Hauptsitz verbunden. Abbildung 17 Eine konzeptionelle Sicht von Northwind Traders Die oben gezeigte Abbildung 17 enthält eine konzeptionelle Sicht. Die einfache Darstellung zeigt jedoch nicht die tatsächliche Topologie und die politischen Implikationen bei der Verwaltung einer solchen Umgebung. In England befindet sich ein Metaverzeichnisdienst, der mehrere unterschiedliche Systeme verbindet, die in den verschiedenen Tochterfirmen von Northwind Traders eingesetzt werden. Da es sich um eine Holdinggesellschaft handelt, gibt es eine Vielzahl eigenständiger Unternehmenseinheiten, nicht nur in England, sondern auf der ganzen Welt. Die Personen, die den Metaverzeichnisdienst in England betreiben, konnten die verschiedenen System zusammenbringen und sogar in das zentrale Personalsystem integrieren. In Australien, Ägypten und mehreren anderen Ländern setzen die Tochterfirmen verschiedene E-MailProgramme wie Exchange und Notes ein, deren Attributflüsse in das Metaverzeichnis in England integriert sind. Die verbundenen Verzeichnisse werden lokal verwaltet und im Metaverzeichnis abgebildet. Der Metaverzeichnisdienst fungiert in diesem Fall als Modul für die Verzeichnissynchronisation, so dass lokale Benutzer das gesamte Firmenadressbuch anzeigen können. Nur die zentralen Administratoren greifen tatsächlich direkt auf das Metaverse zu. Mithilfe der Metaverzeichnistechnologie von Microsoft brauchte Northwind Traders vor Ort in den betreffenden Firmen und Ländern keine besonderen Fachkenntnisse bereitstellen. Die Verbindungen konnten über das Internet eingerichtet werden, so dass Northwind Traders ohne lokale Fachkenntnisse den gewünschten Informations- und Attributfluss erreichen konnte. Interessanterweise besitzt die Holdinggesellschaft ebenfalls eine amerikanische Firma, die von der Größenordnung her mit der britischen Firma vergleichbar ist. Die Amerikaner waren jedoch nicht bereit, ihre lokale Autonomie an die britische Firma abzutreten, so dass in den USA ein zweiter Metaverzeichnisdienst installiert wurde. Die folgende Abbildung 18 stellt die momentane Situation innerhalb Northwind Traders genauer dar. Abbildung 18: Eine realistischere Sicht von Northwind Traders Neben einer lokalen Verwaltung auf der Ebene der verbundenen Verzeichnisse gibt es weiterhin eine regionale Verwaltung auf der Ebene der Metaverzeichnisserver. Die beiden Server verwalten jeweils bestimmte Teile der Welt und tauschen anschließend die Informationen über die Metaverzeichnisreplikation aus, so dass jeder eine vollständige Darstellung des Firmenverzeichnisses enthält. Die Endbenutzer verfügen daher, egal ob in Kairo oder in Chicago, über ein vollständiges, genaues und stets aktuelles Adressbuch. Darüber hinaus verfügen die Administratoren im Metaverse über eine nahtlose, integrierte Sicht der gesamten Firma in ihrer ganzen Komplexität. Coast Appliances Corporation Bei der Coast Appliances Corporation handelt es sich um eine Organisation, die eine Personalbestandslösung benötigte, in der das Personalbüro Personen im Metaverzeichnis hinzufügen und bearbeiten kann. Das Metaverzeichnis sollte dann die Informationen aller Personen integrieren, deren Eigenschaften sich im Telefonsystem, im E-Mail-System, in RACF, in Zertifikatssystemen und anderen Datenspeichern in der Firma befinden. Obwohl konzeptionell betrachtet einfach, gestaltete sich dieses Projekt sehr kompliziert, da es mit den Widrigkeiten der realen Welt zu kämpfen hatte. Als die Coast Appliances Corporation mit diesem Projekt begann, gab es keine einfache Möglichkeit, eine Verknüpfung zwischen den Personalinformationen in den jeweiligen Datenquellen zu erstellen. Die Daten waren schwer zugänglich und unübersichtlich. Besonders interessant war die Tatsache, dass weniger als 65 Prozent der Personalinformationen in den Systemen zu finden waren. Diese Situation wird sogar noch interessanter, da die 65 Prozent der Personalinformationen in dem Systemen nicht übereinstimmten. 70 Prozent befanden sich im Telefonsystem, weitere 65 Prozent im Personalsystem (da eine Vielzahl von Vertragslieferanten und Personen in kleineren Personalsystemen verwaltet wurden). 40 Prozent befanden sich in RACF. Wie erfolgt nun in einer solchen Situation die Verknüpfung der Daten bei der Coast Appliances Corporation? Wenn eine Regel eingerichtet wird, dass das Attribut "Common Name" aus dem Personalsystem verwendet werden soll, werden Personen im Telefonsystem, die sich nicht im Personalsystem befinden, nicht verknüpft. Dies ist für Personen im Telefonsystem wenig beruhigend. Die Coast Appliances Corporation benötigte daher eine komplizierte Möglichkeit, die Personeninformationen zu verknüpfen. Die Firma begann mit dem Personalsystem und brachte 42.000 Mitarbeiterobjekte in das Metaverzeichnis, die als Grundlage dienen sollten. Anschließend konzentrierte sich die Coast Appliances Corporation auf das Telefonsystem, in dem 45.500 Benutzerobjekte enthalten waren. Beim Importieren der Benutzerobjekte des Telefonsystems in das Metaverzeichnis wurden 34.000 Objekte automatisch mit vorhandenen Mitarbeiterobjekten im Personalsystem verknüpft. 11.500 Objekte befanden sich jedoch nicht im Personalsystem und daher auch nicht im Metaverse. Da der MA für das Personalsystem und der MA für das Telefonsystem im Reflektormodus ausgeführt wurden, wurden 11.500 neue Personenobjekte zum Metaverse hinzugefügt. Der Telefon-MA war mit der Option Try to join before reflecting konfiguriert. Die Verknüpfungsregel war so eingerichtet, dass die Verknüpfung anhand des Common Name erfolgen sollte. Die Telefonsystemobjekte, deren Common Names mit Namen übereinstimmten, die sich bereits im Metaverse befanden (aus dem Personalsystem), wurden mit den entsprechenden Objekten verknüpft. Für die restlichen Objekte wurden anhand der Common Names im Telefonsystem neue Metaverseobjekte erstellt. Die Objekte wurden jedoch nicht einfach übernommen und zusammengeführt. Die vom Telefon-MA erzeugten neuen Objekte wurden zunächst in einem speziellen Teil der Metaverzeichnisstruktur gespeichert, wo sie untersucht, übernommen oder verworfen und schließlich an den richtigen Standort in der Organisation verschoben wurden. Abbildung 19: Metaverzeichnisverknüpfung der Coast Appliances Corporation Nach der Integration von Personal- und Telefonsystem widmete sich die Coast Appliances Corporation der RACF-Integration. Basierend auf den oben erwähnten Verknüpfungsregeln wurden 16.000 Benutzerobjekte verknüpft. Schließlich kamen 4.000 neue Einträge im Metaverse hinzu. Einige Einträge stellten Personen, andere Funktionen oder Rollen dar. Interessanterweise wurde festgestellt, dass sich 6.000 weitere Benutzerobjekte im RACFKontosystem als irrelevant herausstellten. Sie gehörten zu Benutzern, die keine Beziehungen mehr zur Coast Appliances Corporation besaßen. Viele im Rechenzentrum aktive Jobs wurden noch immer unter den Berechtigungen von Benutzern ausgeführt, die die Organisation bereits verlassen hatten. So konnte aufgrund eines Rationalisierungsvorgangs, der alle diese irrelevanten und ungenutzten Konten untersuchte, ein Teil der Mainframekapazität zurückgewonnen werden. Der Vorgang ist oben in Abbildung 19 dargestellt. Nach Abschluss der Integration der Identitätsinformationen dieser drei Systeme konnte die Coast Appliances Corporation 49.500 Identitätsobjekte rationalisieren. Anschließend wurden die anderen Systeme in Angriff genommen und die Daten nacheinander konsolidiert. Am Ende dieses Vorgangs hatte die Coast Appliances Corporation die gesamten Identitätsinformationen integriert, wobei ein erheblicher Umfang falscher Informationen in allen drei Systemen gefunden wurde. Darüber hinaus wurde festgestellt, dass einige Identitätsinformationen weder von den verwaltenden Personen noch von den referenzierten Personen kontrolliert wurden. Offensichtlich stellt die Verknüpfung von Identitätsinformationen isolierter Datenquellen in einem großen Unternehmen nicht immer eine einfache Aufgabe dar. Metaverzeichnisdienste können jedoch einen Großteil der Arbeit automatisieren und Probleme sowie Inkonsistenzen aufzeigen. Allein die Installation einer Metaverzeichnislösung bedingt Vorteile und Kosteneinsparungen, da fehlerhafte Informationen bereinigt und rationalisiert werden können. Nach der vollständigen Implementierung sorgt der Metaverzeichnisdienst für weitere laufende Einsparungen und stellt eine zuverlässige, integrierte Identitätsbasis bereit, auf der andere Initiativen und Anwendungen aufbauen können. Die Coast Appliances Corporation nutzte das Metaverzeichnis beispielsweise dazu, für alle Mitarbeiter zentral eindeutige IDs zu erzeugen und dieses Attribut mit Zustimmung der lokalen Administratoren in die verbundenen Verzeichnisse aufzunehmen. Ein solches Programm wäre ohne Metaverzeichnis nicht zu verwalten, wenn nicht gar undenkbar gewesen. Metadirectory Services erweitern Active Directory Microsoft verfolgt das Ziel, Active Directory um Metaverzeichnisdienste zu erweitern und eine umfassende Plattform für verteilte Systeme bereitzustellen. Viele Windows 2000basierte Anwendungen sind Active Directory-fähig. Die Endbenutzer können mithilfe der standortbasierten Druckfunktion den nächstgelegenen Drucker suchen. Anwendungen und Dienstrichtlinien können in Active Directory zentral verwaltet und anschließend zu einer Gruppe von Endbenutzern gedownloadet werden. In zukünftigen Versionen von Exchange wird das Exchange-Verzeichnis durch Active Directory ersetzt. Das DNS (Domain Name System) von Microsoft ist eng in Active Directory integriert. Hierbei handelt es sich lediglich um einige der wichtigsten Integrationsaspekte, deren Vorteile die Unternehmenskunden von Microsoft bei Active Directory nutzen können. Die Microsoft Metadirectory Services erweitern Active Directory durch Dienste wie: Synchronisation mehrerer verbundener Verzeichnisse in einem zentral verwalteten, sternförmig aufgebauten Modell. Programmgesteuerte Verknüpfung mehrerer Sichten eines Objekts in einer einheitlichen Sicht. Obwohl die Erwartung unrealistisch ist, dass die Identitätsinformationen eines Unternehmens immer programmgesteuert verknüpft werden können, vereinfacht die Flexibilität von MMS, die Sicht von Identitätsinformationen zu vereinheitlichen, diesen wesentlichen Schritt erheblich. Festlegen eines verbundenen Verzeichnisses als maßgebliche Quelle für ein Attribut. Integration in die Geschäftsvorgänge, da die Personalbestandsverwaltung unterstützt wird. Eine einfache und flexible Umgebung, in der kurze Skripts zur Anpassung an die Umgebung eines Unternehmens hinzugefügt werden können. Zukünftige Versionen von MMS werden weiter in Active Directory integriert und gleichzeitig erweitert, um die Situation der jeweiligen Kunden berücksichtigen zu können. Die zukünftige Integration in Active Directory soll enthalten: Einen optimierten Active Directory Management Agent, der die Vorteile des erweiterten Active Directory-Replikationsprotokolls nutzt, um Änderungen zu erkennen und diese Änderungen direkt in Active Directory zu kopieren. Active Directory kann somit als primärer Verwaltungspunkt für Metaverseobjekte verwendet werden. Jeglicher autorisierter Zugriff auf die Metaverzeichnisnamespaces verwendet Active Directory zur Authentifizierung. Integration des Gateway Service für NetWare von Microsoft. Integration in Windows 2000 Server. Die Kombination von Active Directory und MMS bildet eine unabdingbare Lösung für eine verteilte Systemplattform in Unternehmenskonten. Microsoft Metadirectory Services erweitern die verteilten Windows Server-Systeme von Microsoft in vielfältiger Hinsicht. Zusammenfassung Die Verwaltung von Identitätsdaten in einem modernen Unternehmensnetzwerk bringt viele Probleme mit sich. Die Identitätsdaten liegen in unterschiedlichen Formen vor und sind auf mehrere Repositories verstreut. Ein Metaverzeichnis sammelt alle Identitätsdaten an einer Stelle und stellt Tools zur Verwaltung der Daten bereit, unabhängig von dem jeweiligen Format. Ein Metaverzeichnis ermöglicht es einem Unternehmen, die Verwaltungskosten zu reduzieren, doppelte Daten zu vermeiden, verschwendete Netzwerkkapazität zurückzugewinnen, Widersprüche in den Daten aufzulösen und die Identitätsdaten passend zur Verfügung zu stellen. Microsoft Metadirectory Services, die aus ZOOMIT VIA entstanden sind, stellen die branchenführende Lösung für die Schwierigkeiten bei der Identitätsverwaltung bereit, mit denen moderne Unternehmen konfrontiert sind. Sie ermöglichen es einem geografisch verstreuten Unternehmen, Daten auf lokaler Ebene oder an einem zentralen Standort zu verwalten. Ein Unternehmen kann sich auch für eine Kombination aus zentraler und lokaler Verwaltung entscheiden. Das Metaverzeichnis ist in der Lage, genaue, immer aktuelle Informationen über Mitarbeiter sowie Adressen, Telefonnummern, E-Mail-Adressen, Abteilungsbezeichnungen und Dokumentdateien zur Verfügung zu stellen. Die neuesten Informationen zu Windows 2000 Server finden Sie im Microsoft TechNet oder in unserer Website unter http://www.microsoft.com/GERMANY/windows2000/produktinfos/server/default.htm bzw. http://www.microsoft.com/windows/server (englischsprachig) sowie im Windows NT ServerForum in MSN™ unter http://computingcentral.msn.com/topics/windowsnt (englischsprachig). © 2000 Microsoft Corporation. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren. Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT. Microsoft, Active Desktop, das BackOffice-Logo, Windows und Windows NT sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Tatsächliche in diesem Dokument aufgeführte Produkt- und Firmennamen sind möglicherweise Marken der jeweiligen Eigentümer. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 0100