Hallo und herzlich willkommen!

In diesem Beitrag geht es um die Modernisierung einer historisch gewachsenen Active-Directory-Umgebung. Du erfährst, warum es häufig sinnvoll ist, zuerst eine neue, sauber strukturierte und gehärtete Zielumgebung aufzubauen, anstatt sämtliche Altlasten ungeprüft in die neue Umgebung zu übernehmen.

Das Wichtigste in Kürze

  • Eine neue Active-Directory-Zielumgebung ermöglicht eine klare, dokumentierte und sicherheitsorientierte Struktur.

  • Das AD-DS-Tier-Modell von Microsoft trennt administrative Konten, Systeme und Zugriffswege nach ihrer Kritikalität.

  • Aus der bestehenden Umgebung dürfen nur geprüfte und tatsächlich benötigte Objekte, Attribute und Berechtigungen übernommen werden.

  • Die Migration muss in mehreren kontrollierten Phasen mit Pilotgruppen, Funktionstests, Sicherheitsprüfungen und einem Rückfallplan erfolgen.

  • PowerShell eignet sich hervorragend für Inventarisierung, Zuordnung, Übertragung, Protokollierung und Validierung – ersetzt aber keine sorgfältige Migrationsplanung.

Ausgangslage

Viele Active-Directory-Umgebungen sind über Jahre oder sogar Jahrzehnte gewachsen. Organisationseinheiten wurden mehrfach erweitert, Gruppen unterschiedlich benannt und Berechtigungen oftmals nur für einzelne Anforderungen ergänzt.

Häufig finden sich darin:

  • nicht mehr benötigte Benutzer-, Computer- und Gruppenkonten,

  • veraltete Gruppenrichtlinien,

  • unklare oder verschachtelte Gruppenmitgliedschaften,

  • dauerhaft privilegierte Konten,

  • Dienstkonten mit weitreichenden Berechtigungen,

  • uneinheitliche Namenskonventionen,

  • fehlende Trennung administrativer Berechtigungen,

  • alte Sicherheitsprotokolle und Konfigurationen,

  • undokumentierte Abhängigkeiten zu Anwendungen und Servern.

Wird eine solche Umgebung lediglich aktualisiert oder vollständig kopiert, werden viele ihrer technischen Altlasten und Sicherheitsrisiken ebenfalls übernommen.

Eine komplett neue Active-Directory-Gesamtstruktur ist allerdings nicht in jedem Unternehmen automatisch die beste Lösung. Vor dieser Entscheidung müssen Abhängigkeiten zu Microsoft Entra ID, Microsoft 365, Exchange, PKI, Dateiberechtigungen, Anwendungen, Dienstkonten, Netzwerken und angebundenen Systemen vollständig analysiert werden.

Warum ist das wichtig?

Active Directory gehört in vielen Unternehmen zur sicherheitskritischen Identitäts- und Steuerungsebene. Wer Active Directory kontrolliert, kann häufig auch auf Server, Anwendungen, Daten und weitere zentrale Systeme zugreifen.

Eine saubere Zielumgebung bietet die Möglichkeit, bekannte Schwachstellen nicht weiterzuführen. Dazu gehören insbesondere zu weitreichende Berechtigungen, gemeinsam verwendete Administratorkonten und die Anmeldung hoch privilegierter Konten an normalen Arbeitsplatzgeräten.

Microsoft empfiehlt für Active Directory ein mehrstufiges Administrationsmodell:

  • Tier 0: Identitätssysteme und Komponenten, die Active Directory vollständig kontrollieren können – beispielsweise Domain Controller, hoch privilegierte Administrationskonten und sicherheitskritische Verwaltungswerkzeuge.

  • Tier 1: Server, Unternehmensanwendungen und die dazugehörigen Administrationskonten.

  • Tier 2: Arbeitsplatzgeräte, Benutzerunterstützung und die entsprechenden Administrationskonten.

Entscheidend ist nicht nur die Einteilung in Organisationseinheiten. Konten, Geräte, Berechtigungen und administrative Zugriffswege müssen so getrennt werden, dass Zugangsdaten einer höheren Vertrauensstufe niemals auf einem System mit niedrigerer Vertrauensstufe verwendet werden.

In hybriden Umgebungen muss das AD-DS-Tier-Modell zusätzlich in das umfassendere Enterprise Access Model von Microsoft eingebettet werden. Das frühere ESAE- beziehungsweise Red-Forest-Konzept gilt dagegen nicht mehr als allgemeine Standardempfehlung für neue Implementierungen.

Empfohlene Vorgehensweise

1. Bestehende Umgebung vollständig erfassen

Vor dem Aufbau der neuen Umgebung müssen alle relevanten Objekte und Abhängigkeiten dokumentiert werden. Dazu gehören unter anderem:

  • Benutzer und administrative Konten,

  • Computer und Server,

  • Sicherheits- und Verteilergruppen,

  • Gruppenmitgliedschaften,

  • Organisationseinheiten,

  • Gruppenrichtlinien,

  • Dienstkonten und geplante Aufgaben,

  • delegierte Berechtigungen,

  • DNS und Vertrauensstellungen,

  • Dateisystem- und Applikationsberechtigungen,

  • PKI- und Zertifikatsabhängigkeiten,

  • Entra-ID- und Microsoft-365-Synchronisationen,

  • sowie technische Abhängigkeiten von Fachanwendungen.

Nicht mehr verwendete Konten, Gruppen und Systeme müssen identifiziert werden. Eine Migration darf nicht gleichzeitig als unkontrollierte Bereinigung durchgeführt werden. Jede geplante Änderung benötigt eine dokumentierte Entscheidung.

2. Neue Zielarchitektur planen

Anschliessend wird die neue Active-Directory-Zielarchitektur entwickelt. Dabei müssen mindestens folgende Punkte festgelegt werden:

  • Forest- und Domänenstruktur,

  • DNS-Namenskonzept,

  • OU-Struktur,

  • Namenskonventionen,

  • Rollen- und Gruppenkonzept,

  • administrative Delegierung,

  • Tier-0-, Tier-1- und Tier-2-Zuordnung,

  • getrennte Benutzer- und Administratorkonten,

  • administrative Arbeitsstationen beziehungsweise Privileged Access Workstations,

  • Gruppenrichtlinien und Sicherheitsbaselines,

  • Protokollierung, Überwachung und Alarmierung,

  • Backup- und Wiederherstellungskonzept,

  • Notfallkonten und Notfallverfahren.

Eine Entwicklungs- oder Laborumgebung ist empfehlenswert, um die Architektur, Automatisierung und Migrationsabläufe zuerst isoliert zu erproben. Die spätere produktive Zielumgebung muss jedoch separat, kontrolliert und nach dem freigegebenen Design aufgebaut werden.

3. Zielumgebung härten

Die neue Umgebung wird vor der ersten produktiven Migration nach aktuellen Sicherheitsanforderungen gehärtet. Dazu gehören insbesondere:

  • konsequente Anwendung des Prinzips der geringsten Berechtigung,

  • Trennung der Administrationskonten nach Vertrauensstufe,

  • abgesicherte administrative Arbeitsstationen,

  • Einschränkung administrativer Anmeldungen,

  • sichere Konfiguration der Domain Controller,

  • aktuelle und freigegebene Sicherheitsbaselines,

  • Schutz privilegierter Gruppen,

  • Überwachung kritischer Änderungen,

  • sichere Verwaltung von Dienstkonten, möglichst mit gMSA,

  • kontrollierte Verwendung starker Authentifizierungsverfahren,

  • sowie getestete Backups und Wiederherstellungsverfahren.

Bei rein lokalem Active Directory steht MFA nicht für jeden administrativen Anmeldeweg automatisch zur Verfügung. Sie muss deshalb passend zur vorhandenen Architektur umgesetzt werden, beispielsweise über abgesicherte Zugangswege, Smartcards, Windows Hello for Business oder angebundene Identitäts- und Privileged-Access-Lösungen.

4. Benötigte Objekte kontrolliert übertragen

Aus der bestehenden Active-Directory-Umgebung werden nur freigegebene und tatsächlich benötigte Informationen übernommen.

PowerShell kann unter anderem verwendet werden für:

  • Inventarisierung der Quellumgebung,

  • Prüfung und Bereinigung der Quelldaten,

  • Zuordnung alter und neuer Organisationseinheiten,

  • Erstellung neuer Benutzer und Gruppen,

  • Übertragung ausgewählter Attribute,

  • Wiederherstellung genehmigter Gruppenmitgliedschaften,

  • Erkennung von Abweichungen,

  • Protokollierung jedes Verarbeitungsschrittes,

  • sowie technische Validierung der Ergebnisse.

Bestimmte Bestandteile lassen sich jedoch nicht einfach mit den normalen Active-Directory-PowerShell-Cmdlets kopieren. Dazu gehören insbesondere Kennwörter und die sicherheitskritische sIDHistory. Auch Computer, Benutzerprofile, verschlüsselte Daten, Zertifikate, Anwendungen und Berechtigungen können zusätzliche Migrationsverfahren erfordern.

Die Verwendung von sIDHistory kann während einer domänenübergreifenden Migration vorübergehend notwendig sein. Sie erweitert jedoch die wirksamen Zugriffsrechte eines Kontos und muss deshalb streng kontrolliert, protokolliert und nach Abschluss der Ressourcenmigration wieder entfernt werden.

Ich entwickle derzeit ein eigenes PowerShell-Modul, das die strukturierte Erfassung, Zuordnung, Übertragung und Validierung ausgewählter Active-Directory-Objekte unterstützen soll. Das Modul wird bewusst mit Prüfungen, Protokollierung, Fehlerbehandlung und kontrollierten Freigabeschritten entwickelt. Es soll keine vollständige Umgebung ungeprüft kopieren.

5. Pilotmigration und verbindliche Tests durchführen

Vor der produktiven Migration muss der gesamte Ablauf mit ausgewählten Pilotobjekten getestet werden. Dazu gehören:

  1. Prüfung der Benutzeranmeldung,

  2. Kontrolle der Gruppenmitgliedschaften,

  3. Validierung der Zugriffsberechtigungen,

  4. Tests von Fachanwendungen und Diensten,

  5. Prüfung von DNS und Namensauflösung,

  6. Tests der Entra-ID- und Microsoft-365-Anbindung,

  7. Kontrolle der administrativen Zugriffswege,

  8. Überprüfung der Sicherheitsprotokolle,

  9. Wiederherstellungs- und Rückfalltests,

  10. Vergleich zwischen Quell- und Zielzustand.

Erst wenn die definierten Abnahmekriterien erfüllt sind, darf die nächste Migrationswelle freigegeben werden.

Praxis-Tipp

Aus meiner langjährigen Erfahrung mit Active Directory, IAM, PKI, Microsoft 365 und komplexen Unternehmensumgebungen empfehle ich, vor der ersten Migration eine verbindliche Zuordnungstabelle zu erstellen.

Für jedes zu übertragende Objekt sollte mindestens dokumentiert werden:

  • Quellobjekt,

  • Zielobjekt,

  • verantwortliche Person,

  • geschäftlicher Zweck,

  • Ziel-OU,

  • Ziel-Tier,

  • benötigte Attribute,

  • Gruppenmitgliedschaften,

  • Berechtigungen,

  • technische Abhängigkeiten,

  • Testverfahren,

  • Freigabestatus,

  • Rückfallverfahren.

Diese Zuordnung verhindert, dass veraltete Strukturen und unnötige Berechtigungen unbemerkt in die neue Umgebung übernommen werden.

Sicherheitshinweis

Eine Active-Directory-Migration ist keine reine Kopieraufgabe. Fehler können zu Anmeldeproblemen, unterbrochenen Diensten, verlorenen Berechtigungen oder neuen Sicherheitslücken führen.

Besondere Vorsicht ist erforderlich bei:

  • privilegierten Konten und Gruppen,

  • sIDHistory,

  • Dienstkonten,

  • Zertifizierungsstellen und Zertifikaten,

  • Gruppenrichtlinien,

  • Entra-ID-Synchronisation,

  • Exchange-Attributen,

  • Dateisystemberechtigungen,

  • verschlüsselten Dateien,

  • sowie Anwendungen mit fest hinterlegten Domänenkonten.

Migrationsskripte müssen zuerst in einer isolierten Testumgebung geprüft werden. Jeder produktive Durchlauf benötigt Protokollierung, Freigabe, Backup, definierte Abbruchkriterien und einen getesteten Rückfallplan.

Fazit

Bei einer stark historisch gewachsenen Active-Directory-Umgebung kann eine neu aufgebaute, sauber strukturierte und gehärtete Zielumgebung erhebliche Sicherheits- und Betriebs­vorteile bieten.

Der richtige Weg besteht nicht darin, die alte Umgebung vollständig zu kopieren. Zuerst wird eine tragfähige Zielarchitektur aufgebaut. Anschliessend werden nur geprüfte und benötigte Objekte kontrolliert übertragen und in verbindlichen Pilot- und Abnahmetests validiert.

In den nächsten Newsletter-Beiträgen zeige ich weitere von mir empfohlene Schritte – von der Bestandsaufnahme und Zielarchitektur bis zur sicheren Migration, Prüfung und späteren Ausserbetriebnahme der alten Umgebung.

Fachliche Grundlagen von Microsoft

Benötigst du Unterstützung?

Ich unterstütze Unternehmen, KMU und Privatpersonen bei Microsoft 365, Active Directory, Entra ID, IAM, PKI, PowerShell, Cybersecurity, Zero Trust und moderner IT-Infrastruktur.

Mehr Informationen:
https://inderwildi.org/

Kostenloses Kennenlerngespräch:
https://inderwildi.org/kennenlerngespraech

Freundliche Grüsse

Hubert Inderwildi
Senior System Engineer & IT-Security-Spezialist
Inderwildi IT Consulting

Reply

Avatar

or to participate

Weiterlesen

Mehr anzeigen
caret-right
© 2026 Inderwildi IT Consulting.
beehiivPowered by beehiiv