Jason Jocobo Produktmanager

Niemand verschiebt eine Active-Directory-Migration, weil das Kopieren von Objekten schwierig ist.

Fragen Sie ein beliebiges Identitätsmanagement-Team in einem Unternehmen, warum die vor drei Jahren geplante Konsolidierung der Domänenforests immer noch nicht stattgefunden hat. Sie werden wahrscheinlich nicht zu hören bekommen, dass die Tools die Objekte nicht verschieben konnten.

Sie werden noch etwas anderes erfahren: Niemand konnte mit Sicherheit sagen, was kaputtgehen würde.

So sieht die tatsächliche Situation bei der Active-Directory-Migration heute aus. Es handelt sich um Projekte mit Tausenden von Benutzern, Zehntausenden von Gruppen, Berechtigungen, die seit der letzten Umstrukturierung von niemandem mehr überprüft wurden, und Anwendungen, die eng mit einem Verzeichnis verknüpft sind, in dem sich seit 20 Jahren Entscheidungen angesammelt haben.

Das Risiko liegt nicht in dem Kopiervorgang selbst. Das Risiko liegt in allem, womit der Kopiervorgang in Berührung kommt.

So werden die Projekte zunächst zurückgestellt. Dann verzögern sie sich. Und schließlich werden sie oft genug gestrichen – während die Organisation weiterhin ein Verzeichnis betreibt, von dem sie bereits weiß, dass es eine Belastung darstellt.

Inzwischen hat sich das Umfeld, in dem diese Entscheidung getroffen wurde, grundlegend verändert. Das Duplizieren von Gruppen, Trusts, Benutzern und Passwörtern sowie die Übertragung der SID-Historie über eine Grenze hinweg war schon immer mit Risiken verbunden. Dies in der heutigen Bedrohungslandschaft zu tun, ist jedoch eine grundlegend andere Herausforderung als noch im Jahr 1999.

Active Directory ist bei den meisten Angriffen auf Unternehmensnetzwerke der primäre Angriffsvektor, und ein Migrationsfenster ist ein Zeitraum, in dem Vertrauensbeziehungen bestehen, Dienstkonten mit erweiterten Berechtigungen ausgeführt werden und Objekte zwischen zwei Umgebungen übertragen werden.

Identität ist die Steuerungsebene für Zugriff, Vertrauenswürdigkeit und Geschäftskontinuität. Sie verdient mehr Beachtung, Kontrolle und Transparenz als die meisten Änderungen an der Infrastruktur.


Migration ist keine Datenübertragung. Es handelt sich um ein Ereignis im Bereich der Identitätssicherheit.

Dies ist die Prämisse, auf der Semperis Migrator 2.0 basiert, und es lohnt sich, dies klar und deutlich zu betonen: Jedes Objekt, das Sie migrieren, stellt das Überschreiten einer Vertrauensgrenze dar.

Migrationswerkzeuge werden in der Regel anhand des Durchsatzes gemessen: wie viele Objekte, wie schnell. Auch „Migrator“ verschiebt Objekte schnell. Doch der Objektdurchsatz war nie der Grund dafür, dass diese Projekte drei Jahre dauerten.

Was den Kalender ausfüllt, sind Nacharbeiten. Eine Synchronisation, die zu einem unerwarteten Ergebnis führte, und die zwei Wochen, die damit verbracht wurden, dies wieder in Ordnung zu bringen. Ein Umstellungswochenende, das verschoben werden musste, weil am Freitag eine Abhängigkeit zutage trat. Vier Stunden an einem Samstagabend, die damit verbracht wurden, herauszufinden, welche von elf Komponenten den Fehler protokolliert hatte. Eine Warteschlange für die Neuinstallation von Systemen auf Rechnern, die gar nicht erst neu aufgesetzt werden mussten.

Migrationen laufen selten langsam ab. Sie kommen zum Stillstand. Und dann beginnen sie von Neuem. Das Problem liegt also nicht darin, wie schnell die Engine läuft, sondern darin, wie viel Zeit Sie damit verbringen, das Programm nicht zu migrieren.

Migrator 2.0 basiert auf drei Fragen.

  • Können Sie erkennen, was sich ändern wird, noch bevor es sich ändert?
  • Ist es möglich, Endpunkte im Batch-Maßstab zu verschieben, ohne sie physisch zu berühren?
  • Wenn etwas nicht funktioniert, können Sie den Fehler innerhalb weniger Minuten finden?

Kontrolle ist hier nicht der Preis, den Sie für Sicherheit zahlen; sie ist vielmehr das, was das Projekt am Laufen hält.


Vier Probleme und wie Migrator 2.0 diese löst

Im Folgenden finden Sie einige der kritischen Fehlerquellen bei der AD-Migration, die Semperis behebt.


Sie können nicht vorhersagen, was eine Synchronisierung tatsächlich bewirken wird.

Bei den meisten Werkzeugsystemen hängt das Ergebnis eines Synchronisierungslaufs von der Erfahrung des Bedieners und von der Hoffnung ab.

Migrator 2.0 führt einen Staging-Bericht ein: eine vollständige Vorschau der erwarteten Änderungen, die anhand der Live-Zielumgebung validiert wird, bevor irgendetwas festgeschrieben wird.

Was diesen Vorgang von einem bloßen Testlauf unterscheidet, ist die Tatsache, dass Ihre Attributbearbeitungen dabei ausgewertet werden. Wenn Sie Regeln zum Umschreiben eines UPN-Suffixes, zum Verketten von Werten oder zum Anwenden bedingter Logik geschrieben haben, zeigt Ihnen der Staging-Bericht die resultierenden Werte an – nicht die Regel selbst, sondern die Ausgabe. Passen Sie die Transformation an , führen Sie das Staging erneut durch und sehen Sie sich das neue Ergebnis an. Sie wiederholen diesen Vorgang so lange, bis die Vorschau Ihren Vorstellungen entspricht, und führen die Änderung erst dann endgültig durch.

Dadurch entfällt der kostspieligste Schritt in einem Migrationsprogramm: die nachträgliche Feststellung und die erneute Durchführung der gesamten Migrationswelle.

Die Synchronisierung selbst ist nun in Verzeichnissynchronisierungssätzenorganisiert – projektbezogene Container, die eine Quelle, ein Ziel, Import- und Geltungsbereichseinstellungen, die Attributauswahl, die Ausführung sowie die Ergebnisse als einen einzigen kontrollierten Arbeitsablauf enthalten. Teams, die mehrere parallele Arbeitsabläufe betreiben, profitieren von einer echten Trennung statt einer einzigen globalen Konfiguration, an die sich niemand heranwagen möchte. Szenarien mit mehreren Domänen, mehreren Forests und einer einzelnen Domäne werden alle über dieselbe Benutzeroberfläche abgewickelt. Attributtransformationen – das Umschreiben von UPN-Suffixen, Zuordnungen sowie bedingte und formelbasierte Regeln – werden direkt im Produkt konfiguriert und nicht in einem Haufen benutzerdefinierter Skripte, für die nach dem Weggang der Berater niemand mehr die Verantwortung übernehmen möchte.


An den Endpunkten scheitern Migrationen tatsächlich.

Die Objekte sind der einfache Teil. Die Fehler, die zu Helpdesk-Tickets führen, treten am Arbeitsplatzrechner und auf dem Dateiserver auf: eine fehlerhafte Zugriffsberechtigung (ACL), ein nicht mehr vorhandener Drucker, ein Dienstkonto, das sich nicht mehr authentifizieren lässt, oder ein Profil, das nicht mit dem Benutzer mitübertragen wurde.

Der „Secure Access and Control Agent“ von Migrator wickelt die Umstellung vor Ort ab. Es ist kein Neuaufbau von Computerobjekten, kein Reimaging und keine Warteschlange von Computern erforderlich, die auf ein Desktop-Team warten. Die Endgeräte werden in Migrationsgruppen organisiert und in Wellen verschoben, deren Größe auf Unternehmenschargen abgestimmt ist. Dadurch kann das Programm kontinuierlich ablaufen, anstatt sich hinter einer Reihe von Umstellungswochenenden anzustauen.


Koexistenz ist der Standardbetriebsmodus, kein Ausnahmefall.

Kaum eine Unternehmensmigration erfolgt heute noch im „Big-Bang“-Verfahren. Tatsächliche Projekte werden in Phasen über mehrere Monate hinweg durchgeführt, wobei sowohl die Quell- als auch die Zielumgebung in Betrieb sind und die Nutzer auf beide verteilt sind.

Migrator Version 2.0 behandelt dies als den Normalfall : Synchronisationsabläufe werden in Zeitfenster eingeplant, die sich am Geschäftsbetrieb orientieren, die einzelnen Wellen werden in kontrollierten Schritten ausgeführt, und die Bediener können den Vorgang je nach den aktuellen Ergebnissen unterbrechen, Korrekturen vornehmen und fortsetzen. Ein Problem in einer Welle kostet Sie lediglich diese eine Welle – nicht jedoch ein Rollback aller Instanzen und einen Neustart des Programms.


Wenn um 23:00 Uhr etwas ausfällt, ist man in der Regel auf nichts vorbereitet.

Verteilte Systeme weisen verteilte Fehler auf, und die erste Stunde eines jeden nächtlichen Umstellungsvorfalls wird in der Regel damit verbracht, herauszufinden, welche Komponente betroffen ist.

Migrator 2.0 fasst Protokolle von Agenten, Diensten, der Webkonsole, der Datenbank und der Infrastruktur in einer einzigen durchsuchbaren Oberfläche zusammen und bietet dabei Korrelations-IDs, die verwandte Einträge komponentenübergreifend verknüpfen, sowie Filter nach Schweregrad, Volltext- und Mustersuche sowie Exportfunktionen.

Das ist der Unterschied zwischen einer Triage, die in Stunden gemessen wird, und einer Triage, die in Minuten gemessen wird.

Die Bereitstellungsvalidierung überprüft die Netzwerkverbindung, Zertifikate, DNS und den Betriebszustand der Dienste, bevor eine Einführung beginnt, sodass die Hindernisse, die normalerweise erst während der Migration auftreten, stattdessen bereits während der Einrichtung erkannt werden.


Und das alles begleitet von einer Live-Fortschrittsanzeige.

Objektzahlen nach Bundesstaat, Erfolgs- und Fehlerquoten nach Objekttyp, Durchsatz, verstrichene Zeit, eine durchsuchbare Liste fehlgeschlagener Objekte mit Fehlerdetails und Wiederholungsversuchen sowie SID-Verlauf und Ergebnisse der Passwortsynchronisierung. Während des risikoreichsten Zeitfensters des Projekts sollte die Beantwortung der Frage „Wo stehen wir gerade?“ nur wenige Sekunden dauern und keinen Anruf beim Support erfordern.

All dies geht nicht zu Lasten der Geschwindigkeit. Genau darin liegt der Ursprung der Geschwindigkeit: weniger Wiederholungsläufe, keine Warteschlange für die Neuabbildung, kontinuierlich fortschreitende Wellen und innerhalb von Minuten erkannte Fehler.

Derselbe Ansatz gilt auch zu Beginn eines Projekts: Eine optimierte, wiederholbare Bereitstellung verkürzt die Zeitspanne zwischen der Vertragsunterzeichnung und dem ersten migrierten Objekt. Migrator läuft auf einem vom Kunden verwalteten Kubernetes-Cluster, sei es in der Cloud oder vor Ort.


Wo die AD-Migration im Gesamtkontext einzuordnen ist…

Die Migration ist ein heikler Punkt im Lebenszyklus einer Identität, nicht deren Ende. Umgebungen befinden sich im Wandel, Berechtigungen können sich verschieben, und es entstehen Lücken in der Transparenz.

Aus diesem Grund betrachtet Semperis die Migration als Teil eines sicherheitsorientierten Modells und nicht als eigenständiges Ereignis. Dadurch werden Sicherheitsrisiken bereits vor der Migration minimiert, der stabile Betrieb während der Umstellung gewährleistet und anschließend eine stärkere Sicherheitslage in der Zielumgebung gefördert.

Die Aufgabe des Migrators in diesem Modell liegt in der Mitte: Identität und Zugriff in kontrollierten Schritten weiterzuentwickeln, jede Änderung bewusst und nachvollziehbar zu gestalten und das Ziel in einem von Ihnen gewählten Zustand zu hinterlassen – und nicht in einem, den Sie übernommen haben.

Die Funktionen der Semperis-Plattform– sowie die in unserer Roadmap vorgesehenen detaillierteren Erkenntnisse zu Migrationsrisiken – sorgen dafür, dass die Phasen davor und danach ebenso sorgfältig geplant sind.

Identität ist kein statisches Konstrukt. Sie verändert sich, wenn Unternehmen fusionieren, Geschäftsbereiche veräußern, sich modernisieren und ihre Sicherheit verstärken. Mobilität ist Teil dieses Lebenszyklus und sollte wiederholbar sein, anstatt nur alle zehn Jahre als Notfallmaßnahme zu dienen.


…und wo Migrator für Sie die richtige Wahl ist

Migrator for Active Directory ist konzipiert für:

  • Migration, Konsolidierung und Modernisierung von AD zu AD
  • Integration und Veräußerung im Rahmen von Fusionen und Übernahmen
  • Konsolidierung über mehrere Domänen und Forests hinweg
  • Modernisierung und Umstrukturierung des Geschäftsbereichs
  • Sicherheitsorientierte Neuinstallationen
  • Umstellung in den Filialen oder bei den Mitarbeitern im Homeoffice

Möchten Sie erfahren, wie „ Migrator for Active Directory “ 2.0 Ihren Teams dabei helfen wird, die Migration mit größerer Sicherheit zu planen, durchzuführen und zu überwachen? Fordern Sie eine individuelle Demo an.


Weiterführende Literatur (sofern zutreffend)