Ausgangslage: Warum DCs kein Druckziel sein sollten

In vielen Umgebungen läuft der Print Spooler auch auf Domain Controllern, schlicht weil er „halt da ist“. Operativ wird auf DCs fast nie gedruckt – sicherheitstechnisch ist das trotzdem relevant: Der Spooler ist ein zusätzlicher Dienst mit eigener Angriffs- und Fehlerfläche, der auf Tier-0-Systemen schlicht nichts zu suchen hat.

Wenn du AD-Hardening als Projekt betreibst (statt als Schalter-Sammlung), ist das ein typischer „Low-Hanging Fruit“-Punkt: klarer Nutzen, überschaubare Komplexität – wenn du Ausnahmen sauber behandelst.

Zielbild: Tier 0 bleibt „lean“

Pragmatisches Zielbild:

  • Auf allen Domain Controllern ist der Dienst Spooler gestoppt und deaktiviert.
  • DCs haben keine Print-Server-Rolle, keine Druckwarteschlangen, keine „mal schnell“-Druckerinstallationen.
  • Falls es echte Ausnahmen gibt: dokumentiert, zeitlich befristet, technisch erzwungen (nicht „still toleriert“).
  • Betrieblich: ein Check (Monitoring/Audit), der den Zustand regelmäßig verifiziert.

Umsetzung: sauber deaktivieren statt „per Hand stoppen“

1) Erst prüfen, ob es überhaupt Abhängigkeiten gibt

Bevor du per GPO in die Fläche gehst:

  • Gibt es überhaupt DCs, die als Print Server missbraucht werden?
  • Gibt es Admins/Jump-Hosts, die auf DCs „lokal“ Drucker verwalten?
  • Gibt es Third-Party-Agenten, die aus irgendeinem Grund den Spooler voraussetzen (selten, aber möglich)?

Ein schneller, ungefährlicher Check in PowerShell (auf DCs bzw. via Remoting):

Get-Service -Name Spooler | Select-Object Status, StartType, Name, DisplayName

2) GPO: Dienst auf DCs deaktivieren

Der robuste Weg ist eine GPO, die auf die Domain Controllers-OU (oder eine dedizierte DC-OU-Struktur) verlinkt ist.

Option A (klassisch): System Services in der GPO

  • Computer Configuration → Policies → Windows Settings → Security Settings → System Services → Print Spooler
  • Startup Mode: Disabled
  • Service Permissions: nicht „öffnen“, wenn du das nicht bewusst brauchst

Option B (praktisch, wenn du schon GPP nutzt): Service per Group Policy Preferences

  • Computer Configuration → Preferences → Control Panel Settings → Services
  • Service name: Spooler
  • Action: Update
  • Startup: Disabled
  • Service action: Stop service

Wichtig: Für Tier 0 ist „per Hand“ keine Lösung. Du willst erzwungenen Zustand, den du jederzeit reproduzierbar nachweisen kannst.

3) Ausnahmen sind ein eigenes Artefakt

Wenn es tatsächlich einen Sonderfall gibt (z.B. temporäre Migrationsphase):

  • Stelle Ausnahmen OU-basiert dar (z.B. OU=DC-Exceptions), nicht über „Security Filtering wild zusammengeklickt“.
  • Definiere eine Ablauffrist und einen Owner.
  • Baue eine Kontrolle, die Ausnahmen sichtbar macht (Dashboard, regelmäßiger Review, Change-Record).

Betrieb: Wie du es prüfbar machst

Minimaler Betriebsstandard:

  • Ein regelmäßiger Compliance-Check (z.B. Skript/Job), der auf allen DCs prüft:
  • Spooler ist Stopped
  • StartType ist Disabled
  • Alarm, wenn ein DC davon abweicht (drift).

Wenn du ohnehin AD-Hardening-Policies iterativ ausrollst: nimm den Check in deinen „Tier-0-Baseline“-Report auf.

Vorteile (explizit)

  • Weniger laufende Dienste auf Tier 0, damit weniger Angriffsfläche und weniger „unerwartete“ Abhängigkeiten.
  • Drift wird sichtbar: Wenn jemand den Dienst wieder aktiviert, ist das ein messbarer Policy-Bruch.
  • DCs bleiben klar getrennt von Workload-Rollen (Print, File, App), was spätere Härtung deutlich einfacher macht.

Nachteile und Grenzen (explizit)

  • Wenn ein DC faktisch als Print Server genutzt wurde (sollte er nicht), gibt es operativen Impact – das ist dann aber ein Architekturproblem, das ohnehin gelöst werden muss.
  • Einige Diagnose-/Admin-Workflows, die „aus Gewohnheit“ auf DCs stattfinden, müssen umgestellt werden (z.B. Druckerverwaltung).
  • Der Schritt ersetzt keine weiteren Kontrollen: Druck-/Point-and-Print-Härtung, Treiberkontrollen, Admin-Workflows und Segmentierung bleiben eigene Themen.

Typische Stolperfallen

  • GPO-Scope: Policy landet nicht wirklich auf allen DCs (OU-Struktur inkonsistent, Verlinkung falsch, Block Inheritance, WMI-Filter).
  • „Nur gestoppt“ statt deaktiviert: Nach Reboot ist der Dienst wieder da.
  • Ausnahmen ohne Governance: Ein „temporäres“ Exception-DC bleibt dauerhaft ausgenommen.
  • Rollenmischung: Ein DC hostet nebenbei noch andere Rollen – dann ist die Spooler-Deaktivierung oft nur der erste Hinweis, dass das Zielbild insgesamt fehlt.

Projekt-Checkliste (für die Umsetzung im Hardening-Projekt)

  1. DC-Inventar: Liste aller DCs, Sites, Rollen, OU-Zuordnung.
  2. Status-Check: Spooler-Status/StartType pro DC erfassen (Ist-Zustand).
  3. Zielbild schriftlich fixieren: „Kein Print Spooler auf Tier 0“ inkl. Exception-Regel.
  4. Pilot: 1–2 DCs pro Site (falls vorhanden), Wartungsfenster einplanen.
  5. Rollout: GPO auf alle DCs, Reboot-/Wartungsplanung abstimmen.
  6. Betriebscheck: Compliance-Query/Script + Alarmierung auf Drift.
  7. Exceptions: dokumentiert, befristet, mit Owner, regelmäßiger Review.