← Übersicht
Active Directory

Active Directory – Grundlagen

Was ist Active Directory?

Active Directory Domain Services (AD DS) ist der Verzeichnisdienst von Microsoft Windows Server. Er speichert Informationen über alle Objekte im Netzwerk – Benutzer, Computer, Gruppen, Drucker, Freigaben – in einer zentralen, hierarchischen Datenbank und stellt Authentifizierung sowie Autorisierung für die gesamte Domäne bereit. Statt sich an jedem Gerät einzeln anzumelden, gibt es ein Single Sign-On gegen die Domäne.

AD DS ist eng mit DNS verzahnt: Clients finden Domänencontroller über DNS-SRV-Records. Ohne funktionierendes DNS funktioniert kein Active Directory.

Logische AD-Struktur: Forest, Tree, Domänen, OUs und Objekte hierarchisch
Abb. – Logische AD-Struktur: Gesamtstruktur (Forest) → Baum (Tree) → Domänen → OUs → Objekte (Benutzer/Computer/Gruppen)
Tipp: AD DS ist die lokale (on-premises) Variante. Der cloudbasierte Identitätsdienst heißt heute Microsoft Entra ID (früher Azure AD) – beide ergänzen sich im Hybrid-Betrieb, sind aber technisch verschiedene Systeme (siehe Abschnitt Azure AD / Entra ID).

Logische Struktur: Domäne, Baum, Gesamtstruktur

Active Directory ist hierarchisch aufgebaut. Die logische Struktur trennt sich von der physischen (Standorte, Server):

BegriffBeschreibung
Domäne (Domain)Administrative und Sicherheitsgrenze. Bündelt Objekte unter einem gemeinsamen DNS-Namen, z. B. firma.local. Eigene Sicherheitsrichtlinien und Replikation.
Baum (Tree)Eine oder mehrere Domänen mit zusammenhängendem Namensraum, z. B. firma.local und vertrieb.firma.local. Untergeordnete Domänen erben den Namen der übergeordneten.
Gesamtstruktur (Forest)Oberste Container-Ebene und echte Sicherheitsgrenze. Umfasst einen oder mehrere Bäume, die ein gemeinsames Schema, einen gemeinsamen Global Catalog und automatische Vertrauensstellungen teilen.
Organisationseinheit (OU)Container innerhalb einer Domäne zur Strukturierung von Objekten, Delegierung und GPO-Verknüpfung (eigener Abschnitt).

Domänencontroller (DC)

Ein Domänencontroller ist ein Windows-Server, auf dem die AD-DS-Rolle installiert ist. Er hält eine beschreibbare Kopie der AD-Datenbank (NTDS.dit), beantwortet Anmelde- und Suchanfragen und repliziert Änderungen mit den anderen DCs (Multi-Master-Replikation). Best Practice: pro Domäne mindestens zwei DCs für Ausfallsicherheit.

Ein Read-Only Domain Controller (RODC) hält nur eine schreibgeschützte Kopie und eignet sich für unsichere Standorte (z. B. Zweigstellen).

# Server zum Domänencontroller heraufstufen (PowerShell) Install-WindowsFeature AD-Domain-Services -IncludeManagementTools # Neue Gesamtstruktur (erster DC einer neuen Domäne) erstellen Install-ADDSForest -DomainName "firma.local" -DomainNetbiosName "FIRMA" ` -InstallDns -ForestMode WinThreshold -DomainMode WinThreshold # Zusätzlichen DC zu bestehender Domäne hinzufügen Install-ADDSDomainController -DomainName "firma.local" -InstallDns -Credential (Get-Credential)

Schema

Das Schema ist der Bauplan von Active Directory. Es definiert alle möglichen Objektklassen (z. B. user, group, computer) und deren Attribute (z. B. givenName, mail). Das Schema gilt gesamtstrukturweit und wird selten geändert – Schema-Erweiterungen (etwa durch Exchange) sind dauerhaft und sollten nur geplant erfolgen.

FSMO-Rollen

Manche Aufgaben dürfen nicht parallel von mehreren DCs ausgeführt werden, da das zu Konflikten führen würde. Diese Flexible Single Master Operations (FSMO) liegen auf jeweils genau einem DC. Es gibt fünf Rollen: zwei pro Gesamtstruktur, drei pro Domäne.

RolleEbeneAufgabe
Schema MasterGesamtstrukturEinziger DC, der Schema-Änderungen schreiben darf
Domain Naming MasterGesamtstrukturHinzufügen/Entfernen von Domänen in der Gesamtstruktur
PDC EmulatorDomäneZeitquelle der Domäne, Passwort-Änderungen, Sperrungen, GPO-Bearbeitung
RID MasterDomäneVergibt RID-Pools an DCs für eindeutige SIDs neuer Objekte
Infrastructure MasterDomäneAktualisiert domänenübergreifende Objektverweise (z. B. Gruppen­mitgliedschaften)
# FSMO-Rolleninhaber anzeigen netdom query fsmo # Per PowerShell – Domänen- und Gesamtstruktur-Rollen Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster # Rolle übertragen (sauberer Wechsel, Quelle online) Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole PDCEmulator
Tipp: Ist der Quell-DC dauerhaft ausgefallen, wird die Rolle mit Move-ADDirectoryServerOperationMasterRole -Force beschlagnahmt (seized). Der alte Rolleninhaber darf danach nie wieder ans Netz – sonst droht ein Split-Brain.

Global Catalog (GC)

Der Global Catalog ist eine gesamtstrukturweite, teilweise Replikation: Er enthält alle Objekte der Gesamtstruktur, aber nur mit den wichtigsten Attributen. Er ermöglicht schnelle, domänenübergreifende Suchen, löst universelle Gruppen­mitgliedschaften bei der Anmeldung auf und unterstützt UPN-Anmeldungen (benutzer@firma.local). In jeder Domäne sollte mindestens ein DC ein GC sein.

# Global-Catalog-Server in der Gesamtstruktur finden Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} | Select-Object Name, Site # LDAP-Port: 389 (LDAP) / 636 (LDAPS) – GC: 3268 (GC) / 3269 (GC über SSL)

LDAP & Kerberos

Anwendungen lesen und schreiben AD-Objekte über LDAP (Lightweight Directory Access Protocol, Port 389 / verschlüsselt 636). Die Authentifizierung erfolgt standardmäßig über Kerberos (NTLM nur noch als Fallback).

Kerberos arbeitet ticketbasiert über das Key Distribution Center (KDC), das auf jedem DC läuft:

  1. Anmeldung: Der Client fordert beim KDC ein Ticket Granting Ticket (TGT) an.
  2. Ressourcenzugriff: Mit dem TGT holt der Client ein Service Ticket für den Zielserver.
  3. Der Zielserver prüft das Ticket – kein erneutes Passwort nötig (Single Sign-On).
Kerberos-Authentifizierung: AS-REQ/AS-REP für TGT, TGS-REQ/TGS-REP für Service Ticket, dann Zugriff
Abb. – Kerberos-Flow: AS-REQ/AS-REP (TGT vom KDC) → TGS-REQ/TGS-REP (Service Ticket) → AP-REQ/AP-REP (Zugriff auf den Dienst)
Tipp: Kerberos ist stark zeitabhängig. Weicht die Uhr eines Clients um mehr als 5 Minuten vom DC ab, schlägt die Authentifizierung fehl (clock skew). Der PDC-Emulator ist die maßgebliche Zeitquelle der Domäne.

Wichtige AD-Ports (Firewall)

Zwischen Clients und DCs sowie zwischen DCs untereinander müssen bestimmte Ports offen sein. Eine zu restriktive Firewall ist eine häufige Ursache für Anmelde- und Replikationsfehler:

PortProtokoll/DienstZweck
53DNS (TCP/UDP)Namensauflösung, SRV-Records zum DC-Finden
88Kerberos (TCP/UDP)Authentifizierung (TGT/Service-Tickets)
389LDAP (TCP/UDP)Verzeichnisabfragen
636LDAPS (TCP)LDAP über TLS
445SMB (TCP)SYSVOL/NETLOGON, GPO-Verteilung
3268 / 3269Global Catalog (TCP)GC-Suche / GC über SSL
135 + dyn.RPC-Endpoint-MapperReplikation, FSMO-Zugriff (dyn. Ports 49152–65535)
123NTP (UDP)Zeitsynchronisation (Kerberos-Voraussetzung)
Tipp: Den verschlüsselten Zugriff prüfen: AD vergibt seit Windows Server die LDAP-Channel-Binding- und Signing-Anforderungen schärfer. Erzwungenes LDAP-Signing verhindert NTLM-Relay-Angriffe – teste vor der Aktivierung mit Get-WinEvent auf Event-ID 2889 (unsignierte LDAP-Binds).
Active Directory

DNS im Active Directory

Warum AD ohne DNS nicht funktioniert

Active Directory nutzt DNS nicht nur für Namen, sondern als Wegweiser: Clients und DCs finden Domänencontroller, Global Catalogs und Kerberos-Server ausschließlich über SRV-Records im DNS. Ist DNS falsch eingerichtet, ist fast jeder AD-Fehler die Folge.

Client fragt DNS nach SRV-Records und kontaktiert dann den Domänencontroller
Abb. – DC-Locator: Der Client fragt DNS, welche DCs es gibt, und meldet sich dann bei einem davon an

Die wichtigsten SRV-Records

RecordFindet
_ldap._tcp.dc._msdcs.<domäne>alle Domänencontroller der Domäne
_kerberos._tcp.<domäne>Kerberos-Server (KDC) für die Anmeldung
_gc._tcp.<forest>Global-Catalog-Server
_ldap._tcp.pdc._msdcs.<domäne>den PDC-Emulator
_ldap._tcp.<standort>._sites.dc._msdcs.<domäne>DCs im eigenen Standort (kurze Wege)

Die Records legt der Netlogon-Dienst jedes DCs selbst an. Fehlen sie, hilft oft ein Neustart des Dienstes: Restart-Service Netlogon bzw. nltest /dsregdns.

AD-integrierte Zonen

  • Die Zone wird nicht als Datei, sondern in der AD-Datenbank gespeichert und mit der normalen AD-Replikation verteilt.
  • Multi-Master: Jeder DC mit DNS-Rolle kann Änderungen annehmen – kein einzelner primärer Server.
  • Sichere dynamische Updates: Nur authentifizierte Domänenmitglieder dürfen ihre eigenen Einträge registrieren.
  • Replikationsbereich wählbar: alle DNS-Server der Domäne oder der gesamten Gesamtstruktur (wichtig für _msdcs).

Best Practices

EinstellungEmpfehlung
DNS-Server der Clientsnur AD-DNS-Server eintragen – nie zusätzlich den Router oder 8.8.8.8
DNS-Server der DCszuerst einen anderen DC, danach sich selbst (127.0.0.1 an zweiter Stelle)
Internet-Namenüber Weiterleitungen (Forwarder) an den Provider oder einen Resolver
Alte EinträgeAufräumen (Scavenging) aktivieren, damit verwaiste Records verschwinden
Reverse-Zonenfür alle internen Subnetze anlegen (PTR-Records)
DomänennameSubdomain einer eigenen, registrierten Domain, z. B. corp.example.com – .local ist in Laboren üblich, aber nicht empfohlen
# SRV-Records prüfen Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.com nslookup -type=SRV _kerberos._tcp.corp.example.com # Zonen und Weiterleitungen anzeigen / setzen Get-DnsServerZone Get-DnsServerForwarder Add-DnsServerForwarder -IPAddress 9.9.9.9 # Scavenging aktivieren (7 Tage) Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones # DNS-Test des DCs dcdiag /test:dns /v
Klassiker im Support: Ein Client hat als zweiten DNS-Server den Router eingetragen. Mal klappt die Anmeldung, mal nicht – je nachdem, welchen Server Windows gerade fragt. Lösung: ausschließlich AD-DNS verwenden.
Active Directory

LDAP & Verzeichnisabfragen

Was ist LDAP?

Das Lightweight Directory Access Protocol ist die Sprache, mit der Programme das Verzeichnis lesen und ändern – von der Adressbuchsuche im Mailprogramm bis zur Anmeldung an einer Firewall oder einem Linux-Server. Port 389 (LDAP) bzw. 636 (LDAPS, verschlüsselt), Global Catalog auf 3268/3269.

Verzeichnisbaum von der Domäne über OUs bis zum Benutzer mit zusammengesetztem DN
Abb. – Jedes Objekt hat einen eindeutigen Pfad, den Distinguished Name

Wichtige Begriffe

BegriffBedeutungBeispiel
DNDistinguished Name – vollständiger PfadCN=Max Muster,OU=Benutzer,DC=corp,…
Base DNStartpunkt einer SucheOU=Benutzer,DC=corp,DC=example,DC=com
AttributEigenschaft eines ObjektssAMAccountName, mail, memberOf
objectClassObjekttyp laut Schemauser, group, computer
BindAnmeldung am VerzeichnisDienstkonto für eine Anwendung

LDAP-Filter lesen und schreiben

Filter stehen in Klammern, Operatoren kommen vor die Bedingungen: & = UND, | = ODER, ! = NICHT.

(objectClass=user) # alle Benutzer (&(objectClass=user)(department=Vertrieb)) # Benutzer aus dem Vertrieb (&(objectCategory=person)(mail=*)) # alle mit E-Mail-Adresse (|(sn=Muster)(sn=Beispiel)) # Nachname Muster ODER Beispiel (&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) # nur aktivierte Konten

Abfragen in der Praxis

# PowerShell (RSAT-Modul ActiveDirectory) Get-ADUser -LDAPFilter "(department=Vertrieb)" -Properties mail | Select Name, mail Get-ADUser -Filter 'Enabled -eq $false' -SearchBase "OU=Benutzer,DC=corp,DC=example,DC=com" Get-ADGroupMember "GG_Vertrieb" -Recursive | Select Name # Klassische Werkzeuge dsquery user -name "Max*" dsget user "CN=Max Muster,OU=Benutzer,DC=corp,DC=example,DC=com" -memberof # Grafisch: ldp.exe oder "Active Directory-Benutzer und -Computer" → Ansicht → Erweiterte Features → Attribut-Editor
Sicherheit: Einfache LDAP-Binds übertragen das Passwort im Klartext. Anwendungen sollten LDAPS (636) oder LDAP mit StartTLS nutzen; Microsoft verschärft die Anforderungen an LDAP Signing und Channel Binding schrittweise.
Active Directory

FSMO-Rollen übertragen & übernehmen

Welche fünf FSMO-Rollen es gibt und wofür sie zuständig sind, steht im Abschnitt AD Grundlagen → FSMO-Rollen. Hier geht es um den Betrieb: Wie man die aktuellen Rolleninhaber ermittelt, eine Rolle geordnet überträgt (transfer) und sie im Notfall beschlagnahmt (seize).

Aktuelle Rolleninhaber anzeigen

Vor jedem Wechsel muss klar sein, welcher DC welche Rolle hält. Drei Wege führen zum Ziel:

# Schnellübersicht aller fünf Rollen netdom query fsmo # Domänenweite Rollen (RID / PDC / Infrastruktur) per PowerShell Get-ADDomain | Select-Object RIDMaster, PDCEmulator, InfrastructureMaster # Gesamtstrukturweite Rollen (Schema / Domänennamen) Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Transfer – geordneter Wechsel (Quelle erreichbar)

Solange der bisherige Rolleninhaber noch online ist, wird die Rolle sauber übertragen. Das ist der Normalfall, z. B. vor Wartung oder Außerbetriebnahme eines DCs. Je nach Rolle gibt es ein eigenes GUI-Werkzeug:

Rolle(n)GUI-Werkzeug & Weg
RID / PDC / Infrastruktur (domänenweit)Active Directory-Benutzer und -Computer (ADUC) → zuerst Rechtsklick oben → „Domänencontroller ändern…" und den Ziel-DC wählen → dann Rechtsklick auf die Domäne → „Betriebsmaster…" → passenden Reiter (RID/PDC/Infrastruktur) → „Ändern".
Domänennamenmaster (forestweit)Active Directory-Domänen und -Vertrauensstellungen → Rechtsklick oben → Betriebsmaster → „Ändern".
Schemamaster (forestweit)Erst Snap-In registrieren mit regsvr32 schmmgmt.dll, dann leere MMC öffnen → Snap-In „Active Directory-Schema" hinzufügen → Rechtsklick → „Betriebsmaster…".

Schneller geht es per PowerShell – mehrere Rollen lassen sich in einem Aufruf auf einen Ziel-DC übertragen:

# Eine oder mehrere Rollen geordnet auf DC02 übertragen Move-ADDirectoryServerOperationMasterRole -Identity "DC02" ` -OperationMasterRole RIDMaster, PDCEmulator, InfrastructureMaster, ` DomainNamingMaster, SchemaMaster

Seize – Beschlagnahmen im Notfall (ntdsutil)

Ist der bisherige Rolleninhaber dauerhaft ausgefallen und nicht wiederherstellbar, kann eine Rolle nicht mehr sauber übertragen, sondern nur noch beschlagnahmt (seized) werden. Das geschieht klassisch mit ntdsutil:

ntdsutil roles connections connect to server DC02 quit seize pdc # PDC-Emulator beschlagnahmen seize rid master # RID-Master beschlagnahmen seize infrastructure master seize naming master # Domänennamenmaster seize schema master # Schemamaster quit quit
Warnung: seize nur bei dauerhaftem Ausfall verwenden. Der alte Rolleninhaber darf danach nie wieder ans Netz – sonst entstehen FSMO-Konflikte (zwei DCs glauben, dieselbe Rolle zu halten / Split-Brain). Im Normalfall immer transfer, niemals seize.

ntdsutil – weitere Aufgaben

ntdsutil ist das Schweizer Taschenmesser der AD-Datenbankpflege und kann über die FSMO-Verwaltung hinaus mehr:

AufgabeKontext / Befehl
Metadatenbereinigungmetadata cleanup – Reste eines unsauber entfernten DCs aus AD löschen
DSRM-Kennwort setzenset dsrm password – Kennwort für den Verzeichniswiederherstellungsmodus zurücksetzen
FSMO-Verwaltungroles → transfer / seize (siehe oben)
Active Directory

Strukturen, Gesamtstruktur & Vertrauensstellungen

Die logische Grundhierarchie (Domäne → Baum → Gesamtstruktur) ist in den AD Grundlagen beschrieben. Dieser Abschnitt vertieft, wie mehrere Domänen zusammenwirken, wie man eine untergeordnete Domäne anlegt und wie Vertrauensstellungen (Trusts) funktionieren.

Baum (Tree) vs. Gesamtstruktur (Forest)

EbeneGemeinsamkeitNamensraum
Baum (Tree)Domänen mit zusammenhängendem Namensraum: Stammdomäne + SubdomänenGemeinsam, z. B. firma.local + ausbildung.firma.local
Gesamtstruktur (Forest)Mehrere Bäume mit gemeinsamem Schema und gemeinsamer KonfigurationspartitionDarf verschieden sein, z. B. firma.local + partner.org

FSMO-Verteilung über Domänen

Die fünf FSMO-Rollen verteilen sich nach ihrer Ebene:

  • Gesamtstrukturweit (je 1× pro Forest): Schemamaster + Domänennamenmaster – idealerweise zusammen auf dem ersten DC der Stammdomäne.
  • Domänenweit (je 1× pro Domäne): RID-Master, PDC-Emulator und Infrastrukturmaster – existieren in jeder Domäne der Gesamtstruktur erneut.

Wie man diese Rollen verschiebt oder beschlagnahmt, steht im Abschnitt FSMO-Rollen übertragen & übernehmen.

Untergeordnete Domäne erstellen

Eine untergeordnete (Child-)Domäne erweitert einen bestehenden Baum um einen Subdomänen-Namensraum. Im Assistenten: „Active Directory-Domänendienste-Konfiguration" → „Neue Domäne zu vorhandener Gesamtstruktur hinzufügen" → Domänentyp „Untergeordnete Domäne". Per PowerShell:

# Untergeordnete Domäne "ausbildung.firma.local" anlegen Install-ADDSDomain -NewDomainName "ausbildung" ` -ParentDomainName "firma.local" -DomainType ChildDomain ` -InstallDNS -Credential (Get-Credential)

Vertrauensstellungen (Trusts)

Ein Trust erlaubt Benutzern einer Domäne den Zugriff auf Ressourcen einer anderen Domäne. Man unterscheidet nach Richtung und Reichweite:

EigenschaftBedeutung
UnidirektionalEine Domäne vertraut der anderen. Aus Sicht einer Domäne eingehend (trusting, stellt Ressourcen bereit) oder ausgehend (trusted, deren Konten dürfen zugreifen).
BidirektionalBeide vertrauen sich gegenseitig – technisch zwei unidirektionale Trusts.
TransitivDas Vertrauen wird an verbundene Domänen vererbt: Vertraut A der B und B der C, vertraut A automatisch auch C.
Tipp: Innerhalb einer Gesamtstruktur richten die DCs Trusts automatisch ein – bidirektional und transitiv. Nur zwischen verschiedenen Gesamtstrukturen (oder zu externen Domänen) müssen Trusts manuell eingerichtet werden. Verwaltet wird das über Active Directory-Domänen und -Vertrauensstellungen.

Hierarchie der Admin-Gruppen

Die privilegierten Gruppen sind nach Reichweite gestaffelt. Je weiter rechts, desto kritischer:

GruppeReichweiteBefugnis
Lokale AdministratorenEinzelner RechnerVollzugriff nur auf diesen Computer
Domänen-AdminsJe DomäneVollzugriff auf die gesamte Domäne
Organisations-/Enterprise-AdminsForestweit (nur Stammdomäne)Vollzugriff auf alle Domänen der Gesamtstruktur
Schema-AdminsForestweit (nur Stammdomäne)Dürfen das Schema ändern – kritisch, da dauerhaft & forestweit
Warnung: Das Administrator-Konto der Stammdomäne ist standardmäßig Mitglied in Domänen-Admins, Enterprise-Admins und Schema-Admins – damit das kritischste Konto der gesamten Gesamtstruktur. Schütze es besonders (eigenes komplexes Kennwort, MFA wo möglich, nur für Notfälle, niemals für Alltagsarbeit) und nutze für Schema-Änderungen eine zeitlich begrenzte Mitgliedschaft.
Active Directory

Subdomänen & Domänenbaum

Wächst eine Organisation, reicht eine einzelne Domäne oft nicht mehr aus. Über untergeordnete Domänen (Subdomänen) entsteht ein Domänenbaum (Tree) mit zusammenhängendem Namensraum. Die logische Grundhierarchie und die Vertrauenslogik sind in Strukturen, Gesamtstruktur & Vertrauensstellungen beschrieben – dieser Abschnitt vertieft den praktischen Lebenszyklus einer Subdomäne.

Baum-Struktur & Stammdomäne

Baut mindestens eine Domäne auf dem Namensraum einer anderen Domäne auf, liegt eine Baumstruktur (Tree) vor. Es existiert immer eine Stammdomäne (Root Domain), die als erste erstellt wird und den zentralen Anteil des Namensraums hält und vorgibt. Alle weiteren Domänen erweitern diesen als untergeordnete Subdomänen:

corp.example.com # Stammdomäne (Forest Root) – zuerst erstellt └── schulung.corp.example.com # untergeordnete (Child-)Domäne, erbt den Namensraum
Hinweis: Eine Subdomäne kann nur unter einer bereits existierenden Stammdomäne angelegt werden – die Stammdomäne muss also zuerst stehen. Der untergeordnete Name (schulung) wird vorangestellt, der übergeordnete Namensraum (corp.example.com) bleibt erhalten.

FSMO-Verteilung im Baum

Mit jeder neuen Domäne kommen Betriebsmaster (FSMO) hinzu. Entscheidend ist die Trennung nach Reichweite (Details und Verschiebung: FSMO-Rollen übertragen & übernehmen):

Rolle(n)ReichweiteVorkommen im Baum
Schemamaster + DomänennamenmasterGesamtstrukturweitGenau einmal – nur in der Stammdomäne. Beide ändern die forestweite Struktur; Best Practice: zusammen auf dem ersten DC der Stammdomäne belassen.
RID-Master, PDC-Emulator, InfrastrukturmasterDomänenweitIn jeder Domäne erneut – also auch in jeder neuen Subdomäne.
Hinweis: Der Infrastrukturmaster aktualisiert domänenübergreifende Objektverweise. Ist nicht jeder DC ein Globaler Katalog, sollte der Infrastrukturmaster nicht auf einem GC-Server liegen – sonst bemerkt er fehlende Verweise nicht. Sind alle DCs der Domäne GC, ist das unkritisch.

Untergeordnete Domäne anlegen

Im Server-Manager: Rolle „Active Directory-Domänendienste" installieren → Heraufstufungsassistent → „Neue Domäne zu vorhandener Gesamtstruktur hinzufügen" → Domänentyp „Untergeordnete Domäne" → übergeordnete Domäne und neuen Namen wählen. Schneller per PowerShell:

# DC der neuen Subdomäne "schulung.corp.example.com" heraufstufen Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSDomain -NewDomainName "schulung" ` # neuer untergeordneter Label -ParentDomainName "corp.example.com" ` # bestehende Stammdomäne -DomainType ChildDomain ` # untergeordnete Domäne im selben Baum -InstallDNS ` # DNS-Delegierung mit anlegen -Credential (Get-Credential) # Enterprise-Admin der Stammdomäne # Nach dem Heraufstufen: neue Domäne in der Gesamtstruktur sehen Get-ADForest | Select-Object -ExpandProperty Domains
Tipp: Das Anlegen einer Subdomäne erfordert ein Konto der Gruppe Organisations-/Enterprise-Admins (forestweit). Innerhalb einer Gesamtstruktur richten die DCs den Trust zur neuen Subdomäne automatisch ein – bidirektional und transitiv. Nur Trusts zu fremden Gesamtstrukturen müssen manuell konfiguriert werden.

Trusts der Subdomäne prüfen (GUI)

Nach dem Anlegen ist die transitive, bidirektionale Vertrauensstellung zwischen Stamm- und Subdomäne automatisch vorhanden. So sieht man sie nach:

  • Active Directory-Domänen und -Vertrauensstellungen (domain.msc) öffnen.
  • Rechtsklick auf die Domäne → Eigenschaften → Reiter „Vertrauensstellungen" – dort sind alle ein- und ausgehenden Trusts aufgelistet.
  • Über „Neue Vertrauensstellung…" startet der Assistent für manuelle Trusts (nur für externe/forest-übergreifende Vertrauensstellungen nötig).

Per PowerShell lässt sich derselbe Stand abfragen:

# Alle Vertrauensstellungen der aktuellen Domäne auflisten Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, IntraForest # Direction: BiDirectional | Inbound | Outbound # IntraForest = True → automatischer Trust innerhalb der Gesamtstruktur

Wann Subdomäne, wann besser nicht?

Spricht für eine SubdomäneSpricht dagegen (OU bevorzugen)
Eigene Domänen-Sicherheitsrichtlinie nötig (historisch; heute via PSO auch je Gruppe lösbar)Reine organisatorische Gliederung – das leisten OUs ohne zusätzliche DCs
Eigene Verwaltung/Delegation einer Teilorganisation mit eigenen AdminsDelegation ist auch per OU möglich, ohne neue Domäne zu betreiben
Trennung des Replikationsverkehrs großer, schlecht angebundener StandorteStandorttrennung löst man primär über Sites & Standortverknüpfungen
Tipp: Jede zusätzliche Domäne bedeutet eigene DCs, eigene FSMO-Rollen und mehr Replikations- und Betriebsaufwand. Moderne Empfehlung: möglichst eine Domäne und intern mit OUs strukturieren – Subdomänen nur, wenn echte Domänengrenzen (Verwaltung, Richtlinien, Replikation) zwingend gebraucht werden.
Active Directory

Benutzer & Gruppen

Benutzerkonten

Ein Benutzerkonto ist das zentrale Sicherheitssubjekt im AD. Jedes Objekt hat eine eindeutige, unveränderliche SID (Security Identifier) – Berechtigungen hängen an der SID, nicht am Namen. Wichtige Anmeldenamen:

  • UPN (User Principal Name): m.mueller@firma.local – modern, empfohlen, identisch zur E-Mail.
  • sAMAccountName: FIRMA\m.mueller – Pre-Windows-2000-Anmeldename (max. 20 Zeichen).
# Neues Benutzerkonto anlegen New-ADUser -Name "Max Mueller" -GivenName "Max" -Surname "Mueller" ` -SamAccountName "m.mueller" -UserPrincipalName "m.mueller@firma.local" ` -Path "OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" ` -AccountPassword (Read-Host -AsSecureString "Passwort") ` -Enabled $true -ChangePasswordAtLogon $true # Benutzer bearbeiten / deaktivieren / Gruppenmitgliedschaft Set-ADUser m.mueller -Department "Vertrieb" -Title "Sales Manager" Disable-ADAccount m.mueller Add-ADGroupMember "GG_Vertrieb" -Members m.mueller # Suche nach gesperrten oder inaktiven Konten Search-ADAccount -LockedOut Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00

Gruppentypen

Active Directory unterscheidet zwei Gruppentypen – nicht zu verwechseln mit dem Gruppenbereich:

TypZweckSID / Berechtigungen?
SicherheitsgruppeBerechtigungen auf Ressourcen vergeben (NTFS, Freigaben, AD)Ja – hat eine SID, kann in ACLs verwendet werden
VerteilergruppeReine E-Mail-Verteilerliste (z. B. Exchange)Nein – keine SID, keine Rechtevergabe möglich

Gruppenbereiche (Group Scopes)

Der Gruppenbereich steuert, woher die Mitglieder kommen dürfen und wo die Gruppe Berechtigungen erhalten kann:

BereichMögliche MitgliederBerechtigung nutzbar in
Global (G)Konten & globale Gruppen derselben DomäneGesamter Gesamtstruktur / vertrauten Domänen
Domänenlokal (DL)Konten/Gruppen aus allen Domänen der GesamtstrukturNur in der eigenen Domäne
Universal (U)Konten/Gruppen aus allen DomänenGesamter Gesamtstruktur – Mitgliedschaft im GC repliziert

AGDLP-Prinzip

Das AGDLP-Modell ist die Microsoft-Best-Practice zur Rechtevergabe und beschreibt die Verschachtelungskette:

  • Account → Benutzerkonto
  • Global Group → bündelt Konten nach Rolle/Organisation (z. B. „Vertrieb")
  • Domain Local Group → bündelt Zugriffsrechte auf eine Ressource (z. B. „Lesen Projektordner")
  • Permission → die Berechtigung wird an die domänenlokale Gruppe gebunden
Tipp: Berechtigungen immer nur an die domänenlokale Gruppe am Ende der Kette binden – nie direkt an Benutzer oder globale Gruppen. In Multi-Domain-/Multi-Forest-Umgebungen erweitert man auf AGUDLP (mit einer zusätzlichen universellen Gruppe).

Alternative: AGGP-Modell

Eine modernere Variante für Umgebungen mit einer Domäne und mehreren Standorten ist AGGP: Account → globale Funktionsgruppe (Function-Group, bündelt Konten nach Rolle) → globale Berechtigungsgruppe (Permission-Group, bündelt Rechte) → Permission. Statt domänenlokaler Gruppen kommen durchgehend globale Gruppen zum Einsatz – das hält den Kerberos-Token kleiner (weniger Gruppen-SIDs pro Anmeldung) und vereinfacht die Verwaltung, solange nur eine Domäne existiert. In Mehr-Domänen-Umgebungen bleibt AGDLP/AGUDLP die robustere Wahl.

# AGDLP praktisch umsetzen # 1) Globale Rollengruppe + domänenlokale Ressourcengruppe anlegen New-ADGroup -Name "GG_Vertrieb" -GroupScope Global -GroupCategory Security -Path "OU=Gruppen,DC=firma,DC=local" New-ADGroup -Name "DL_Projekte_RW" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Gruppen,DC=firma,DC=local" # 2) Konten in die globale Gruppe (Rolle) Add-ADGroupMember "GG_Vertrieb" -Members m.mueller, a.schmidt # 3) Globale Gruppe in die domänenlokale Gruppe verschachteln Add-ADGroupMember "DL_Projekte_RW" -Members "GG_Vertrieb" # 4) Berechtigung auf die Ressource an DL_Projekte_RW vergeben (NTFS) icacls "D:\Projekte" /grant "FIRMA\DL_Projekte_RW:(OI)(CI)M"

Fine-Grained Password Policies (PSO)

Lange galt: eine Domäne = eine Passwortrichtlinie. Mit Fine-Grained Password Policies (FGPP) lassen sich abweichende Passwort- und Sperrungs-Richtlinien für einzelne Benutzer oder – empfohlen – für Gruppen definieren, z. B. strengere Vorgaben für Administratoren. FGPP werden nicht über GPOs, sondern als Password Settings Objects (PSO) der Klasse msDS-PasswordSettings gesetzt (Windows Server 2016–2025).

RegelVerhalten
PrecedenceNiedrigerer Index gewinnt (z. B. 1 vor 10); jeder Index sollte eindeutig sein
Benutzer vor GruppeEin direkt am Konto verknüpftes PSO sticht jedes Gruppen-PSO
Resultant PSOAttribut msDS-ResultantPSO zeigt die effektiv geltende Richtlinie eines Kontos
# Strengeres PSO für Administratoren anlegen New-ADFineGrainedPasswordPolicy -Name "PSO_Admins" -Precedence 10 ` -MinPasswordLength 16 -PasswordHistoryCount 24 ` -MaxPasswordAge "60.00:00:00" -LockoutThreshold 5 ` -LockoutDuration "0.00:30:00" -ComplexityEnabled $true # PSO einer Gruppe zuweisen (Best Practice: Gruppe statt Einzeluser) Add-ADFineGrainedPasswordPolicySubject "PSO_Admins" -Subjects "GG_DomainAdmins" # Effektiv geltendes PSO eines Kontos prüfen Get-ADUserResultantPasswordPolicy -Identity m.mueller
Tipp: FGPP kennt keine Wörterbuch-/Sperrlisten und kann keine bereits kompromittierten Passwörter erkennen. Für Schutz gegen schwache und geleakte Passwörter kombiniert man FGPP mit Drittanbieter-Tools oder – im Hybrid-Betrieb – mit Entra Password Protection (gesperrte Begriffe global und benutzerdefiniert).
Active Directory

Massenanlage von Benutzern

Müssen viele Konten auf einmal angelegt werden – etwa zum Schuljahresbeginn oder bei einer neuen Abteilung – ist die Einzelanlage (siehe Benutzer & Gruppen) zu mühsam. Zwei bewährte Wege: das Vorlagenkonto für wenige, ähnliche Konten und der CSV-Import für echte Massenanlage.

Vorlagenkonto (Template)

Ein Vorlagenkonto ist ein vorbereitetes Benutzerkonto, dessen Eigenschaften beim Kopieren auf das neue Konto übernommen werden. So legt man es an:

  • Konto z. B. _Vorlage nennen – der führende Unterstrich sortiert es in der Liste nach oben.
  • Gemeinsame Eigenschaften vorab setzen: Gruppenmitgliedschaften, Anmeldezeiten, Home-Verzeichnis und Profilpfad.
  • In Pfaden den Platzhalter %username% statt eines festen Namens verwenden (z. B. \\srv\home\%username%) – beim Kopieren wird er automatisch durch den neuen Anmeldenamen ersetzt.
  • Im ADUC: Rechtsklick auf die Vorlage → „Kopieren…" → Name/Anmeldename des neuen Benutzers eingeben. Gruppen, Zeiten und Pfade werden mitübernommen.
Tipp: Das Vorlagenkonto selbst immer deaktivieren – es soll sich nie anmelden, sondern nur als Schablone dienen. Ein aktives Vorlagenkonto ist ein Sicherheitsrisiko.

CSV-Import per PowerShell

Für viele Konten liefert eine CSV-Datei (z. B. aus HR oder dem Schulverwaltungssystem) die Daten. Import-Csv liest sie ein, ForEach-Object legt pro Zeile ein Konto an. Die CSV braucht passende Spaltenüberschriften (hier: Name, SamAccountName, UPN, OU):

# Beispiel C:\user.csv: # Name,SamAccountName,UPN,OU # Max Mueller,m.mueller,m.mueller@firma.local,"OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" Import-Csv "C:\user.csv" | ForEach-Object { New-ADUser -Name $_.Name ` -SamAccountName $_.SamAccountName ` -UserPrincipalName $_.UPN ` -Path $_.OU ` -AccountPassword (ConvertTo-SecureString "Start#2024" -AsPlainText -Force) ` -Enabled $true }
Tipp: Vergib für die Massenanlage ein einheitliches Startkennwort und erzwinge die Änderung bei der ersten Anmeldung mit -ChangePasswordAtLogon $true. Für rollenbasierte Rechte die neuen Konten anschließend per Add-ADGroupMember den passenden globalen Gruppen zuweisen – siehe AGDLP-Prinzip.
Active Directory

Organisationseinheiten (OUs)

Was ist eine OU?

Eine Organisationseinheit (Organizational Unit, OU) ist ein Container innerhalb einer Domäne, der Objekte (Benutzer, Computer, Gruppen) gruppiert. OUs erfüllen genau zwei zentrale Zwecke:

  • Delegierung von Administration: Verwaltungsrechte können auf OU-Ebene an bestimmte Personen/Gruppen vergeben werden.
  • Verknüpfung von Gruppenrichtlinien (GPOs): Eine GPO wird mit einer OU verknüpft und wirkt auf deren Objekte.
Tipp: OUs sind keine Sicherheitsgrenzen – das ist nur die Gesamtstruktur. Und: An die Standard-Container CN=Users und CN=Computers lassen sich keine GPOs binden. Lege deshalb von Anfang an eigene OUs an und verschiebe Objekte dorthin (Redirektion mit redirusr / redircmp).

Struktur-Design

Die OU-Struktur sollte sich am Verwaltungs- und Richtlinienbedarf orientieren, nicht sklavisch am Organigramm der Firma – sonst zwingt jede Umstrukturierung im HR-Bereich zu ständigem Verschieben von Objekten. Zwei verbreitete Modelle:

ModellAufbauGeeignet für
Nach StandortTop-OU je Standort, darunter AbteilungenGeografisch verteilte Firmen mit lokalen Admins
Nach AbteilungTop-OU je Abteilung, darunter ggf. StandorteZentrale IT, einheitliche Richtlinien
Nach ObjekttypGetrennte OUs für Benutzer, Computer, ServerKlare GPO-Trennung (empfohlene Basis)

Best Practice ist eine Kombination: oberste Trennung nach Objekttyp, darunter nach Standort oder Abteilung. Beispielstruktur:

firma.local ├── OU=Benutzer │ ├── OU=Vertrieb │ ├── OU=IT │ └── OU=Verwaltung ├── OU=Computer │ ├── OU=Clients │ └── OU=Notebooks ├── OU=Server │ ├── OU=Fileserver │ └── OU=SQL └── OU=Gruppen ├── OU=Global └── OU=DomainLocal

Verschachtelung & Vererbung

OUs lassen sich verschachteln. GPOs und delegierte Rechte werden standardmäßig an untergeordnete OUs vererbt. Wenige, flache Ebenen sind besser – jede zusätzliche Ebene erhöht GPO-Verarbeitungszeit und Komplexität. Verwende eine klare, konsistente Namenskonvention (z. B. OU=Vertrieb, OU=Server_SQL).

Delegierung

Mit dem Assistenten zum Zuweisen der Objektverwaltung (oder per PowerShell/dsacls) erhält z. B. der Helpdesk das Recht, in einer bestimmten OU Passwörter zurückzusetzen – ohne Domänen-Admin zu sein. Delegiere immer auf der niedrigstmöglichen Ebene nach dem Prinzip der minimalen Rechte.

# Neue OU anlegen (Schutz vor versehentlichem Löschen ist Default) New-ADOrganizationalUnit -Name "Vertrieb" -Path "OU=Benutzer,DC=firma,DC=local" ` -ProtectedFromAccidentalDeletion $true # Verschachtelte OU New-ADOrganizationalUnit -Name "Innendienst" -Path "OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" # Objekt in eine OU verschieben Get-ADUser m.mueller | Move-ADObject -TargetPath "OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" # Delegierung: Helpdesk darf in OU Passwörter zurücksetzen (dsacls) dsacls "OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" /I:S /G "FIRMA\Helpdesk:CA;Reset Password;user"

OU-Inventur & Pflege per PowerShell

In gewachsenen Umgebungen sammeln sich verwaiste oder leere OUs an. Diese Befehle helfen, die Struktur sauber zu halten und vor versehentlichem Löschen zu schützen:

# Alle OUs samt Pfad und enthaltener Objektzahl auflisten Get-ADOrganizationalUnit -Filter * -Properties CanonicalName | Select-Object Name, CanonicalName, @{N="Objekte";E={ (Get-ADObject -SearchBase $_.DistinguishedName ` -SearchScope OneLevel -Filter *).Count }} | Sort-Object CanonicalName # Leere OUs finden (keine direkten Kindobjekte) Get-ADOrganizationalUnit -Filter * | Where-Object { -not (Get-ADObject -SearchBase $_.DistinguishedName -SearchScope OneLevel -Filter *) } | Select-Object DistinguishedName # Löschschutz nachträglich für ALLE OUs aktivieren (Best Practice) Get-ADOrganizationalUnit -Filter * | Set-ADObject -ProtectedFromAccidentalDeletion $true
Tipp: Der Löschschutz (ProtectedFromAccidentalDeletion) verhindert versehentliches Entfernen, blockiert aber auch das Verschieben per Drag & Drop in der Konsole. Zum gewollten Verschieben oder Löschen muss der Schutz vorher per -ProtectedFromAccidentalDeletion $false deaktiviert werden.
Active Directory

Replikation & Standorte

Die Replikation sorgt dafür, dass alle Domänencontroller einer AD-Infrastruktur denselben, konsistenten Datenstand haben. Ohne sie würde eine Änderung (Anlegen, Ändern, Löschen eines Objekts) nur auf dem DC festgehalten, auf dem sie durchgeführt wurde – das Verzeichnis liefe auseinander. AD nutzt Multi-Master-Replikation: An jedem beschreibbaren DC kann geändert werden, die Änderung wird anschließend verteilt. Repliziert werden u. a. Benutzerkonten, Gruppen, Computerkonten, OUs, Richtlinien- und Zertifikatsinformationen.

Das physische Replikationsmodell (Sites, Partitionen, KCC) ist auch für die Fehlersuche relevant und dort knapp zusammengefasst: Diagnose & Troubleshooting → Replikationskonzept. Hier steht die Architektur und der Betrieb im Vordergrund.

Standorte (Sites)

Ein Standort (Site) bildet die physische Struktur ab: ein oder mehrere gut angebundene Subnetze (ein LAN). Sites steuern, wie über teure WAN-Strecken repliziert wird, und werden grafisch mit dssite.msc verwaltet. Verwenden von Standorten bringt zwei Effekte:

  • Replikation: Innerhalb einer Site wird unkomprimiert und sofort repliziert; zwischen Sites komprimiert und nach Zeitplan – das schont die Bandbreite.
  • Authentifizierung: Anhand der Standortinformationen findet der Client einen nahen DC. So bleibt die Anmeldung schnell, und unnötiger DC-Verkehr über WAN-Strecken wird vermieden.

Replikationsmethoden: Intra-Site vs. Inter-Site

EigenschaftStandortintern (Intra-Site)Standortübergreifend (Inter-Site)
WoZwischen DCs desselben Standorts (LAN)Zwischen DCs verschiedener Standorte (WAN)
AuslöserNotification – automatisch & sofort bei ÄnderungFester Zeitplan, Standard alle 180 Min. (planbar)
KomprimierungNein (CPU schonen, LAN ist schnell)Ja ab >50 KB (WAN-Bandbreite schonen)
VermittlungDC zu DC direktÜber Bridgehead-Server je Standort
TransportprotokollRPC (IP)IP (RPC) – selten SMTP
Hinweis: Der Bridgehead-Server empfängt und sendet die Replikationsdaten eines Standorts gebündelt und verteilt sie lokal weiter. Aus Gründen der Ausfallsicherheit sollten je Standort mindestens zwei Bridgehead-Server möglich sein. Die SMTP-Replikation ist eine Sonderlösung für Standorte ohne durchgängige IP-Verbindung: Sie kann nur Schema-, Konfigurations- und Globaler-Katalog-Partitionen replizieren – nicht die Domänenpartition – und benötigt eine Zertifizierungsstelle. Standard und Empfehlung ist IP/RPC.

Replikationsversorgung: Pull-Prinzip

AD repliziert nach dem Pull-Prinzip: Ein DC holt sich Änderungen aktiv beim Partner ab – er bekommt sie nicht aufgedrängt. Zwei Modelle steuern, wann das passiert:

ModellVerhaltenEinsatz
Benachrichtigung (Notification)Der Quell-DC meldet dem Partner eine Änderung; dieser ruft die Daten daraufhin ab. Standard alle 15 Sekunden.Standortintern – nahezu sofortige Konvergenz
Abrufintervall (Polling)Der DC fragt nach festem Zeitplan beim Partner nach, ob es Änderungen gibt. Standard alle 180 Min.Standortübergreifend – planbarer WAN-Verkehr
Tipp: Repliziert werden nur die geänderten Attribute (Deltas), nicht ganze Objekte. Bei einem Konflikt entscheidet die höchste Versionsnummer des Attributs, bei Gleichstand der jüngste Zeitstempel. Ein RODC repliziert nur eingehend – er gibt nie Änderungen an andere DCs weiter.

Knowledge Consistency Checker (KCC)

Der KCC ist ein Prozess auf jedem DC, der die Replikationstopologie automatisch berechnet und pflegt – er erzeugt die Verbindungsobjekte (Connection Objects), über die DCs tatsächlich replizieren. So muss kein Administrator die Topologie von Hand verdrahten:

  • Standortintern baut der KCC einen bidirektionalen Ring auf – mit Querverbindungen, sobald mehr als drei DCs vorhanden sind, damit kein DC mehr als ≈3 Hops (Replikationssprünge) entfernt ist. Das hält Latenz und Replikationsgeschwindigkeit konstant gut.
  • Standortübergreifend erzeugt der ISTG (Inter-Site Topology Generator) – ein DC je Standort – die Verbindungen anhand der definierten Standortverknüpfungen und deren Kosten.
Hinweis: Die vom KCC erzeugten Verbindungsobjekte laufen unter NTDS Settings in dssite.msc. Man kann manuell eigene Verbindungsobjekte anlegen (z. B. um eine feste Replikationsroute zu erzwingen), sollte das aber nur in begründeten Fällen tun – der KCC respektiert manuelle Objekte und plant nur die übrige Topologie automatisch.

Standortverknüpfungen (Site Links)

Während die Verbindungsobjekte vom KCC automatisch erzeugt werden, müssen Standortverknüpfungen (Site Links) vom Administrator manuell eingerichtet werden. Sie definieren welche Standorte überhaupt miteinander replizieren dürfen und mit welchen Eigenschaften – der KCC/ISTG baut darauf die konkreten Pfade auf. Wichtige Parameter eines Site Links:

ParameterBedeutung
Kosten (Cost)Bewertet die „Güte" der Verbindung – niedrigere Kosten werden bevorzugt. Üblich an der Bandbreite orientiert (mehr Bandbreite → niedrigere Kosten).
ReplikationsintervallWie oft über diese Verknüpfung repliziert wird (Standard 180 Min.).
ZeitplanZeitfenster, in denen die Replikation erlaubt ist (z. B. nachts).

Die Kosten orientieren sich an der verfügbaren Bandbreite – je schneller die Leitung, desto günstiger der Pfad:

Verfügbare Bandbreite (KBit/s)Empfohlene Kosten
9,61042
64567
128486
256425
512378
1024340
2048309
4096283
Tipp: Die Option „Brücke zwischen allen Standortverknüpfungen herstellen" (Bridge all site links) ist standardmäßig aktiv. Sie erlaubt es, alle Site Links zu kombinieren, um den kostengünstigsten Gesamtweg zwischen zwei Sites zu berechnen (transitive Site Links). Sollen Standorte ausschließlich über explizit definierte Pfade replizieren, muss diese Option deaktiviert werden.

Replikation prüfen & steuern (PowerShell / repadmin)

Im Betrieb ist repadmin das Standardwerkzeug; ergänzend gibt es PowerShell-Cmdlets. Tiefergehende Diagnose-Befehle stehen im Abschnitt Diagnose & Troubleshooting.

repadmin /replsummary :: Übersicht Erfolg/Fehler je DC (Startpunkt) repadmin /showrepl :: detaillierter Replikationsstatus des DCs repadmin /syncall /AdeP :: alle Partitionen mit allen Partnern synchronisieren # Replikationspartner und letzte erfolgreiche Replikation per PowerShell Get-ADReplicationPartnerMetadata -Target "DC01" | Select-Object Partner, LastReplicationSuccess, LastReplicationResult # Replikation gezielt anstoßen (von DC02 die Domänenpartition holen) Sync-ADObject -Object "CN=m.mueller,OU=Vertrieb,DC=firma,DC=local" ` -Source "DC02" -Destination "DC01" # Standortverknüpfung anlegen (zwei Sites verbinden, Kosten + Intervall) New-ADReplicationSiteLink -Name "Berlin-Muenchen" ` -SitesIncluded "Berlin","Muenchen" -Cost 340 -ReplicationFrequencyInMinutes 180
Active Directory

Gruppenrichtlinien (GPO)

Was sind Gruppenrichtlinien?

Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) sind das zentrale Werkzeug, um Einstellungen für Benutzer und Computer im AD durchzusetzen – von Passwortrichtlinien über Laufwerkszuordnungen, Softwareverteilung und Desktop-Sperren bis hin zu Sicherheits-Baselines. Eine GPO besteht aus zwei Hälften:

  • Computerkonfiguration: wird beim Systemstart und alle 90 Minuten angewendet.
  • Benutzerkonfiguration: wird bei der Anmeldung angewendet.

Verknüpfung (Linking)

Eine GPO wirkt nur, wenn sie mit einem AD-Container verknüpft ist. Möglich sind drei Ebenen:

VerknüpfungsebeneWirkungsbereichTypischer Einsatz
Site (Standort)Alle Objekte eines physischen AD-StandortsStandortspezifisch (z. B. Proxy)
DomäneAlle Objekte der DomäneDomänenweite Baseline (z. B. Passwortrichtlinie)
OUObjekte der OU (und untergeordneter OUs)Gezielte Konfiguration pro Abteilung/Gerätetyp
Tipp: GPOs werden mit OUs verknüpft, nicht mit Sicherheitsgruppen. Soll eine GPO nur für bestimmte Mitglieder einer OU gelten, nutzt man das Security Filtering (Anwenden auf eine bestimmte Gruppe) oder einen WMI-Filter.

Verarbeitungsreihenfolge: LSDOU

Mehrere GPOs können dasselbe Objekt betreffen. Die Reihenfolge merkt man sich mit LSDOU – spätere überschreiben frühere bei Konflikten:

  1. Lokal – lokale Computerrichtlinie
  2. Site – Standort-GPOs
  3. Domäne – Domänen-GPOs
  4. OU – OU-GPOs (von der obersten zur tiefsten OU)

Da die OU als letztes verarbeitet wird, „gewinnt" sie normalerweise. Zwei wichtige Ausnahmen vom Standardverhalten:

OptionWirkung
Enforced (Erzwungen)Diese GPO setzt sich durch und kann von unteren Ebenen nicht überschrieben werden
Block InheritanceOU blockiert vererbte GPOs von oben (greift nicht bei Enforced-GPOs)
LinkreihenfolgeBei mehreren GPOs an derselben OU gewinnt die mit der niedrigsten Nummer (Link Order 1 zuletzt verarbeitet → höchste Priorität)
GPO-Verarbeitungsreihenfolge LSDOU mit Enforced und Block Inheritance
Abb. – GPO-Verarbeitung LSDOU: Local → Site → Domain → OU (spätere überschreiben frühere), plus Enforced und Block Inheritance

Verwaltung mit der GPMC

Zentrales Werkzeug ist die Gruppenrichtlinien-Verwaltungskonsole (GPMC) (gpmc.msc). Dort werden GPOs erstellt, bearbeitet, verknüpft, gefiltert, gesichert und mit dem Group Policy Modeling/Results-Assistenten getestet. Per PowerShell-Modul GroupPolicy lässt sich vieles automatisieren:

# Neue GPO erstellen und mit einer OU verknüpfen New-GPO -Name "GPO_Vertrieb_Sicherheit" New-GPLink -Name "GPO_Vertrieb_Sicherheit" ` -Target "OU=Vertrieb,OU=Benutzer,DC=firma,DC=local" -LinkEnabled Yes # Eine Registry-Einstellung setzen Set-GPRegistryValue -Name "GPO_Vertrieb_Sicherheit" ` -Key "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop" ` -ValueName "ScreenSaveTimeOut" -Type String -Value "600" # GPO sichern und Bericht erzeugen Backup-GPO -Name "GPO_Vertrieb_Sicherheit" -Path "C:\GPO-Backup" Get-GPOReport -All -ReportType Html -Path "C:\GPO-Report.html"

Anwendung & Prüfung am Client

gpupdate /force # Richtlinien sofort neu anwenden (Computer + Benutzer) gpupdate /target:user /logoff # nur Benutzerrichtlinien, danach abmelden gpresult /r # angewendete GPOs (Resultant Set of Policy) anzeigen gpresult /h C:\rsop.html # ausführlicher HTML-Bericht rsop.msc # grafische RSoP-Ansicht
Tipp: Wird eine GPO scheinbar nicht angewendet, prüfe mit gpresult /r die Abschnitte „Angewendete" und „Abgelehnte" GPOs. Häufige Ursachen: falsches Security Filtering, fehlende „Lesen+Anwenden"-Rechte, Block Inheritance oder ein WMI-Filter, der nicht zutrifft.

GPO-Inventur & Security Filtering

Verwaiste (nirgends verknüpfte) GPOs blähen die Verwaltung auf, und falsch gesetztes Security Filtering ist die häufigste Ursache für „GPO greift nicht". Diese Befehle helfen beim Aufräumen und Eingrenzen:

# Nicht verknüpfte GPOs finden (Kandidaten zum Löschen) Get-GPO -All | Where-Object { $report = Get-GPOReport -Guid $_.Id -ReportType Xml $report -notmatch "<LinksTo>" } | Select-Object DisplayName, CreationTime # Security Filtering: GPO nur für eine bestimmte Gruppe wirksam machen # 1) "Authenticated Users" als Apply-Recht entfernen, Lese-Recht behalten Set-GPPermission -Name "GPO_Vertrieb_Sicherheit" ` -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace # 2) Zielgruppe mit "Lesen + Anwenden" berechtigen Set-GPPermission -Name "GPO_Vertrieb_Sicherheit" ` -TargetName "GG_Vertrieb" -TargetType Group -PermissionLevel GpoApply
Tipp: Seit dem Sicherheitsupdate zu MS16-072 liest der Computer GPOs im Computer-Sicherheitskontext. Entfernt man „Authenticated Users" komplett aus dem Filtering, müssen die Zielcomputer (oder „Domain Computers") trotzdem mindestens Lese-Rechte auf die GPO behalten – sonst wird sie nicht mehr verarbeitet.
Active Directory

Azure AD / Microsoft Entra ID

Cloud-Identität: Was ist Entra ID?

Microsoft Entra ID ist der seit 2023 gültige Name für den früher als Azure Active Directory (Azure AD) bekannten Dienst. Es ist Microsofts cloudbasierter Identitäts- und Zugriffsverwaltungsdienst und die Authentifizierungsgrundlage für Microsoft 365, Azure und tausende SaaS-Anwendungen.

Tipp: „Azure AD" und „Entra ID" bezeichnen denselben Dienst – nur umbenannt. Microsoft 365- und Azure-Konten sind Entra-ID-Konten. Trotz des ähnlichen Namens ist Entra ID kein Cloud-gehostetes AD DS: Es gibt keine OUs, keine klassischen GPOs und kein Kerberos/LDAP im selben Sinne.

Entra ID vs. lokales AD DS

MerkmalLokales AD DSMicrosoft Entra ID
BetriebOn-premises (eigene DCs)Cloud-Dienst (Microsoft)
ProtokolleKerberos, NTLM, LDAPSAML, OAuth 2.0, OpenID Connect, SCIM
StrukturDomänen, OUs, ForestFlacher Tenant, keine OUs
RichtlinienGruppenrichtlinien (GPO)Conditional Access, Intune-Profile
GeräteDomänenbeitritt (Domain Join)Entra Join / Registrierung
Hardware-FokusLAN / klassischer PerimeterInternet / Zero Trust

Hybrid-Identität mit Entra Connect

Die meisten Unternehmen betreiben beides parallel. Microsoft Entra Connect (bzw. das leichtgewichtige Entra Cloud Sync) synchronisiert Benutzer, Gruppen und Passwort-Hashes vom lokalen AD in den Cloud-Tenant – so existiert ein Benutzer mit einem Login in beiden Welten. Drei Authentifizierungsmethoden stehen zur Wahl:

MethodeFunktionsweiseHinweis
Password Hash Sync (PHS)Hash des Passwort-Hashes wird in die Cloud synchronisiertEinfachste, robusteste Variante – empfohlen
Pass-Through Auth (PTA)Validierung erfolgt live gegen den lokalen DC via AgentPasswort verlässt das Haus nie
Federation (AD FS)Eigene Federation-InfrastrukturKomplex, nur für Sonderfälle

Mit Entra Hybrid Join werden domänenbeigetretene Geräte gleichzeitig in Entra ID registriert – Voraussetzung für Conditional Access auf Basis des Gerätestatus und nahtloses SSO.

SSO, MFA & Conditional Access

  • Single Sign-On (SSO): Einmal anmelden, alle verbundenen Cloud-Apps nutzen.
  • Multi-Faktor-Authentifizierung (MFA): Zweiter Faktor (Authenticator-App, FIDO2-Key, Passkey) – heute Pflicht-Baseline.
  • Conditional Access (Bedingter Zugriff): Regel-Engine nach „Wenn–Dann": Wenn Benutzer/Gruppe + App + Standort + Geräte- und Risikostatus, dann erlauben, blockieren oder MFA erzwingen. Kernbaustein einer Zero-Trust-Strategie.
# Verbindung zu Microsoft Graph / Entra ID herstellen Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All" # Cloud-Benutzer anlegen $pw = @{ Password = "Start#2026!"; ForceChangePasswordNextSignIn = $true } New-MgUser -DisplayName "Max Mueller" -UserPrincipalName "m.mueller@firma.onmicrosoft.com" ` -MailNickname "m.mueller" -AccountEnabled -PasswordProfile $pw # Gruppen / Mitgliedschaften New-MgGroup -DisplayName "Vertrieb-Cloud" -MailEnabled:$false -SecurityEnabled ` -MailNickname "vertrieb" -GroupTypes @() Get-MgUser -Filter "department eq 'Vertrieb'" | Select-Object DisplayName, UserPrincipalName # Status der Verzeichnis-Synchronisierung (klassisches MSOnline / AzureAD-Cmdlet) Get-ADSyncScheduler # Sync-Zeitplan von Entra Connect
Tipp: Die alten Module MSOnline und AzureAD sind abgekündigt. Verwende für neue Skripte das Microsoft Graph PowerShell SDK (Microsoft.Graph).

Pflicht-MFA & Conditional Access (Stand 2026)

Microsoft erzwingt seit 2024/2025 schrittweise MFA für administrative Portale (Azure-Portal, Entra-Admin-Center, Microsoft-365-Admin-Center) und weitet die Pflicht 2026 auf weitere Verwaltungsoberflächen aus. Reine Passwort-Anmeldung an Admin-Tools ist damit faktisch nicht mehr möglich – plane Authenticator-App, FIDO2-Keys oder Passkeys für alle privilegierten Konten ein.

Conditional Access ist die Regel-Engine dahinter. Eine typische Baseline-Richtlinie verlangt MFA für alle Benutzer außer von vertrauenswürdigen Standorten und schließt Notfall-Konten („Break-Glass") aus:

# Conditional-Access-Richtlinie per Graph anlegen (Beispielgerüst) Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess" $params = @{ DisplayName = "CA01 - MFA fuer alle Benutzer" State = "enabledForReportingButNotEnforced" # erst im Report-Modus testen! Conditions = @{ Users = @{ IncludeUsers = @("All"); ExcludeUsers = @("<BreakGlass-ObjectId>") } Applications = @{ IncludeApplications = @("All") } } GrantControls = @{ Operator = "OR"; BuiltInControls = @("mfa") } } New-MgIdentityConditionalAccessPolicy -BodyParameter $params
Tipp: Conditional-Access-Richtlinien immer zuerst im Report-only-Modus (enabledForReportingButNotEnforced) ausrollen und im Anmeldeprotokoll prüfen, bevor man auf enabled stellt. Lege mindestens zwei Break-Glass-Konten an, die von allen Richtlinien ausgenommen sind – sonst riskierst du, dich selbst auszusperren.
Active Directory

Sicherung & Wiederherstellung

Was muss gesichert werden?

Ein Domänencontroller wird über den Systemstatus (System State) gesichert. Er enthält alles, was den DC ausmacht:

  • die AD-Datenbank NTDS.dit mit Logdateien
  • den SYSVOL-Ordner (Gruppenrichtlinien, Anmeldeskripte)
  • Registry, Startdateien, ggf. die Zertifikatsdatenbank
Mehrere DCs ersetzen kein Backup. Replikation verteilt auch Fehler: Wird eine OU gelöscht, ist sie Sekunden später auf allen DCs weg. Pro Domäne mindestens einen DC regelmäßig sichern – Backups älter als die Tombstone Lifetime (Standard 180 Tage) sind unbrauchbar.

Systemstatus sichern mit Windows Server-Sicherung

# Feature installieren Install-WindowsFeature Windows-Server-Backup # Systemstatus auf ein separates Laufwerk sichern wbadmin start systemstatebackup -backupTarget:E: -quiet # Vorhandene Sicherungen anzeigen wbadmin get versions

Welche Wiederherstellung passt?

Entscheidungshilfe zwischen Papierkorb, nicht-autoritativer, autoritativer Wiederherstellung und Forest Recovery
Abb. – Von der schnellen Objektwiederherstellung bis zum Notfall für die ganze Gesamtstruktur

1 · Der AD-Papierkorb (Recycle Bin)

Mit aktiviertem Papierkorb bleiben gelöschte Objekte mit allen Attributen und Gruppenmitgliedschaften erhalten und lassen sich ohne Neustart zurückholen. Er ist standardmäßig aus – und das Einschalten ist nicht umkehrbar.

# Einmalig aktivieren (Gesamtstruktur-Funktionsebene mind. 2008 R2) Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target corp.example.com # Gelöschte Objekte finden und wiederherstellen Get-ADObject -Filter 'Name -like "Max*"' -IncludeDeletedObjects Get-ADObject -Filter 'Name -like "Max*"' -IncludeDeletedObjects | Restore-ADObject

Alternativ grafisch im Active Directory-Verwaltungscenter (dsac.exe) unter „Deleted Objects“.

2 · Nicht-autoritative Wiederherstellung

Ein defekter DC wird aus dem Backup zurückgespielt und holt sich alle neueren Änderungen anschließend per Replikation von den anderen DCs. Ablauf:

  1. DC im Verzeichnisdienst-Wiederherstellungsmodus (DSRM) starten: bcdedit /set safeboot dsrepair, Neustart.
  2. Mit dem lokalen DSRM-Kennwort anmelden (wird beim Heraufstufen festgelegt – gut dokumentieren!).
  3. Systemstatus zurückspielen: wbadmin start systemstaterecovery -version:<Version>
  4. Normalen Start wiederherstellen: bcdedit /deletevalue safeboot, Neustart.
Oft schneller: Bei mehreren DCs ist es häufig einfacher, den defekten DC sauber zu entfernen (Metadaten bereinigen) und einen neuen DC heraufzustufen.

3 · Autoritative Wiederherstellung

Wenn ein Fehler bereits auf alle DCs repliziert wurde und kein Papierkorb aktiv war: Nach der nicht-autoritativen Wiederherstellung (noch im DSRM) werden die betroffenen Objekte als „maßgeblich“ markiert. Ihre Versionsnummer wird erhöht, sodass sie die Löschung auf den anderen DCs überschreiben.

ntdsutil activate instance ntds authoritative restore restore subtree "OU=Vertrieb,DC=corp,DC=example,DC=com" quit quit

DSRM-Kennwort pflegen

ntdsutil set dsrm password reset password on server null # null = lokaler DC quit quit
Notfall-Checkliste: DSRM-Kennwörter aller DCs sicher dokumentiert · Systemstatus-Backups regelmäßig und offline · Papierkorb aktiviert · Wiederherstellung einmal in einer Testumgebung geübt.
Active Directory

Diagnose & Troubleshooting

Die drei Säulen: DNS, Replikation, Zeit

Die meisten AD-Probleme lassen sich auf drei Fundamente zurückführen. Prüfe bei jeder Störung systematisch in dieser Reihenfolge:

FundamentWarum kritisch?Typisches Symptom bei Fehler
DNSClients/DCs finden sich nur über DNS-SRV-RecordsAnmeldung schlägt fehl, „DC nicht erreichbar"
ReplikationAlle DCs müssen denselben Datenstand habenObjekt fehlt auf einem DC, Passwortänderung greift nicht
ZeitsynchronisationKerberos toleriert max. 5 Min. AbweichungKerberos-Fehler, „clock skew too great"

dcdiag – Gesundheitscheck des DCs

dcdiag führt eine Batterie von Tests gegen einen DC aus (Dienste, Replikation, DNS, FSMO-Erreichbarkeit) und ist der erste Griff bei AD-Problemen.

dcdiag # Standard-Tests auf dem lokalen DC dcdiag /v # ausführlich (verbose) dcdiag /test:dns /v # gezielter, umfassender DNS-Test dcdiag /test:replications # nur Replikationstests dcdiag /s:DC02 /test:fsmocheck # FSMO-Erreichbarkeit gegen DC02 prüfen

Replikationskonzept: Standorte, Partitionen & KCC

Bevor man Replikation diagnostiziert, hilft das Modell dahinter. Standorte (Sites) bilden die physische Topologie ab: ein Standort ist ein gut angebundener Bereich (ein oder mehrere Subnetze / ein LAN). AD steuert über Standorte, wie über langsame WAN-Strecken repliziert wird:

ReplikationsartAuslöserEigenschaften
Intra-Site (innerhalb eines Standorts)Notification (sofort bei Änderung)RPC, unkomprimiert – schnell, da LAN
Inter-Site (zwischen Standorten)Fester Zeitplan über Bridgehead-ServerIP (oder SMTP), komprimiert – schont das WAN

Repliziert wird die AD-Datenbank NTDS.DIT, die aus vier Partitionen besteht:

PartitionReichweiteInhalt
SchemaForestweitBauplan aller Objektklassen/Attribute
KonfigurationForestweitStandorte, Subnetze, Replikationstopologie
DomäneDomänenweitBenutzer, Computer, Gruppen, OUs
AnwendungsverzeichnisKonfigurierbarz. B. AD-integriertes DNS
Tipp: Repliziert werden nur Deltas (geänderte Attribute), nicht ganze Objekte. Der KCC (Knowledge Consistency Checker) baut die Topologie innerhalb eines Standorts automatisch als bidirektionalen Ring auf (mit Querverbindungen, damit kein DC mehr als ≈3 Hops entfernt ist). Ein RODC repliziert nur eingehend. Bei einem Konflikt gewinnt die höchste Versionsnummer des Attributs. Standorte und Verbindungen verwaltet man grafisch mit dssite.msc.

repadmin – Replikation prüfen & steuern

repadmin ist das Standardwerkzeug für die AD-Replikation. Damit sieht man, ob und wann DCs zuletzt erfolgreich repliziert haben.

repadmin /replsummary # Übersicht: Erfolg/Fehler je DC (Startpunkt!) repadmin /showrepl # detaillierter Replikationsstatus des DCs repadmin /replicate DC01 DC02 "DC=firma,DC=local" # Replikation manuell anstoßen repadmin /syncall /AdeP # alle Partitionen mit allen Partnern synchronisieren repadmin /queue # ausstehende Replikationsaufträge anzeigen

nltest – Secure Channel & DC-Lokalisierung

nltest /dsgetdc:firma.local # welchen DC nutzt der Client gerade? nltest /sc_query:firma.local # Status des sicheren Kanals (Secure Channel) nltest /sc_reset:firma.local # sicheren Kanal zurücksetzen nltest /dclist:firma.local # alle DCs der Domäne auflisten

DNS & Zeit verifizieren

# DNS – findet der Client die DC-SRV-Records? nslookup -type=SRV _ldap._tcp.dc._msdcs.firma.local Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.firma.local # Zeitsynchronisation prüfen (PDC-Emulator ist die Quelle der Domäne) w32tm /query /status # aktueller Zeitquellen-Status w32tm /query /source # woher kommt die Zeit? w32tm /resync # Zeit sofort neu synchronisieren w32tm /monitor # Zeitabweichung aller DCs überwachen

Häufige Fehlerbilder

SymptomWahrscheinliche UrsacheErste Maßnahme
Anmeldung dauert sehr lange / schlägt fehlFalscher DNS-Server am Client (z. B. Router statt DC)Client-DNS auf DC zeigen lassen, ipconfig /flushdns
„Vertrauensstellung fehlgeschlagen" am PCComputer-Konto-Passwort/Secure Channel kaputtTest-ComputerSecureChannel -Repair bzw. nltest /sc_reset
Änderungen kommen nicht auf allen DCs anReplikationsfehler (oft DNS- oder Firewall-Ursache)repadmin /replsummary, dann gezielt /showrepl
Kerberos-Fehler beim RessourcenzugriffZeitabweichung > 5 Min oder doppelter SPNw32tm /resync; SPN mit setspn -X prüfen
GPO wird nicht angewendetFiltering / Inheritance / WMI-Filtergpresult /r – „Abgelehnte GPOs" prüfen
Tipp: Faustregel der AD-Fehlersuche: „Es ist fast immer das DNS." Beginne jede Diagnose mit dcdiag /test:dns und der Kontrolle, dass alle Domänenmitglieder ausschließlich interne DCs als DNS-Server eingetragen haben – niemals den ISP- oder Router-DNS.

SYSVOL-Replikation (DFS-R) prüfen

SYSVOL hält Anmeldeskripte und GPO-Dateien und wird heute per DFS-Replikation (DFS-R) repliziert (das alte FRS ist abgekündigt). Stimmen GPOs auf verschiedenen DCs nicht überein, liegt oft ein SYSVOL-Replikationsproblem vor:

# Replizieren beide DCs SYSVOL? Freigaben müssen vorhanden sein Get-SmbShare | Where-Object { $_.Name -in "SYSVOL","NETLOGON" } # DFS-R-Backlog zwischen zwei DCs prüfen (0 = synchron) dfsrdiag Backlog /RGName:"Domain System Volume" ` /RFName:"SYSVOL Share" /SMem:DC01 /RMem:DC02 # DFS-R-Zustand und Fehler im Ereignisprotokoll Get-WinEvent -LogName "DFS Replication" -MaxEvents 20 | Where-Object LevelDisplayName -in "Error","Warning"

Gezielte Event-Log-Analyse

Die Ereignisanzeige ist bei tiefergehenden Problemen unverzichtbar. Diese Logs und IDs sind die häufigsten Anlaufstellen:

ProtokollEvent-IDBedeutung
Directory Service1311KCC kann konsistente Replikationstopologie nicht bilden
Directory Service2889Unsignierter/ungeschützter LDAP-Bind (vor LDAP-Signing-Erzwingung prüfen)
System5805 / 5723Computerkonto-Authentifizierung fehlgeschlagen (Secure Channel)
System (W32Time)50 / 36Zeitdienst-Probleme, Quelle nicht erreichbar
DFS Replication4012 / 5014SYSVOL-Replikation gestoppt / Verbindungsfehler
# Replikationsfehler 1311 gezielt im Directory-Service-Log suchen Get-WinEvent -FilterHashtable @{ LogName="Directory Service"; Id=1311 } -MaxEvents 10 | Format-List TimeCreated, Message