Metadirectory

Wir können und bei Net at Work natürlich mit Microsoft Technologien (Windows Server, Active Directory, ILM (früher MIIS) etc. bestens aus. Wir sind aber bei Kunden aktiv, bei denen es keine homogene Microsoft Welt gibt. Es ist eher eine Koexistenz verschiedener Systeme, die wir vorfinden und die von den Kunden oder anderen Dienstleistern betrieben werden.

Ziele

Ziele wie "Einfache Verwaltung", "Kosteneinsparung", Sicherheit" etc. sorgen aber dafür, dass dein paralleler Betrieb von Systemen ohne Verbindungen nicht sinnvoll ist. Es gibt sehr viele Möglichkeiten, heterogene Umgebungen zu "verbinden. Das geht in beide Richtungen wie z.B. ein "SAMBA"-Server als SMB-Dateiserver genauso zeigt wie ein Active Directory, welches per NIS, LDAP, Kerberos, RADIUS seine Dienste auch anderen Plattformen bereit stellt. Ziele könnten daher sein:

  • Konsistente Daten in verschiedenen Verzeichnissen
  • Vereinfachte und kostengünstige Verwaltung
  • "SelfService" der Mitarbeiter
  • Unternehmensweites Adressbuch über mehrere Systeme hinweg
  • Einbindung von Partnern
  • Einheitliche Authentifizierung und Autorisierung.
  • Passwordmanagement
  • Change Management
  • Auditing
  • Einbindung unterschiedlicher Clients und Systeme
  • Single Sign On

Letztlich gilt es die Anforderungen aufzunehmen und wenn ein zentraler Verzeichnisdienst nicht alle Dienste bereit stellen kann, dann wird es mehrere Verzeichnisdienste geben, die für ihren Fachbereich die Funktion erfüllen kann. Dann steht das Thema eines Verzeichnisabgleich an, d.h. die teilweise redundant vorgehaltenen Daten müssen synchronisiert werden.

1:1 oder 1:n

Wenn nur zwei Verzeichnisdienste zu bedienen sind, dann kann ein relativ einfacher Prozess zwischen den Verzeichnissen ausreichen. Solch eine Aufgabenstellung finden wir oft zwischen Mailsystemen vor, wo Empfänger eines Systems auf der anderen Seite als "Kontakt" im Adressbuch erscheinen sollen. Entsprechende Beschreibungen finden Sie auf Verbinden von Organisationen.

Entsprechende Lösungen haben wir schon mit einem einfachen VBScript (Siehe MiniSync) realisiert. Damit ist es sehr schnell möglich, z.B. die Adressdaten eines anderen Verzeichnisdienstes  per LDAP regelmäßig auszulesen und die Felder im Active Directory (z.B. Ort, Telefon, Straße, Abteilung etc.) zu schreiben.

Kommen aber mehr Verzeichnisdienste zum Tragen, dann ist es eine gute Praxis, einen zentralen Clearingpoint aufzusetzen, an den alle anderen Dienste als 1:1 Anbindung angekoppelt werden (Siehe MIIS, IIFP, ILM2007)

 

Der zentrale Knoten wird dabei als "Metadirectory" bezeichnet, welcher alle Daten konsolidiert und je nach Einstellung zu den verschiedenen verbundenen Verzeichnisdiensten abgleicht und Format umsetzt. Ohne zentrale Clearingstelle wird ein Verzeichnisabgleich sehr schnell komplex, wenn drei oder mehr Dienste miteinander verbunden werden sollen. Ein zusätzlicher Dienst ist dabei das kleinere Übel. Wobei durchaus überlegt werden kann, ob ein bestehender Dienst leistungsfähig genug ist, um neben seiner bisherigen Aufgabe auch als Mittelpunkt für andere Dienste zu dienen. In vielen Firmen ist das Active Directory "sowieso" da und durchaus als stabiler, leistungsfähiger und erweiterbarer Dienst anzusehen.

Wenn Informationen nicht erst verteilt und repliziert werden müssen, sondern direkt von einer gemeinsamen Quelle genutzt werden, die über alle erforderlichen Protokolle erreichbar ist, dann sparen Sie sich viel Komplexität. Allerdings muss das zentrale Verzeichnis dann natürlich professionell betrieben werden.

Authentifizierung, Autorisierung und Kennwort

Wenn die verschiedenen Verzeichnisdienste auch "Anmeldefunktion" für ihre Bereiche übernehmen, dann ist ein Abgleich der Kennwort wünschenswert. Eine Änderung des Kennworts in einem System sollte auch in den anderen Diensten sofort oder nach kurzer Zeit aktiv werden. Dies ist nicht immer einfach, da dazu das Kennwort bei einigen Diensten nur irreversibel verschlüsselt als Hash gespeichert wird und damit nicht abgeglichen werden kann, wenn unterschiedliche Verfahren zum Einsatz kommen. Dann müsste das Kennwort zum Abgleich quasi beim ändern "abgefangen" werden. Alternativ könnten alle KennwortÄnderungen auf den untergeordneten Diensten verboten werden, so dass die Anwender z.B. per Webbrowser ihr Kennwort auf dem Metadirectory ändern müssen. Damit wäre eine Replikation einfacher möglich, wobei Zeitverzögerungen und z.B. Unterschiedliche Kennwortrichtlinien diesen Prozess erschweren. Daher ist genau zu prüfen, ob wirklich verschiedene Anmeldedienste erforderlich sind, oder nicht ein Verzeichnis für die Anmeldung aller Clients zuständig ist.

Systemnahe und produktspezifische Einstellungen

Die Verwaltung produktspezifischer und systemnaher Einstellungen muss ebenfalls berücksichtigt werden. Wenn ein zentrales Metadirectory aufgebaut wird, ist zu prüfen, ob dieses auch alle EinstellMöglichkeiten aller verbundenen Systeme bereitstellen muss.

So könnte es ja denkbar sein, dass das Metadirectory "nur" die Personendaten und Gruppen bereit stellt, aber z.B. AD-Spezifische Einstellungen (Anmeldezeiten, Sicherheitsgruppen, Exchange Konfiguration etc.) oder Unix-Einstellungen (UID, GID, Homedirectory) werden weiterhin dezentral gepflegt.

Eine zentrale Pfleg erfordert natürlich auch eine entsprechende Verwaltungskonsole für das Metadirectory während bei der dezentralen Pflege zwar weniger Aufwand ansteht, aber ein neuer Benutzer im Metadirectory dann nur "halb fertig" im untergeordneten Verzeichnis angelegt wird.

Am Beispiel Exchange lässt sich das gut erklären. Die Exchange Management Console setzt beim Anlegen einer Mailbox verschiedene Werte im Active Directory (LDAP). Die Details sind aber nur bedingt offen gelegt, so dass eine vergleichbare Aktion per Replikation von einem anderen Metadirectory diese Logik nachbauen muss. Entsprechend sind Konflikte möglich. Ein solches System muss also damit umgehen können, dass eine Änderung im Metadirectory nicht in allen Systemen erfolgreich möglich ist bzw. Abhängigkeiten beachtet werden müssen.

Die Themen "Provisioning" und "Benachrichtigungen" sind also entsprechend zu definieren. Teilweise sollen Metadirectories sogar komplette Arbeitsabläufe (Workflows) abbilden, wobei dies eher eine Frage der verwendeten Provisioning-Anwendung ist. Solche Dinge lassen den Aufwand förmlich explodieren, denn "Standards" gibt es in der Umgebung nicht. Wenn ihre Aufgabenstellung "kleiner" ist, könnte die Einigung auf einen vorhandenen Verzeichnisdienst mit Kompromissen sogar schneller, einfacher und günstiger sein als eine große Lösung.

Partner und Dienstleister

Auch wenn wir als Net at Work "Microsoft orientiert" sind, so zeigen die größeren Projekte, dass immer mehrere Parteien involviert werden. für jeden Bereich brauchen Sie einen passenden Ansprechpartner, welcher sehr gut die internen Strukturen und Felder der verschiedenen Dienste kennt und wie diese gesetzt werden.

Unsere Praxiserfahrungen reichen dabei von der Verbindung von Firmen miteinander (E-Mail Adress-Abgleich) über den Einsatz von IIFP (die Light-Version von MIIS) bis zur Unterstützung der Exchange Migration (2003-2007) einer großen MIIS-Installation, bei der die Masterdaten aus einem SAP-HR-System kommen, in MIIS übertragen und von dort dann das Active Directory, Branchenanwendungen und bis zum Zugangskontrollsystem ausgerollt werden. Eine zeit lang hat MIIS z.B. kein Exchange 2007 unterstützt. Hier konnten wir dann mit E2K7:RUS eine Zwischenlösung schaffen. Insofern kann es auch trotz unseres Microsoft Backgrounds interessant sein, ein Konzeptgespräch zu führen

Weitere Links