Active Directory – Grundlagen

Was ist Active Directory?

Active Directory (AD) ist der Verzeichnisdienst von Microsoft für Windows-Netzwerke. Kurz gesagt: AD ist das zentrale Gedächtnis deines Firmennetzwerks. Es weiss, wer du bist, was du darfst und auf welche Ressourcen du zugreifen kannst – und das alles, bevor du auch nur einen Ordner öffnest.

Ohne AD müsstest du auf jedem Server und jedem PC jeden Benutzer einzeln anlegen und Berechtigungen manuell setzen. Mit AD passiert das alles von einer zentralen Stelle aus. Du loggst dich einmal ein – an deinem Arbeitsplatz, auf dem Laptop, im Homeoffice via VPN – und hast überall Zugriff auf genau das, was für dich freigegeben ist.

In der Praxis läuft AD auf einem Domain Controller (DC), einem Windows Server mit der Rolle “Active Directory Domain Services (AD DS)”. Ein typisches KMU hat mindestens zwei DCs (einer für Redundanz), grössere Unternehmen oft mehrere pro Standort.

Die zentralen Konzepte

Domain

Eine Domain ist die logische Grundeinheit in AD. Sie hat einen DNS-basierten Namen, zum Beispiel firma.local oder firma.ch. Alle Objekte (User, Computer, Drucker, Gruppen) gehören zu einer Domain.

• Interne Domains enden oft auf .local oder .intern – das hat Nachteile beim Hybrid-Betrieb mit Microsoft 365 (UPN-Suffix-Probleme), weshalb neuere Setups lieber die echte Domain verwenden: firma.ch
• Der NetBIOS-Name (kurz, z.B. FIRMA) ist der ältere Name für ältere Protokolle und Legacy-Anwendungen

Forest und Tree

Ein Forest (Gesamtstruktur) ist der äusserste Container in AD – er fasst eine oder mehrere Domains zusammen. In kleinen KMU gibt es meistens genau einen Forest mit einer Domain.

• Tree (Domänenbaum): Mehrere Domains mit zusammenhängendem Namensraum, z.B. firma.ch und uk.firma.ch
• Forest: Mehrere Trees, die sich eine gemeinsame Schema-Datenbank teilen und sich gegenseitig vertrauen (Transitive Trusts)

Für den KMU-Alltag: Du wirst fast immer in einem Single-Domain-Forest arbeiten.

Domain Controller (DC)

Der Domain Controller ist der Server, auf dem AD DS läuft. Er:

• Authentifiziert Login-Versuche (ist dieses Passwort korrekt?)
• Autorisiert Zugriffe (darf dieser User diesen Ordner öffnen?)
• Repliziert Änderungen an alle anderen DCs in der Domain
• Hostet wichtige Dienste wie DNS, SYSVOL und NETLOGON

OU – Organizational Unit

OUs sind die Ordnerstruktur innerhalb deiner Domain. Du organisierst damit deine AD-Objekte logisch – typischerweise nach Standort, Abteilung oder Funktion:

firma.ch
├── Benutzer
│   ├── Verwaltung
│   ├── IT
│   └── Produktion
├── Computer
│   ├── Workstations
│   └── Server
└── Dienstkonten

OUs haben zwei Hauptzwecke:

1. Übersicht – du findest Objekte schnell wieder
2. GPO-Verknüpfung – Group Policy Objects werden an OUs gehängt und gelten dann für alle Objekte darunter (siehe GPO-Grundlagen)

Objekte in AD

AD speichert alles als Objekte. Die wichtigsten:

Wie Authentifizierung mit Kerberos funktioniert

AD verwendet Kerberos als primäres Authentifizierungsprotokoll (Port 88/TCP+UDP). Der grosse Vorteil: Passwörter werden nie im Klartext übers Netzwerk übertragen.

Das vereinfachte Prinzip:

1. AS-REQ: Du gibst dein Passwort ein. Dein PC sendet eine verschlüsselte Anfrage an den Key Distribution Center (KDC) auf dem DC.
2. AS-REP / TGT: Der DC antwortet mit einem Ticket Granting Ticket (TGT) – einem verschlüsselten “Ausweis”, gültig für 10 Stunden (Standard).
3. TGS-REQ: Willst du auf einen Server zugreifen, schickst du deinen TGT an den KDC und fragst nach einem Service Ticket.
4. TGS-REP: Du bekommst ein Service Ticket für genau diesen Server.
5. Zugriff: Du zeigst das Service Ticket dem Zielserver. Der Server vertraut dem Ticket, weil es vom DC signiert ist – kein weiterer Passwort-Check nötig.

Dieses Prinzip nennt sich Single Sign-On (SSO): einmal einloggen, überall Zugriff (solange du berechtigt bist). Kerberos ist der Grund, warum du dich am Morgen einmal anmeldest und den ganzen Tag auf Fileserver, Drucker und Intranet zugreifen kannst, ohne je wieder ein Passwort einzugeben.

LDAP – wie AD abgefragt wird

LDAP (Lightweight Directory Access Protocol) ist das Protokoll, über das AD-Informationen gelesen und geschrieben werden. Port 389 (unverschlüsselt) bzw. 636 (LDAPS, verschlüsselt).

Anwendungen (ERP-Systeme, VPN-Appliances, Ticketsysteme) nutzen LDAP, um AD zu fragen: “Gibt es einen Benutzer mit diesem Login? In welchen Gruppen ist er?” Das ist die Basis für die AD-Integration in fast jede Unternehmenssoftware.

Ein LDAP-Pfad sieht so aus:

CN=Max Muster,OU=Verwaltung,OU=Benutzer,DC=firma,DC=ch

• CN = Common Name (Name des Objekts)
• OU = Organizational Unit
• DC = Domain Component (ein Teil des Domain-Namens)

In der Praxis musst du LDAP-Pfade kennen, wenn du eine Anwendung ans AD anschliesst – zum Beispiel ein NAS, einen Mailserver oder ein Helpdesk-System. Der sogenannte Bind-Account (ein Dienstkonto mit Leserechten) und der Base-DN (ab wo gesucht wird) sind die zwei Pflichtangaben.

Die AD-Datenbank: NTDS.dit

Die gesamte AD-Datenbank steckt in einer einzigen Datei: C:\Windows\NTDS\ntds.dit. Sie ist die JET-Datenbankdatei, die alle Objekte, Attribute und Passwort-Hashes enthält.

Wichtige Dateien auf dem DC:

AD-Papierkorb, Tombstone-Lifetime und Wiederherstellung gelöschter Objekte

Löschst du in AD ein Objekt (User, Gruppe, ganze OU), verschwindet es nicht sofort unwiederbringlich. AD kennt einen mehrstufigen Lebenszyklus für gelöschte Objekte:

1. Live-Objekt – normal vorhanden und repliziert.
2. Gelöscht / Recycled – nur wenn der AD-Papierkorb aktiviert ist. Das Objekt behält alle Attribute (inkl. Gruppenmitgliedschaften), wird aber in den Container CN=Deleted Objects verschoben und ist für normale Ansichten unsichtbar.
3. Tombstone – das Objekt verliert die meisten Attribute (nur noch ein “Skelett” bleibt übrig, damit die Löschung an alle DCs repliziert werden kann), bleibt aber für die Dauer der Tombstone-Lifetime im Verzeichnis. Seit Windows Server 2003 SP1 liegt der Standardwert bei 180 Tagen; ältere, hochgezogene Forests können noch auf 60 Tagen stehen.
4. Garbage Collection – nach Ablauf der Tombstone-Lifetime entfernt der periodisch laufende Garbage-Collection-Prozess das Objekt endgültig und unwiederbringlich.

Aktuelle Tombstone-Lifetime abfragen:

$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$config" -Property tombstoneLifetime |
  Select-Object tombstoneLifetime

AD-Papierkorb aktivieren

Der AD-Papierkorb (seit Windows Server 2008 R2) macht die Wiederherstellung massiv einfacher, weil gelöschte Objekte mit allen Attributen zurückkommen – nicht nur mit dem mageren Tombstone-Rest. Voraussetzung: Forest-Funktionsebene Windows Server 2008 R2 oder höher.

Enable-ADOptionalFeature 'Recycle Bin Feature' `
  -Scope ForestOrConfigurationSet `
  -Target firma.ch

Gelöschte Objekte wiederherstellen

Einzelnes Objekt (z.B. einen versehentlich gelöschten User):

Get-ADObject -Filter {displayName -eq "Max Muster"} -IncludeDeletedObjects |
  Restore-ADObject

Eine ganze gelöschte OU inklusive aller Kinder-Objekte – die Reihenfolge ist wichtig: zuerst die OU selbst, danach die Kinder:

# 1. Die OU selbst wiederherstellen
$ou = Get-ADObject -Filter {objectClass -eq "organizationalUnit" -and name -eq "Verwaltung"} `
  -IncludeDeletedObjects
$ou | Restore-ADObject

# 2. Alle direkten Kinder-Objekte wiederherstellen (User, Gruppen, Sub-OUs)
Get-ADObject -Filter {isDeleted -eq $true -and lastKnownParent -eq $ou.DistinguishedName} `
  -IncludeDeletedObjects | Restore-ADObject

Ohne aktivierten AD-Papierkorb bleibt nur die klassische Tombstone-Reanimation – sie funktioniert nur innerhalb der Tombstone-Lifetime und bringt viele Attribute (z.B. Gruppenmitgliedschaften) nicht zurück. Für eine vollständige Wiederherstellung brauchst du dann ein System State Backup, siehe Windows Server Backup.

FSMO-Rollen

AD ist Multi-Master: jeder DC kann Änderungen annehmen. Für bestimmte Aufgaben gibt es jedoch Ausnahmen – diese sogenannten FSMO-Rollen (Flexible Single Master Operations) darf nur ein einziger DC pro Domain (oder Forest) übernehmen:

In einem KMU-Umfeld mit einem einzigen DC liegen alle fünf Rollen auf diesem einen Server. Bei zwei DCs macht es Sinn, den PDC Emulator auf dem “stärkeren” DC zu lassen.

Aktuelle FSMO-Rolleninhaber abfragen:

# Alle FSMO-Rollen anzeigen
netdom query fsmo

# Oder via PowerShell
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

Schema-Erweiterungen: wann nötig, welche Risiken

Das AD-Schema definiert forest-weit, welche Objektklassen (z.B. User, Computer) und Attribute (z.B. mail, telephoneNumber) überhaupt existieren dürfen. Eine Schema-Erweiterung fügt neue Klassen oder Attribute hinzu – meist ausgelöst durch die Installation bestimmter Software:

Praktisches Vorgehen für eine Schema-Erweiterung:

1. Mitgliedschaft in Schema Admins ist nötig – diese Gruppe sollte im Normalbetrieb leer sein, ein Mitglied nur temporär für die Dauer der Erweiterung hinzufügen und danach sofort wieder entfernen.
2. Die Erweiterung muss auf dem DC mit der Schema-Master-FSMO-Rolle ausgeführt werden (siehe oben, netdom query fsmo).
3. Schema-Updates müssen aktiv erlaubt sein (Registry-Wert Schema Update Allowed unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, oder direkt im Schema-Snap-In aktivierbar).
4. Vendor-Tools führen die Erweiterung meist automatisiert aus (z.B. setup /PrepareSchema bei Exchange). Manuelle Erweiterungen über LDIF-Dateien:

ldifde -i -f schema-extension.ldf -c "DC=X" "DC=firma,DC=ch"

5. Nach der Erweiterung: Replikation an alle DCs abwarten (repadmin /replsummary), dann die Schema-Admins-Mitgliedschaft wieder entfernen.

AD-Sites, Subnets und die Replikationstopologie

Sobald du mehr als einen Standort hast (Hauptsitz plus Filiale, Rechenzentrum plus Aussenstelle), solltest du AD-Sites konfigurieren. Eine Site bildet einen physischen Standort mit guter interner Netzwerkanbindung ab (typischerweise ein LAN) und steuert zwei Dinge:

• Client-Zuweisung: Anmeldende Clients suchen sich automatisch den nächstgelegenen DC bzw. Global Catalog anhand ihrer Site, statt quer über eine langsame WAN-Leitung zu authentifizieren
• Replikationstopologie: Wie und wann Änderungen zwischen DCs an verschiedenen Standorten repliziert werden

Subnets

Ein Subnet-Objekt (z.B. 10.10.0.0/24) wird in AD Sites and Services (dssite.msc) einer Site zugeordnet. Damit weiss AD: “Ein Client aus diesem IP-Bereich gehört zur Site Bern.” Ohne korrekt gepflegte Subnets landen Clients im falschen Standort und authentifizieren unnötig über die WAN-Leitung.

New-ADReplicationSite -Name "Bern"
New-ADReplicationSubnet -Name "10.20.0.0/24" -Site "Bern"

Intra-Site- vs. Inter-Site-Replikation

KCC – Knowledge Consistency Checker

Der KCC läuft auf jedem DC und berechnet automatisch die Replikationstopologie: Er legt fest, welcher DC mit welchem anderen eine Replikationsverbindung (Connection Object) hat, mit dem Ziel, dass eine Änderung nie mehr als drei Hops braucht, um jeden DC in der Site zu erreichen. Standardmässig rechnet der KCC alle 15 Minuten neu; manuell erzwingen:

repadmin /kcc

Für Inter-Site-Verbindungen wählt ein pro Site gewählter Inter-Site Topology Generator (ISTG) die Verbindungen zwischen Standorten.

Bridgehead-Server

Pro Site und pro Verzeichnispartition (Domain, Schema, Configuration, Global Catalog) bestimmt der KCC automatisch genau einen DC als Bridgehead-Server – nur dieser tauscht Änderungen mit anderen Standorten aus, damit nicht jede Änderung über jede WAN-Leitung mehrfach geschickt wird. Manuell festlegbar (z.B. um Firewall-Regeln auf einen bestimmten Server zu begrenzen) über dssite.msc, am DC-Objekt unter “Preferred Bridgehead Server hinzufügen für”.

Site-Links

Ein Site-Link verbindet zwei oder mehr Sites und definiert, wie oft und über welchen Pfad repliziert wird:

New-ADReplicationSiteLink -Name "Hauptsitz-Bern" `
  -SitesIncluded "Default-First-Site-Name","Bern" `
  -Cost 100 -ReplicationFrequencyInMinutes 15

Read-Only Domain Controller (RODC) für Aussenstellen

Für kleine Filialen oder Aussenstellen mit schwacher physischer Sicherheit (Server im Abstellraum statt im verschlossenen Rechenzentrum) oder unzuverlässiger WAN-Anbindung bietet sich ein Read-Only Domain Controller (RODC) an – seit Windows Server 2008 verfügbar.

Ein RODC hält eine schreibgeschützte Kopie der AD-Datenbank:

• Unidirektionale Replikation: Der RODC empfängt Änderungen nur von einem schreibbaren DC (inbound-only). Selbst wenn ein Angreifer den RODC physisch in die Hände bekommt und manipuliert, können keine böswilligen Änderungen zurück in die restliche Domain repliziert werden.
• Keine gecachten Passwörter per Default: Die Password Replication Policy (PRP) legt fest, welche Benutzer- oder Computerpasswörter lokal auf dem RODC zwischengespeichert werden dürfen. Standardmässig cacht die “Denied RODC Password Replication Group” (u.a. Domain Admins, Enterprise Admins, Schema Admins, krbtgt) nichts; gezielt fügst du lokale Filial-User zur “Allowed”-Liste hinzu.
• Filtered Attribute Set (FAS): Besonders sensible Attribute (z.B. BitLocker-Recovery-Keys, LAPS-Passwörter) repliziert Microsoft standardmässig nie an einen RODC – unabhängig von der PRP.
• Eigenes krbtgt-Konto: Jeder RODC bekommt ein eigenes krbtgt_XXXX-Konto, damit eine Kompromittierung des RODC nicht das Kerberos-Vertrauen der ganzen Domain gefährdet.
• Administrator Role Separation: Du kannst einer Person vor Ort lokale Admin-Rechte auf dem RODC geben, ohne ihr Domain-Admin-Rechte einzuräumen – praktisch, wenn in der Filiale niemand von der zentralen IT sitzt. Das passt zum Prinzip der Rollentrennung, siehe auch AD Security Hardening & Tier-Modell.

Voraussetzungen: Forest-Funktionsebene Windows Server 2003 oder höher, mindestens ein schreibbarer DC mit Windows Server 2008 oder neuer in derselben Domain.

# Passwort-Replikationsrichtlinie einsehen
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC-BERN -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC-BERN -Denied

# Eine Filial-Gruppe zur erlaubten Liste hinzufügen
Add-ADDomainControllerPasswordReplicationPolicy -Identity RODC-BERN `
  -AllowedList "GRP-Bern-Mitarbeiter"

Die wichtigsten Admin-Tools

dsa.msc – Active Directory Users and Computers (ADUC)

Das Hauptwerkzeug für die tägliche AD-Verwaltung. Hier legst du User an, setzt Passwörter zurück, organisierst OUs und verwaltest Gruppen.

Öffnen: Win+R, dann dsa.msc eingeben.

Wichtig: ADUC zeigt standardmässig nicht alle Objekte. Um versteckte Objekte und erweiterte Attribute zu sehen: Ansicht > Erweiterte Features aktivieren.

gpmc.msc – Group Policy Management Console

Für das Erstellen, Bearbeiten und Verknüpfen von GPOs. Ohne diese Konsole ist das Verwalten von Gruppenrichtlinien sehr mühsam. Mehr dazu auf der Seite GPO-Grundlagen.

dssite.msc – AD Sites and Services

Für Multi-Standort-Umgebungen: Hier konfigurierst du AD-Sites (physische Standorte) und Replikations-Verbindungen zwischen DCs.

PowerShell (RSAT)

Für alles, was in der GUI zu langsam oder zu manuell wäre. Das Active Directory-Modul für PowerShell ist Teil der RSAT-Tools (Remote Server Administration Tools).

RSAT auf Windows 10/11 installieren:

# RSAT AD-Tools installieren (als Admin)
Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"

Danach stehen alle *-AD*-Cmdlets zur Verfügung.

Praktische PowerShell-Befehle für den Alltag

# === Domain-Informationen ===
Get-ADDomain                                    # Domain-Details
Get-ADForest                                    # Forest-Details
Get-ADDomainController -Filter *               # Alle DCs auflisten

# === Benutzer-Suche und -Info ===
Get-ADUser -Identity "mmuster"                 # Einen User abfragen
Get-ADUser -Filter {Name -like "Max*"}         # User nach Namen suchen
Get-ADUser -Filter * -SearchBase "OU=IT,OU=Benutzer,DC=firma,DC=ch"  # Nur in einer OU

# === Gesperrte Konten finden und entsperren ===
Search-ADAccount -LockedOut                    # Alle gesperrten Accounts
Unlock-ADAccount -Identity "mmuster"           # Account entsperren

# === Passwort zurücksetzen ===
Set-ADAccountPassword -Identity "mmuster" -Reset `
  -NewPassword (ConvertTo-SecureString "Temp!Pass23" -AsPlainText -Force)
Set-ADUser -Identity "mmuster" -ChangePasswordAtLogon $true

# === Replikation prüfen ===
repadmin /replsummary                          # Replikationsstatus
repadmin /showrepl                             # Detaillierte Replikations-Infos
dcdiag /test:replications                      # DC-Diagnose: Replikation

# === SYSVOL-Replikation (DFSR) prüfen ===
dfsrdiag ReplicationState

Vertiefte Diagnose: dcdiag und repadmin richtig lesen

dcdiag und repadmin liefern schnell viele Zeilen Output – die Kunst ist, die relevanten Zeilen zu erkennen.

dcdiag – Gesundheitscheck eines DCs

C:\> dcdiag /v

Verzeichnisserverdiagnose

Testen des Servers: Default-First-Site-Name\DC01
   Sternenstart-Tests

   Testen des Servers: Default-First-Site-Name\DC01
      Starting test: Connectivity
         ......................... DC01 hat den Test Connectivity bestanden

   Sternentests für den Server DC01
      Starting test: Advertising
         ......................... DC01 hat den Test Advertising bestanden
      Starting test: FrsEvent
         ......................... DC01 hat den Test FrsEvent bestanden
      Starting test: DFSREvent
         ......................... DC01 hat den Test DFSREvent bestanden
      Starting test: NCSecDesc
         ......................... DC01 hat den Test NCSecDesc bestanden
      Starting test: NetLogons
         ......................... DC01 hat den Test NetLogons bestanden
      Starting test: Replications
         ......................... DC01 hat den Test Replications bestanden
      Starting test: RidManager
         ......................... DC01 hat den Test RidManager bestanden
      Starting test: Services
         ......................... DC01 hat den Test Services bestanden
      Starting test: SysVolCheck
         ......................... DC01 hat den Test SysVolCheck bestanden
      Starting test: KccEvent
         ......................... DC01 hat den Test KccEvent bestanden
      Starting test: MachineAccount
         ......................... DC01 hat den Test MachineAccount bestanden

Die wichtigsten Tests im Überblick:

Für einen gezielten Check statt des kompletten Durchlaufs:

dcdiag /test:replications /test:dns /test:advertising /v

repadmin – Replikationsstatus im Detail

C:\> repadmin /replsummary

Replikationszusammenfassung starten für DC01
...
Quelle DSA          groesste Delta   Fehler/Insgesamt  %  Fehler
DC01                 00:14:32       0 /   5          0
DC02                 00:15:01       0 /   5          0
RODC-BERN            00:32:10       1 /   5         20  (1461) Der Vorgang konnte auf diesem Server aufgrund keines vorhandenen Objekts nicht ausgeführt werden.

Ein hoher Delta-Wert (Zeit seit letzter erfolgreicher Replikation) oder eine Fehlerquote grösser als 0 Prozent ist ein klares Alarmzeichen. Für die Fehlersuche im Detail:

# Nur Fehler anzeigen, über alle DCs
repadmin /showrepl * /errorsonly

# Für die Auswertung in Excel exportieren
repadmin /showrepl * /csv > C:\Temp\replstatus.csv

# Replikation für eine Partition sofort erzwingen
repadmin /syncall /AdeP

# RPC-Erreichbarkeit zwischen zwei DCs testen
repadmin /bind DC02

Typische Fehlercodes: 8524 (kein DNS-Eintrag für Ziel-DC gefunden), 1722 (RPC-Server nicht erreichbar, meist eine Firewall), 8606 (nicht genug Replikationspartner, bei Single-DC-Domains normal), 1256 (Zielserver antwortet nicht, Netzwerk oder DC down).

Troubleshooting – häufige Probleme

Benutzer kann sich nicht anmelden

1. Konto gesperrt? → Search-ADAccount -LockedOut ausführen, ggf. Unlock-ADAccount
2. Passwort abgelaufen? → In ADUC: Benutzer > Eigenschaften > Konto > Passwortoptionen
3. Konto deaktiviert? → In ADUC: grauer Pfeil-Icon = deaktiviert
4. DC nicht erreichbar? → nltest /dsgetdc:firma.ch zeigt, welcher DC geantwortet hat
5. Uhrzeit falsch? → Kerberos toleriert maximal 5 Minuten Zeitabweichung. w32tm /query /status auf Client und DC prüfen

Replikation schlägt fehl

# Replikationsfehler anzeigen
repadmin /showrepl * /errorsonly

# Replikation erzwingen
repadmin /syncall /AdeP

Häufige Ursachen: Netzwerkprobleme zwischen DCs, DNS-Fehler, abgelaufene Zertifikate, Zeitdifferenzen.

DNS-Probleme mit AD

AD ist stark DNS-abhängig. Fast alle AD-Probleme lassen sich auf DNS zurückführen. Prüfe:

# SRV-Records prüfen (werden bei DC-Promotion automatisch erstellt)
Resolve-DnsName _ldap._tcp.firma.ch -Type SRV
Resolve-DnsName _kerberos._tcp.firma.ch -Type SRV

# Umfassende DC-Diagnose
dcdiag /test:dns /v

Mehr zu DNS findest du auf der Seite DNS-Grundlagen.

Computerkonto ist abgelaufen oder beschädigt

Wenn sich ein PC nicht mehr an der Domain anmelden kann (Fehlermeldung: “Vertrauensbeziehung zwischen Arbeitsstation und primärer Domäne fehlgeschlagen”):

# Computerkonto zurücksetzen (auf dem betroffenen PC als lokaler Admin)
Test-ComputerSecureChannel -Repair -Credential (Get-Credential "FIRMA\Admin")

Alternativ: PC aus der Domain entfernen, Computerkonto in AD löschen, PC neu der Domain beitreten.

AD-Health-Monitoring automatisieren

Warte nicht, bis sich jemand beschwert, um zu merken, dass die Replikation seit drei Tagen steht. Ein einfaches, geplantes PowerShell-Skript, das täglich dcdiag und repadmin auf allen DCs ausführt und das Ergebnis per Mail zusammenfasst, reicht in den meisten KMU-Umgebungen völlig aus – dedizierte Monitoring-Suiten (siehe Monitoring-Grundlagen) sind für eine Handvoll DCs oft überdimensioniert.

# AD-Health-Check.ps1 - als geplanter Task taeglich morgens ausfuehren
$DCs = (Get-ADDomainController -Filter *).HostName
$report = foreach ($dc in $DCs) {
    $diag = dcdiag /s:$dc /test:advertising /test:netlogons /test:replications 2>&1
    $failed = $diag | Select-String "failed test"
    [PSCustomObject]@{
        DC      = $dc
        Status  = if ($failed) { "FEHLER" } else { "OK" }
        Details = ($failed -join "; ")
    }
}

$replFails = repadmin /replsummary /errorsonly

$body  = $report | ConvertTo-Html -Property DC, Status, Details -Fragment
$body += "<h3>Replikationsfehler</h3><pre>$($replFails -join "`n")</pre>"

$hatFehler = $report | Where-Object { $_.Status -eq "FEHLER" }
$betreff   = "AD-Health-Report $(Get-Date -Format 'dd.MM.yyyy')"
if ($hatFehler) { $betreff += " - FEHLER GEFUNDEN" }

Send-MailMessage -From "ad-monitor@firma.ch" -To "it@firma.ch" `
  -SmtpServer "smtp.firma.ch" -Subject $betreff -Body $body -BodyAsHtml

Als geplanten Task einrichten (täglich um 06:00 Uhr, Details siehe Task Scheduler):

$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument "-NoProfile -File C:\Scripts\AD-Health-Check.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At 6am
Register-ScheduledTask -TaskName "AD-Health-Check" -Action $action `
  -Trigger $trigger -User "FIRMA\svc-monitoring" -RunLevel Highest

AD im KMU-Alltag: Typisches Setup

Ein typisches KMU (50–200 Mitarbeitende) sieht so aus:

• 2× Windows Server als DC (einer physisch, einer als VM)
• AD-integriertes DNS auf beiden DCs
• DHCP entweder auf einem der DCs oder auf dem Router/Firewall
• Alle Workstations und Laptops sind Mitglied der Domain
• Benutzer loggen sich mit ihrem user@firma.ch-Konto ein
• Fileserver-Berechtigungen laufen über AD-Gruppen (nie direkte User-Berechtigungen!)
• GPOs steuern Sicherheitsrichtlinien, Laufwerksmappings und Software-Einstellungen
• Gibt es eine Filiale oder Aussenstelle mit eigenem Netzwerk, kommt zusätzlich eine eigene AD-Site (eventuell mit RODC) dazu

Für die Benutzerverwaltung (User anlegen, in Gruppen aufnehmen, Passwörter zurücksetzen) geht es weiter auf der Seite AD – User & Gruppen verwalten. Wenn du wissen willst, wie du mit GPOs Einstellungen ausrollst, lies GPO-Grundlagen.

Weiterlernen

• Übersicht über Active Directory Domain Services – Microsoft Learn
• Active Directory-Replikationskonzepte – Microsoft Learn
• Best Practices für die Sicherung von Active Directory – Microsoft Learn
• Verwalten von AD DS mit PowerShell – Microsoft Learn
• Grundlegende lokale AD- und Microsoft Entra-Umgebung (Hybrid) – Microsoft Learn
• Active Directory-Papierkorb – Microsoft Learn
• Planung von Active Directory-Standorten und -Diensttopologie – Microsoft Learn
• Read-Only Domain Controllers Overview – Microsoft Learn
• Erweitern des Active Directory-Schemas – Microsoft Learn

Videos

YouTube

YouTube