Active Directory ist das Rückgrat der zentralen Benutzer- und Rechteverwaltung in praktisch jedem Windows-geprägten Unternehmensnetzwerk. Genau in diesem Kontext ist auch dieses Lab entstanden: Ein Windows Server wurde von Grund auf zum Domänencontroller aufgebaut, um den vollständigen Ablauf einmal durchzuspielen, den ein Systemintegrator bei der Einrichtung einer kleinen Firmenumgebung ebenfalls durchläuft – von der reinen Rollen-Installation bis zu einer abteilungsgetrennten, rechtebasierten Arbeitsumgebung mit zentraler Softwarepflege.
Ein Windows Server 2025 wurde zum Domänencontroller einer neuen Gesamtstruktur aufgebaut, inklusive DNS. Darauf aufbauend wurde eine kleine, aber vollständige Firmenstruktur mit zwei Abteilungen abgebildet: eigene Organisationseinheiten, Sicherheitsgruppen, abteilungsspezifische Gruppenrichtlinien (individuelle Desktophintergründe, automatisches Laufwerksmapping), Freigaben nach dem AGDLP-Prinzip mit granularer NTFS-Rechtetrennung sowie getrennte automatische Windows-Update-Richtlinien für Server und Clients.
- Server: Windows Server 2025, Hostname
DC1,10.42.0.234 - Client: Windows 11 Pro, Hostname
CL01,10.42.0.68 - Domäne:
testdomain.local(NetBIOS:TESTDOMAIN)
Auf dem Server wurden zunächst die Rollen Active Directory-Domänendienste (AD DS) und DNS installiert. Anschließend wurde der Server über den Heraufstufungs-Assistenten zum Domänencontroller einer neuen Gesamtstruktur gemacht.
Ein Domänencontroller muss dabei zwingend sich selbst als primären DNS-Server eintragen (statt Router oder externem DNS) – nur so kann er die für AD notwendigen SRV-Records zuverlässig auflösen. Für Internetzugriff vom Server aus werden stattdessen Forwarder im DNS-Manager konfiguriert, die primäre DNS-Auflösung bleibt intern.
Server-Manager nach Rolleninstallation, DC ist sich selbst als DNS-Server eingetragen (127.0.0.1)
Zu beachten: Der Domänenname sollte beim Heraufstufen bewusst und exakt eingegeben werden (bestenfalls per Copy-Paste statt Tippen) – ein Tippfehler im FQDN lässt sich im Nachhinein nicht einfach in der DNS-Zone korrigieren, da der Name tief in der AD-Struktur (Gesamtstruktur, SYSVOL, Kerberos-Realm) verankert ist. Eine Korrektur bedeutet in der Praxis einen kompletten Neuaufbau.
Damit der Client die Domäne überhaupt finden kann, muss er zwingend den Domänencontroller als DNS-Server eingetragen haben – nicht den Router oder einen externen DNS-Server, da sonst die für den Beitritt nötigen SRV-Records nicht auflösbar sind. Auf CL01 wurde daher eine statische IP-Konfiguration mit DC1 (10.42.0.234) als primärem DNS-Server gesetzt.
Als Funktionstest wurde vom Client aus die Namensauflösung der Domäne verifiziert:
Erst danach erfolgte der eigentliche Domänenbeitritt (Einstellungen → System → Info → Domäne oder Arbeitsgruppe ändern), bestätigt mit den Zugangsdaten eines Domänen-Admin-Kontos, gefolgt von einem Neustart des Clients.
Für die Firma wurde eine Organisationseinheit Firma XY angelegt. Darunter befindet sich jeweils eine OU pro Abteilung (Buchhaltung, Verwaltung), die wiederum in die OUs Benutzer und Gruppen unterteilt ist. Da in diesem Lab nur ein Testcomputer (CL01) verwendet wird, wurde die OU Computer direkt unterhalb der OU Firma XY angelegt und nicht zusätzlich nach Abteilungen unterteilt. Dadurch bleibt die Computerverwaltung unabhängig von der Abteilungsstruktur und kann bei Bedarf später um weitere Computer-OUs ergänzt werden.
Diese Trennung erlaubt es, GPOs und Delegierungen gezielt auf Benutzer-, Gruppen- oder Computerobjekte anzuwenden, ohne dass sich die Objekttypen vermischen.
OU-Struktur mit Abteilungen und Unterteilung nach Benutzern, Gruppen und Computern
Je ein Testbenutzer pro Abteilung wurde angelegt: John (Buchhaltung) und Linus (Verwaltung).
Zu beachten: Der Standard-Container Computers, in dem ein Client nach dem Domänenbeitritt zunächst automatisch landet, erlaubt keine direkte GPO-Verknüpfung – dafür wird zwingend eine echte OU benötigt, in die das Computerobjekt verschoben werden muss.
Pro Abteilung wurde eine globale Sicherheitsgruppe angelegt (GG_Buchhaltung, GG_Verwaltung) und mit dem jeweiligen Benutzer befüllt.
Für jede Abteilung wurde eine eigene GPO erstellt und über die Sicherheitsfilterung gezielt auf die jeweilige Gruppe beschränkt (statt der Standardgruppe „Authentifizierte Benutzer", die alle Domänenkonten einschließen würde).
Zu beachten: Entfernt man „Authentifizierte Benutzer" aus der Filterung, benötigen Computerkonten trotzdem weiterhin das Leserecht auf die GPO (über die Delegierung, z. B. für die Gruppe Domänencomputer), da sie sonst nicht prüfen können, ob die Richtlinie für sie relevant ist. Sicherheitsfilterung steuert nur, wer die GPO anwendet – nicht, wer sie lesen darf.
Um den GPO-Mechanismus unabhängig von einer konkreten Einstellung zu verifizieren, wurde testweise eine simple, eindeutig sichtbare Richtlinie (Task-Manager sperren) konfiguriert und verknüpft:
Zu beachten: Eine GPO, die zwar korrekt verknüpft und gefiltert ist, aber keine tatsächliche Einstellung enthält, wird bei einer RSoP-Prüfung (gpresult) mitunter nicht als „angewendet" gelistet – das liegt nicht an einem Konfigurationsfehler, sondern schlicht daran, dass eine leere GPO nichts zu berichten hat. Ein einfacher, sichtbarer Testfall wie oben schafft hier schnell Klarheit.
Für abteilungsspezifische Hintergründe wurde zunächst eine gemeinsame, nur lesbare Freigabe \\DC1\Bilder eingerichtet (Freigabe: Jeder = Lesen; NTFS: Domänen-Benutzer = Lesen/Ausführen, Administratoren & SYSTEM = Vollzugriff). Anschließend wurde in jeder Abteilungs-GPO die Einstellung „Desktophintergrund" unter Benutzerkonfiguration → Administrative Vorlagen → Desktop → Desktop aktiviert und auf das jeweilige Bild verwiesen.
Zu beachten:
- Der Pfad muss als UNC-Pfad (
\\DC1\Bilder\...) angegeben werden, nicht als lokaler Pfad – sonst funktioniert die Einstellung nur, falls die Datei zufällig auch lokal auf dem Client existiert. - Bei der Anzeigeart empfiehlt sich „Ausfüllen" statt „Dehnen" – Letzteres ignoriert das Seitenverhältnis des Bildes und führt je nach Client-Auflösung zu Verzerrungen.
Ergebnis nach Neuanmeldung, je nach Abteilung:
Für die abteilungsspezifischen Arbeitsdaten wurden zwei Freigaben angelegt (\\DC1\Buchhaltung, \\DC1\Verwaltung), deren Zugriff sauber nach dem AGDLP-Prinzip (Account → Global Group → Domain Local Group → Permission) strukturiert ist: Die bestehenden globalen Gruppen (GG_Buchhaltung, GG_Verwaltung) wurden jeweils Mitglied einer eigenen domänenlokalen Gruppe (DL_Buchhaltung_Aendern, DL_Verwaltung_Aendern), die wiederum die tatsächliche Berechtigung auf der Ressource trägt. Der Vorteil: Wer Zugriff auf eine bestimmte Ressource braucht, wird einfach in die passende DL-Gruppe aufgenommen, unabhängig davon, was die zugrunde liegende globale Gruppe sonst noch an Rechten/Zwecken hat.
Auf Freigabeebene wurde bewusst breit berechtigt (Authentifizierte Benutzer = Ändern) – die eigentliche, feingranulare Steuerung erfolgt ausschließlich über NTFS. Das vermeidet doppelte Pflege an zwei Stellen und folgt damit der in der Praxis üblichen Empfehlung, Freigabeberechtigungen offen und NTFS restriktiv zu halten.
Zu beachten: Beim Zugriff über die Freigabe (\DC1\Verwaltung) gilt immer die restriktivere Kombination aus Freigabe- und NTFS-Berechtigungen – auch für Administratoren. Die Freigabeberechtigung wurde deshalb bewusst auf Authentifizierte Benutzer = Ändern begrenzt und nicht auf Vollzugriff, während auf NTFS-Ebene Administratoren und SYSTEM weiterhin Vollzugriff besitzen. Für administrative Tätigkeiten bleibt der vollständige Zugriff dennoch möglich, wenn direkt lokal auf dem DC über den NTFS-Pfad gearbeitet wird, da Freigabeberechtigungen ausschließlich bei einem Zugriff über SMB ausgewertet werden. Der reguläre Zugriff über die Netzwerkfreigabe bleibt dadurch für den Alltagsbetrieb bewusst eingeschränkt, ohne die administrativen Zugriffsmöglichkeiten auf Dateisystemebene einzuschränken.
Auf NTFS-Ebene wurde die Vererbung vom übergeordneten Ordner entfernt und die Berechtigung explizit neu gesetzt: SYSTEM und Administratoren mit Vollzugriff (damit Windows selbst und die Administration den Ordner immer verwalten können), die jeweilige DL_-Gruppe mit „Ändern".
Zu beachten: Ein neu angelegter Ordner erbt zunächst automatisch die Berechtigungen seines übergeordneten Verzeichnisses. Für eine wirklich abteilungsexklusive Freigabe muss diese Vererbung bewusst entfernt werden – dabei sollte vorher geprüft werden, welche Standardeinträge (insbesondere SYSTEM und Administratoren) danach wieder ergänzt werden müssen, damit Windows selbst und die Administration nicht ausgesperrt werden.
Die Trennung wurde anschließend gegenseitig getestet:
Positivtest – John greift erfolgreich auf die Buchhaltungs-Freigabe zu
Negativtest – John erhält beim Versuch, auf die Verwaltungs-Freigabe zuzugreifen, korrekt eine Zugriffsverweigerung
Damit Mitarbeiter ihre Abteilungsfreigabe nicht manuell per UNC-Pfad öffnen müssen, wurde in den jeweiligen Abteilungs-GPOs zusätzlich eine Laufwerkszuordnung (Group Policy Preferences) eingerichtet – Buchhaltung auf Z:, Verwaltung auf G:, jeweils mit „Verbindung wiederherstellen" für dauerhaftes Neu-Mapping bei jeder Anmeldung.
Nach Neuanmeldung erscheint die Freigabe automatisch als eigenes Laufwerk im Explorer:
Für die Systempflege wurden zwei separate GPOs mit Computerkonfigurations-Einstellungen aufgebaut: eine für den Domänencontroller (verknüpft an die eingebaute OU Domain Controllers), eine für Clients (verknüpft an Firma XY, wo die zugehörige Computer-OU liegt). Beide konfigurieren automatisches Herunterladen und Installieren nach Zeitplan, zusätzlich wurde die Feature-Update-Übernahme über „Windows Update for Business" zurückgehalten – so laufen Sicherheits- und Qualitätsupdates automatisch durch, während große Versionssprünge kontrolliert bleiben.
Zu beachten: Computer- und Benutzerkonfiguration einer GPO werden komplett getrennt verarbeitet – eine Computer-Richtlinie gilt für den Rechner selbst, unabhängig davon, welcher Benutzer gerade angemeldet ist. Bei der Diagnose per gpresult lohnt sich deshalb ein gezielter Blick auf den Computer-Anteil.
Dieses Lab wurde primär zum Erlernen der grundlegenden AD-Mechaniken (OUs, GPOs, Freigaben, AGDLP) aufgebaut. Als reine Testumgebung wurde bewusst auf produktionsreifes Hardening verzichtet, um sich zunächst auf die Kernfunktionalität konzentrieren zu können. Für einen produktiven Einsatz wären insbesondere folgende Punkte relevant:
Konten & Passwörter
- Verschärfte Passwortrichtlinie statt der AD-Standardwerte (Mindestlänge, Komplexität, Ablaufzeit)
- Kontosperrrichtlinie gegen Online-Brute-Force und Password-Spraying
- Dediziertes, benanntes Admin-Konto statt des eingebauten
Administrator-Kontos, das ein bekanntes Standardziel für Angriffe ist - LAPS (Local Administrator Password Solution) für automatisch rotierende, pro Computer eindeutige lokale Admin-Passwörter – verhindert laterale Bewegung über ein einheitliches lokales Passwort
Kerberos & Dienstkonten
- Absicherung gegen Kerberoasting: starke, regelmäßig rotierte Passwörter für Dienstkonten mit SPN, idealerweise Group Managed Service Accounts (gMSA) statt klassischer Dienstkonten
Administrative Trennung
- Tiering-Modell (Tier 0/1/2) zur Trennung von Domänen-Admin-Rechten von alltäglicher Client-Administration
- Verzicht auf die Anmeldung mit Domänen-Admin-Konten an normalen Arbeitsplatzrechnern
Infrastruktur
- Zweiter Domänencontroller für Redundanz (aktuell Single Point of Failure)
- Regelmäßige System-State-Backups des DC
- Monitoring/Logging sicherheitsrelevanter Ereignisse (z. B. fehlgeschlagene Anmeldungen, Änderungen an privilegierten Gruppen)
- Zweiter Domänencontroller für Redundanz und Replikation
- Ordnerumleitung (Desktop/Dokumente) für abteilungsübergreifend konsistente Benutzerprofile
- Zertifikatsdienste (AD CS) – eigene interne Zertifizierungsstelle, z. B. für internes HTTPS oder 802.1X
- Softwareverteilung per GPO (.msi-Pakete automatisch installieren)
- Azure AD Connect / Hybrid-Szenario – lokale Domäne mit Entra ID synchronisieren (zeigt Cloud-Anbindung)