Eine belastbare Bestandsaufnahme ist die Grundlage jedes zukünftigen AD-Projekts

Bevor eine historisch gewachsene Active-Directory-Umgebung modernisiert, gehärtet oder migriert wird, muss zunächst verstanden werden, was tatsächlich vorhanden ist.

Gerade bei AD-Umgebungen, die über viele Jahre oder Jahrzehnte gewachsen sind, reicht es nicht, einige Benutzer, Gruppen und Gruppenrichtlinien zu exportieren. Für eine belastbare Entscheidungsgrundlage braucht es eine strukturierte technische und sicherheitsbezogene Bestandsaufnahme.

Mein Ansatz: So viel wie möglich automatisiert erfassen – anschließend fachlich bewerten.

Was sollte dokumentiert und analysiert werden?

Eine Enterprise-Bestandsaufnahme sollte unter anderem folgende Bereiche umfassen:

Forest- und Domain-Struktur

• Forests, Domains und Trusts

• Forest- und Domain Functional Levels

• Domain Controller und Betriebssystemversionen

• FSMO-Rollen

• Global Catalogs

• AD Sites und Subnetze

• Replikation und Replikationsfehler

DNS und grundlegende AD-Infrastruktur

• AD-integrierte DNS-Zonen

• Forwarder und Conditional Forwarder

• DNS-Registrierung der Domain Controller

• veraltete oder fehlerhafte DNS-Einträge

• Abhängigkeiten zwischen DNS, Sites und Replikation

Benutzer und Computer

• aktive und deaktivierte Konten

• lange nicht verwendete Konten

• veraltete Computerobjekte

• Service Accounts

• Konten mit besonderen Einstellungen

• privilegierte Konten

• Kennwort- und Anmeldeeigenschaften

Gruppen und Berechtigungsstrukturen

• Security- und Distribution-Gruppen

• Gruppenverschachtelungen

• privilegierte Gruppen

• verwaiste oder nicht mehr verwendete Gruppen

• direkte Benutzerzuweisungen statt rollenbasierter Gruppenmodelle

• problematische oder historisch gewachsene Berechtigungsketten

Organizational Units

• bestehende OU-Struktur

• Delegationen

• Vererbung

• Block Inheritance

• Verknüpfungen mit Gruppenrichtlinien

• Abweichungen zwischen organisatorischer und sicherheitstechnischer Struktur

Group Policies

• sämtliche GPOs

• GPO-Verknüpfungen

• Security Filtering

• WMI-Filter

• deaktivierte oder nicht verknüpfte GPOs

• widersprüchliche Einstellungen

• veraltete Richtlinien

• sicherheitsrelevante Konfigurationen

Privilegierte Identitäten

• Domain Admins

• Enterprise Admins

• Schema Admins

• Administrators

• Account Operators, Server Operators und Backup Operators

• verschachtelte privilegierte Gruppenmitgliedschaften

• administrative Service Accounts

• dauerhaft vergebene administrative Rechte

Was lässt sich automatisieren?

Ein erheblicher Teil dieser Bestandsaufnahme kann mit PowerShell automatisiert werden.

Beispielsweise können Skripte strukturierte Daten zu Benutzern, Gruppen, Computern, OUs, GPOs, Domain Controllern, Sites, Subnetzen, Trusts, FSMO-Rollen und privilegierten Gruppen erfassen und in CSV-, JSON-, HTML- oder andere weiterverarbeitbare Formate exportieren.

Das reduziert nicht nur den manuellen Aufwand. Eine automatisierte Erfassung schafft auch eine reproduzierbare Baseline, gegen die spätere Änderungen verglichen werden können.

Für umfangreichere Analysen können – abhängig von Zielsetzung, Sicherheitsanforderungen und Umgebung – zusätzlich etablierte Werkzeuge eingesetzt werden, beispielsweise:

• Microsoft PowerShell und die ActiveDirectory-/GroupPolicy-Module

• dcdiag

• repadmin

• Microsoft Security Compliance Toolkit

• Microsoft Defender for Identity

• PingCastle

• Purple Knight

Dabei ist wichtig: Ein Tool ersetzt keine Architektur- und Sicherheitsbewertung.

Ein Scanner kann Auffälligkeiten finden. Er kann aber nicht zuverlässig entscheiden, warum eine Struktur entstanden ist, welche Geschäftsanforderungen dahinterstehen oder ob eine bestimmte Abhängigkeit weiterhin benötigt wird.

Das Ziel ist nicht nur eine Dokumentation

Am Ende sollte deshalb nicht einfach ein mehrere hundert Seiten langer Bericht entstehen.

Benötigt wird eine entscheidungsfähige Dokumentation:

Was haben wir?
Was davon wird noch benötigt?
Wo bestehen technische Schulden?
Wo liegen Sicherheitsrisiken?
Welche Abhängigkeiten existieren?
Was kann bereinigt werden?
Was muss migriert werden?
Und was sollte bewusst nicht in eine zukünftige AD-Struktur übernommen werden?

Erst mit dieser Grundlage lässt sich fundiert entscheiden, ob die bestehende Umgebung modernisiert werden sollte oder ob der Aufbau einer neuen, sauber strukturierten Zielumgebung mit anschließender Migration langfristig die bessere Lösung darstellt.

In Teil 3 gehe ich deshalb tiefer auf die Analyse von privilegierten Identitäten, administrativen Berechtigungen und die Vorbereitung einer modernen administrativen Sicherheitsstruktur ein.

➡️ Teil 1: Entwicklungsumgebung aufbauen und die Ausgangslage bewerten
➡️ Teil 2: Bestandsaufnahme und automatisierte AD-Analyse
➡️ Teil 3: Privilegierte Identitäten, administrative Ebenen und Security-Analyse

#ActiveDirectory #MicrosoftAD #CyberSecurity #IdentitySecurity #IAM #PowerShell #WindowsServer #ITSecurity #Infrastructure #ActiveDirectorySecurity

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

• Tier Model for Active Directory Domain Services

• Best Practices for Securing Active Directory

• Enterprise Access Model

• Securing Privileged Access

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

Herzlich willkommen!

Mit diesem ersten Beitrag startet der neue Newsletter und Blog von Inderwildi IT Consulting.

Hier teile ich verständliches und praxisnahes Wissen aus über 40 Jahren IT-Erfahrung. Mein Ziel ist es, technische Themen so aufzubereiten, dass sie nicht nur theoretisch korrekt, sondern im beruflichen Alltag tatsächlich hilfreich sind.

Was dich hier erwartet

In den kommenden Beiträgen geht es unter anderem um:

• Microsoft 365 und Modern Workplace
• Active Directory und Microsoft Entra ID
• Cybersecurity und Zero Trust
• Identity & Access Management
• Public Key Infrastructure und Zertifikate
• PowerShell und IT-Automatisierung
• Windows Server, Cloud und IT-Infrastruktur
• Compliance, NIS2 und ISO 27001
• Praktische IT- und Sicherheitstipps für Schweizer KMU und Privatpersonen

Für wen ist dieser Newsletter gedacht?

Der Newsletter richtet sich an:

• Unternehmen und Schweizer KMU
• IT-Verantwortliche und Systemadministratoren
• Entscheidungsträger, die ihre IT sicherer gestalten möchten
• Privatpersonen, die verständliche Unterstützung benötigen
• Alle, die sich für Microsoft-Technologien und Cybersecurity interessieren

Praxiswissen statt leerer Versprechen

Viele IT-Themen werden unnötig kompliziert dargestellt. Ich möchte zeigen, welche Massnahmen wirklich sinnvoll sind, welche Risiken häufig unterschätzt werden und wie sich Verbesserungen schrittweise umsetzen lassen.

Dabei fliessen Erfahrungen aus zahlreichen Enterprise-Projekten in den Bereichen Microsoft 365, Active Directory, Entra ID, IAM, PKI, Cloud, Automatisierung und Cybersecurity ein.

Was ist als Nächstes geplant?

Geplant sind unter anderem Beiträge zu folgenden Fragen:

• Wie lässt sich Microsoft 365 für Schweizer KMU sinnvoll absichern?
• Welche Schutzmassnahmen helfen nach einem Cybervorfall?
• Wie unterscheiden sich Active Directory und Microsoft Entra ID?
• Wie beginnt man mit Zero Trust, ohne die gesamte IT neu aufzubauen?
• Welche Aufgaben lassen sich sicher mit PowerShell automatisieren?
• Warum sind funktionierende Backups und Wiederherstellungstests unverzichtbar?

Deine Fragen sind willkommen

Gibt es ein IT- oder Sicherheitsthema, das ich in einem zukünftigen Beitrag behandeln soll?

Antworte einfach auf den Newsletter oder schreibe an:

info@inderwildi.org

Benötigst du persönliche Unterstützung?

Inderwildi IT Consulting unterstützt 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

Vielen Dank für dein Interesse. Ich freue mich, mein Wissen und meine Erfahrungen künftig mit dir zu teilen.

Freundliche Grüsse

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