Mike Masciulli Geschäftsführer, Migrationsprodukte und -dienstleistungen

Ihre AD-Migration hat Ihre Sicherheit nicht erhöht. In vielen Umgebungen bewirkt sie sogar das Gegenteil.

„Woher wissen Sie das?“

Das ist die unangenehme Frage, auf die ich immer wieder zurückkomme, wenn ich mit Unternehmen spreche, die Fusionen, Cloud-Umstellungen und Modernisierungsprojekte planen.

Allzu oft geben Unternehmen Millionen für ein Migrations- und Konsolidierungsprojekt für Active Directory (AD) aus und behandeln es wie einen einfachen Datenumzug: Sie übertragen Benutzer, Gruppen und Anwendungen in eine neue Gesamtstruktur, erklären das Projekt für erfolgreich und gehen davon aus, dass der schwierige Teil damit erledigt ist.

Wenn Sie jedoch dieselben Fehler bei der Delegierung, der Verschachtelung von Gruppen, den Vertrauensbeziehungen und den Konten mit übermäßigen Berechtigungen mitnehmen, können Sie dieselben Angriffspfade in einer neuen Umgebung nachbilden – und diese manchmal sogar noch schwerer aufspürbar machen. Eine saubere Umstellung bedeutet nicht automatisch eine saubere Sicherheitslage.

Hier sind elf häufige Risiken, die mir bei typischen AD-Migrationen auffallen. Wenn Sie bei der AD-Migration einen sicherheitsorientierten Ansatz verfolgen, können Sie Sicherheitslücken aus dem Altsystem reduzieren, anstatt sie mit in die neue Umgebung zu übertragen.


1. Vererbte Administratorrechte

Eine AD-Migration kann zu einem Motor für die Ausweitung von Berechtigungen werden, wenn alte Domain-Admin- oder Enterprise-Admin-Rechte ohne Überprüfung in die Zielumgebung übertragen werden. Was wie Kontinuität aussieht, ist in Wirklichkeit die Übertragung alter administrativer Fehler in eine neue Umgebung, die eigentlich auf aktuellen Sicherheitspraktiken hätte aufbauen sollen.

Ich habe erlebt, dass bei Migrationen jahrzehntealte Privilegienstrukturen erhalten blieben. Wenn alte Privilegien fortbestehen, bleiben auch die damit verbundenen Risiken bestehen.


2. Alte Angriffspfade wurden nachgestellt

Wenn Sie die Verschachtelung von Gruppen, die Delegierung und die Koexistenz-Shortcuts beibehalten, ohne die Berechtigungsbeziehungen vor der Umstellung zu analysieren, können Angreifer weiterhin dieselben Wege für die laterale Bewegung nutzen, die ihnen bereits zur Verfügung standen. Die Migration mag zwar betrieblich nahtlos verlaufen, doch aus Sicherheitssicht besteht derselbe Angriffspfad weiterhin.

In manchen Fällen führt die Migration zu einer noch gefährlicheren Situation: einer Brücke von einer kompromittierten Quellumgebung in die Zielumgebung. Was Sie während der Migration nicht überprüfen, wird später oft zum Problem für andere.


3. Offenlegung von Anmeldedaten während der Migration

Migrationsfenster sind unbeständig. Anmeldedaten werden gemeinsam genutzt, Vertrauensbeziehungen werden hinzugefügt, die Synchronisierung wird ausgeweitet, und legitime Änderungen verursachen so viel Unruhe, dass böswillige Aktivitäten in aller Öffentlichkeit verborgen bleiben.

Im April 2026 änderte Microsoft die Standardkonfiguration des Kerberos-KDC dahingehend, dass für Konten ohne explizite Verschlüsselungseinstellungen AES bevorzugt wird. Diese Umstellung kann dazu führen, dass RC4-abhängige Dienstkonten während der Koexistenz nicht mehr funktionieren, wenn die Teams diese Abhängigkeiten nicht im Voraus erkannt haben. Wie in meinem Beitrag „RC4 und AD-Migration: Entdecken Sie die in Ihrer Quelldomäne verborgenen Ausfallszenarien“ erläutert wird, sind Migrationsprojekte in besonderer Weise gefährdet, da Standardtools ein Konto zwar verschieben, dessen Verschlüsselungsannahmen jedoch unberücksichtigt lassen können.

Wenn man das Risiko hinzunimmt, dass Angreifer Vertrauensbeziehungen missbrauchen – oder gar „Geisterwälder“ einrichten, um sich Zugriff zu verschaffen, während sich die Teams auf die Umstellung konzentrieren –, wird deutlich, dass das Migrationsfenster eine der Phasen mit dem höchsten Risiko im Identitätslebenszyklus darstellt.


4. Missbrauch der SID-Historie

Das SID-History-Attribut ist nützlich für die Kontinuität, birgt jedoch ohne entsprechende Kontrollmechanismen Gefahren. Penetrationstester haben es Monate nach der Migration genutzt, um über Identitäten, die eigentlich keine Rolle mehr spielen sollten, auf alte Ressourcen zuzugreifen.

In der Praxis kann ein Angreifer die SID-Historie eines Administratorkontos einem Konto mit geringeren Berechtigungen zuweisen und so wieder effektiven Zugriff auf die ursprüngliche Umgebung erlangen. Schlimmer noch: Diese veralteten SIDs bleiben oft jahrelang bestehen, da Unternehmen sie nie vollständig bereinigen.


5. Fehlerhafte oder zu freizügige Zugriffsrechte

Die Übersetzung von Zugriffskontrolllisten (ACL) ohne Validierung ist einer der schnellsten Wege, um eine Berechtigungsabweichung zu verursachen. Sensible Personal- oder Finanzdaten können für große Benutzergruppen zugänglich werden – und Unternehmen bemerken dies oft erst, wenn ein Audit fehlschlägt oder ein Benutzer Daten sieht, die er niemals hätte sehen dürfen.

In großen, unübersichtlichen Umgebungen mit einer Vielzahl von Gruppen kommt es leicht zu solchen Abweichungen, wenn man nicht klar definiert, was wirklich im Vordergrund stehen muss.


6. Fehler bei Dienstkonten und versteckte Berechtigungen

Abhängigkeiten bei Dienstidentitäten sind oft nur unzureichend dokumentiert, weshalb Fachanwendungen auch noch Tage nach einer Migration ausfallen können. Probleme mit Dienstkonten sind jedoch nicht nur eine Frage der Verfügbarkeit. Oft decken sie veraltete Passwörter, übermäßige Berechtigungen, undokumentierte Abhängigkeiten und Authentifizierungspfade auf, die niemand beibehalten wollte.

Wenn Sie Dienstkonten nicht korrekt zuordnen, die Zugriffsrichtlinien (ACLs) für Dienste und COM-Objekte nicht aktualisieren und systemverwaltete Identitäten nicht berücksichtigen, können Sie die Quelle abschalten und erst zu spät feststellen, dass kritische Anwendungen im Zielsystem weiterhin davon abhängig sind. In diesem Moment wird aus „Migration abgeschlossen“ ein „Betriebsausfall“ – und alte Berechtigungen sind möglicherweise weiterhin in der Dienstebene eingebettet.


7. Identitätskonflikte und fehlerhafte Zuordnungen

Eine unzureichende Abgleichlogik kann zu gefährlichen Identitätskonflikten führen. Ein einfaches Beispiel hierfür ist die Verknüpfung des CEO eines übernommenen Unternehmens mit einer Person mit ähnlichem Namen in der Zielumgebung. Die falsche Person kann dadurch den falschen Alias, die falsche E-Mail-Adresse oder falsche Gruppenmitgliedschaften übernehmen.

Hier geht es um mehr als nur um die Ordnung in den Verzeichnissen. Eine fehlerhafte Objektzuordnung führt zu unzulässigen Zugriffen, Datenlecks und schwer nachvollziehbaren Authentifizierungsproblemen, die das Vertrauen in die gesamte Migration untergraben.


8. Koexistenz, die die Auswirkungen von Sicherheitsverletzungen verstärkt

Die Vernetzung während der Migrationsphase kann die Auswirkungen eines Sicherheitsvorfalls vergrößern. Wenn Quelle und Ziel während der Koexistenz nicht ausreichend voneinander isoliert sind, kann die Migrationsinfrastruktur selbst zu einer Brücke werden, über die Angreifer den Angriff von der alten auf die neue Gesamtstruktur ausweiten können.

Koexistenz ist aus betrieblicher Sicht nützlich, aber gefährlich, wenn man sie standardmäßig als vertrauenswürdig betrachtet. Eine neu erstellte Gesamtstruktur ist nicht automatisch eine abgesicherte Gesamtstruktur.


9. Lücken bei der Compliance und bei der Prüfung

Wenn Prüfer fragen, wer während der Migration Zugriff hatte, warum sich die Berechtigungen geändert haben oder wann die SID-Historie hinzugefügt wurde, ist „wir sind uns nicht sicher“ keine akzeptable Antwort.

Wenn es bei der Migration an überprüfbaren Arbeitsabläufen und nachvollziehbaren Berichten mangelt, können Sicherheitsteams keine Kontrolle über Identitätsänderungen nachweisen. Dies führt zu besonders schwierigen Gesprächen mit Wirtschaftsprüfern, Rechtsabteilungen und Cyberversicherern, die Beweise und keine Vermutungen verlangen.


10. Forensische Lücken nach der Umstellung

Die Protokollierung ist während der Migration nicht optional. Sollten Wochen später verdächtige Aktivitäten auftreten und die Protokolle unvollständig, unverständlich oder gar nicht vorhanden sein, können Sie nicht mehr nachvollziehen, was genau geschehen ist und wie der Angreifer eingedrungen ist.

Wenn Sie den Angriffsweg nicht zuverlässig quantifizieren können, können Sie auch nicht nachweisen, dass Sie ihn geschlossen haben. Das ist nach einem Vorfall eine schwer zu verteidigende Position.


11. Ein neuer Wald mit alten Hintertüren

Diese weitreichenderen Risiken sind alle auf denselben Fehler zurückzuführen: dass Mängel weitergeführt werden, weil niemand derzeit etwas ändern möchte.

Inaktive Konten, verwaist SIDs und fragwürdige Konfigurationen bleiben nach der Migration bestehen. Die Sicherheitslücke bleibt verborgen, bis eine spätere Prüfung, eine Cloud-Initiative oder ein Sicherheitsvorfall das Problem aufdeckt.

Und das ist die gefährlichste Annahme von allen: zu glauben, ein neu aufgebauter Wald sei sicher, nur weil er neu ist. Der eigentliche Test für eine AD-Migration besteht nicht darin, ob sich die Benutzer am Montag anmelden können. Es geht vielmehr darum, ob die neue Umgebung wesentlich schwerer zu kompromittieren ist als diejenige, die sie ersetzt hat.


Machen Sie Ihre AD-Migration zu einer Sicherheitsumstellung

AD-Migrationen gehören zu den besten Gelegenheiten, die ein Unternehmen jemals haben wird, um Angriffsflächen zu reduzieren, Sicherheitslücken in Altsystemen zu beseitigen und die Identitätssicherheit zu modernisieren. Dies ist jedoch nur dann der Fall, wenn die Sicherheit von Anfang an in den Migrationsplan integriert wird und nicht als Nacharbeit nach der Umstellung betrachtet wird.

Wenn Ihr Unternehmen eine AD-Migration, eine M&A-Integration oder ein Projekt zur Modernisierung der Active Directory-Gesamtstruktur plant, ist dies der richtige Zeitpunkt, um zu entscheiden, ob Sie lediglich die Infrastruktur verlagern oder Ihre Sicherheitslage wesentlich verbessern möchten.

Bei Semperis betrachten wir die Migration als Sicherheitsmaßnahme und nicht als reine „Lift-and-Shift“-Maßnahme. Wir unterstützen Unternehmen dabei, Risiken aus Altsystemen während der Migration zu minimieren, anstatt diese mitzunehmen und später dafür zu bezahlen. Erfahren Sie mehr über unsere AD-Migrationsdienste.


Erfahren Sie mehr über eine erfolgreiche AD-Migration