Ausgangslage: Gruppenrichtlinien hängen an unscheinbaren Freigaben

In Active Directory wirken SYSVOL und NETLOGON oft wie technische Nebengeräusche. Jeder kennt die Pfade, kaum jemand betrachtet sie als eigenen Schutzbereich. Genau dort liegen aber Gruppenrichtlinien, Logon-Skripte und weitere Dateien, die Clients beim Start, bei der Anmeldung oder beim Policy Refresh lesen.

Der kritische Punkt ist nicht die Freigabe allein. Kritisch ist der Pfad vom Client zum Domain Controller: Namensauflösung, Kerberos, SMB, DFS-Referral, Standortwahl und die Frage, ob der Client wirklich mit dem erwarteten Server spricht. Wenn dieser Pfad schwach ist, können Richtlinien und Skripte über einen unsauberen Transport geladen werden. Das ist kein sauberer Betriebszustand für eine Domäne.

Hardened UNC Paths adressieren genau diesen Bereich. Der Client bekommt für bestimmte UNC-Pfade Mindestanforderungen vorgegeben. Wenn der Server diese Anforderungen nicht erfüllt, soll der Zugriff fehlschlagen statt still unsicher weiterzulaufen.

Für AD-Hardening sind zuerst diese Pfade relevant:

  • \\*\SYSVOL
  • \\*\NETLOGON

Diese Wildcards sind bewusst gewählt. Clients greifen häufig über den Domänennamen, einen konkreten Domain Controller oder DFS-Referral auf diese Shares zu. Die Regel soll deshalb nicht nur einen einzelnen Hostnamen schützen.

Zielbild: Policy-Dateien werden nur über geprüfte SMB-Sessions gelesen

Ein belastbarer Zielzustand ist konkret:

  1. SYSVOL und NETLOGON verlangen gegenseitige Authentifizierung. Der Client akzeptiert nicht irgendeinen SMB-Server, sondern erwartet Kerberos-basierte Serveridentität.
  2. SMB-Integrität ist Pflicht. Manipulationen am Transport sollen nicht still akzeptiert werden.
  3. SMB-Verschlüsselung wird bewusst bewertet. RequirePrivacy=1 ist sinnvoll, wenn Clients und Domain Controller das sauber unterstützen; in gemischten Umgebungen braucht es Tests.
  4. Die GPO gilt für Clients und Server, nicht nur für Domain Controller. Der Schutz sitzt auf der zugreifenden Maschine.
  5. Fehler sind sichtbar. GroupPolicy- und NetworkProvider-Logs werden ausgewertet, damit harte Pfade nicht nur "gesetzt", sondern auch wirksam sind.
  6. Ausnahmen sind dokumentiert. Alte Clients, Drittanbieter-SMB-Systeme oder Sonderpfade bekommen Owner, Risikoannahme und Ablaufdatum.

Das Ziel ist nicht, alle UNC-Pfade blind zu verschlüsseln. Das Ziel ist, die kritischen AD-Pfade so zu behandeln, wie sie sind: Transportwege für vertrauenswürdige Konfiguration.

Umsetzung: erst SYSVOL und NETLOGON, dann weitere Freigaben

1) Wirksame Richtlinie auf Clients prüfen

Starte mit einem repräsentativen Client, nicht mit dem Domain Controller. Hardened UNC Paths werden beim Zugriff durch den Client bewertet.

$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths'

if (Test-Path -LiteralPath $path) {
  Get-ItemProperty -LiteralPath $path |
    Select-Object -Property '\\*\SYSVOL','\\*\NETLOGON'
}

Wenn hier nichts steht, heißt das nicht automatisch, dass der Client gar keinen Schutz hat. Moderne Windows-Versionen bringen für SYSVOL und NETLOGON bereits Schutzlogik mit. Für ein AD-Hardening-Projekt ist eine explizite, prüfbare GPO trotzdem besser: Sie macht Zielzustand, Drift und Ausnahmen sichtbar.

Ergänzend prüfen:

gpresult /h "$env:TEMP\gpresult.html"

Get-WinEvent -LogName 'Microsoft-Windows-NetworkProvider/Operational' -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Die Eventauswertung ist wichtig, weil falsche Pfade, Kerberos-Probleme oder nicht erfüllte SMB-Anforderungen sonst nur als "Group Policy failed" im Betrieb auftauchen.

2) GPO sauber setzen

Die Einstellung liegt hier:

Computer Configuration
  Administrative Templates
    Network
      Network Provider
        Hardened UNC Paths

Für eine robuste AD-Basis:

Value name: \\*\NETLOGON
Value:      RequireMutualAuthentication=1, RequireIntegrity=1

Value name: \\*\SYSVOL
Value:      RequireMutualAuthentication=1, RequireIntegrity=1

Diese Einstellung verlangt Kerberos-basierte gegenseitige Authentifizierung und SMB-Integrität. Praktisch bedeutet das: Wenn der Client die Serveridentität nicht sauber prüfen kann oder SMB Signing nicht erfüllt wird, soll der Zugriff nicht einfach unsicher weitergehen.

Für moderne, vollständig unterstützte Umgebungen kann zusätzlich geprüft werden:

RequirePrivacy=1

Das erzwingt SMB Encryption für den betroffenen Pfad. Das ist ein stärkerer Schutz, aber auch der Teil mit dem größten Kompatibilitäts- und Performance-Risiko. Deshalb nicht blind per Copy-and-paste in jede Domäne rollen.

3) Kerberos-Pfade reparieren, nicht durch Ausnahmen verstecken

RequireMutualAuthentication=1 ist nur dann stabil, wenn Kerberos funktioniert. Typische Ursachen für Fehler:

  • Zugriff per IP-Adresse statt Name,
  • CNAMEs oder Aliase, die nicht sauber als Computername/SPN abgebildet sind,
  • DNS-Drift zwischen Standorten,
  • alte Clients oder Appliances,
  • manuelle Mapping-Skripte mit falschen UNC-Namen,
  • Zeitabweichung oder kaputte Domänenvertrauensstellung.

Der richtige Umgang ist selten "UNC Hardening wieder abschalten". Meist muss der Namens- und Kerberos-Pfad repariert werden: FQDNs verwenden, SPNs prüfen, DNS bereinigen, alte Alias-Konstrukte ersetzen und DFS-Namespaces testen.

4) RequirePrivacy getrennt pilotieren

RequireIntegrity=1 erzwingt SMB Signing. RequirePrivacy=1 erzwingt SMB Encryption. Verschlüsselung enthält Integrität praktisch mit, ist aber nicht automatisch in jeder Umgebung der richtige Sofortschritt.

Prüfe vor RequirePrivacy=1:

  • Unterstützen alle relevanten Clients SMB 3.x?
  • Unterstützen alle Domain Controller und betroffenen Fileserver SMB Encryption?
  • Gibt es alte Betriebssysteme, Boot-/Deployment-Prozesse oder Recovery-Szenarien?
  • Wie verhalten sich WAN-Standorte, VPN-Clients und langsame Links?
  • Gibt es Monitoring für GroupPolicy-Fehler nach dem Rollout?

Ein sinnvoller Ablauf ist: erst RequireMutualAuthentication=1, RequireIntegrity=1 breit ausrollen, dann RequirePrivacy=1 in einer Pilot-OU mit modernen Clients und aktuellen Domain Controllern testen. Wenn die Umgebung sauber ist, kann Verschlüsselung für SYSVOL und NETLOGON Teil der Zielbaseline werden.

5) Nicht nur Domain Controller in den Scope nehmen

Ein häufiger Denkfehler: "SYSVOL liegt auf DCs, also konfigurieren wir DCs." Der Client erzwingt die UNC-Anforderung beim Zugriff. Deshalb gehört die GPO auf Domänen-Clients und Member Server, die Gruppenrichtlinien und Logon-Skripte laden.

Für Domain Controller selbst ist die Einstellung ebenfalls sinnvoll, aber sie löst nicht den Hauptfall. Entscheidend ist, dass Workstations, Terminalserver, Applikationsserver, Admin-Workstations und Management-Systeme die geschützten Pfade nur noch mit den geforderten Eigenschaften akzeptieren.

6) Weitere kritische UNC-Pfade nachziehen

Nach SYSVOL und NETLOGON lohnt sich eine zweite Welle für Freigaben, aus denen Code, Konfiguration oder administrative Inhalte geladen werden:

  • Softwareverteilung,
  • zentrale Skript- und Toolshares,
  • Admin-Tooling,
  • Deployment-Freigaben,
  • Profil- oder Konfigurationsshares mit hohem Einfluss,
  • DFS-Namespaces mit sicherheitsrelevanten Inhalten.

Hier sollte nicht pauschal \\*\* gebaut werden. All-wildcard ist nicht der richtige Steuerungsmechanismus und wird für Hardened UNC Paths nicht als sinnvoller Zielpfad behandelt. Besser sind konkrete Server-/Share-Muster mit Owner, Testfall und Rollback.

Vorteile

  • Schützt kritische AD-Transportpfade: Gruppenrichtlinien und Logon-Skripte werden nicht blind über schwache SMB-Sessions geladen.
  • Reduziert Spoofing- und Tampering-Risiken: Kerberos-basierte Serveridentität und SMB-Integrität werden zur Pflicht.
  • Passt gut zu SMB-Signing- und Kerberos-Hardening: Die Maßnahme ergänzt bestehende Baselines statt ein neues Sondermodell zu bauen.
  • Gut messbar: Registry/GPO, gpresult, SMB-Verbindungen und Eventlogs liefern prüfbare Evidenz.
  • Geringe Änderung am Betriebsmodell: Für moderne Domänen ist die Basisvariante meist weniger invasiv als viele andere AD-Härtungen.
  • Ausbaufähig: Nach SYSVOL/NETLOGON können weitere Code- und Admin-Freigaben gezielt folgen.

Nachteile und Grenzen

  • Fehler wirken schnell wie GPO-Probleme: Wenn Kerberos, DNS oder SMB nicht sauber sind, sieht der Betrieb zuerst fehlgeschlagene Richtlinien.
  • RequirePrivacy kann brechen: SMB Encryption ist nicht für alle Altclients, Drittanbieter-Server oder Sonderprozesse garantiert.
  • Performance muss bewertet werden: Signing und besonders Encryption haben Kosten, vor allem auf alten Systemen oder langsamen Links.
  • Es ersetzt keine Rechtehygiene: Falsche ACLs auf SYSVOL, schwache GPO-Delegation oder unsichere Skripte bleiben eigene Risiken.
  • Es schützt keine Nicht-SMB-Pfade: HTTP-basierte Softwareverteilung, Cloud-Shares oder lokale Cache-Probleme müssen separat betrachtet werden.
  • Namenskonventionen werden wichtig: IP-Zugriffe, unsaubere Aliase und CNAME-Gewohnheiten fallen stärker auf.

Typische Stolperfallen

  • Nur auf Domain Controller verlinken: Der Schutz muss auf den zugreifenden Systemen ankommen.
  • RequirePrivacy=1 ohne Pilot setzen: Eine einzelne Legacy-Abhängigkeit kann dann Gruppenrichtlinien oder Logon-Skripte stören.
  • CNAMEs und IP-Zugriffe ignorieren: Kerberos-basierte gegenseitige Authentifizierung braucht saubere Namen.
  • DFS nicht testen: SYSVOL nutzt DFS-Logik; Standort, Referral und DC-Auswahl gehören in den Test.
  • Nur erfolgreichen Zugriff prüfen: Ein erfolgreicher dir \\domain\SYSVOL zeigt nicht, ob Signing, Kerberos und Hardening tatsächlich greifen.
  • NetworkProvider-Logs nicht auswerten: Konfigurationsfehler stehen oft dort, bevor sie als breite Betriebsmeldung sichtbar werden.
  • Weitere Code-Freigaben vergessen: Wenn Softwareverteilung und Admin-Skripte unsicher bleiben, ist nur ein Teil des Problems gelöst.
  • Ausnahmen ohne Ablaufdatum dokumentieren: Dann wird aus einer Kompatibilitätsbremse wieder Dauerzustand.

Projekt-Checkliste

  • [ ] Bestehende GPOs und Registry-Werte für Hardened UNC Paths auf repräsentativen Clients prüfen.
  • [ ] \\*\SYSVOL und \\*\NETLOGON mit RequireMutualAuthentication=1, RequireIntegrity=1 als Basis konfigurieren.
  • [ ] GPO auf Workstations, Member Server, Admin-Systeme und Domain Controller passend verlinken.
  • [ ] gpresult, GroupPolicy-Logs und Microsoft-Windows-NetworkProvider/Operational auswerten.
  • [ ] Zugriff auf \\domain\SYSVOL, \\domain\NETLOGON, konkrete DC-Pfade und Standortwechsel testen.
  • [ ] Kerberos-Probleme durch DNS/SPN/Namenskorrektur beheben, nicht durch pauschale Hardening-Ausnahmen.
  • [ ] RequirePrivacy=1 separat in moderner Pilot-OU testen und Performance bewerten.
  • [ ] Legacy-Clients, Deployment-Prozesse, Recovery-Abläufe und Drittanbieter-SMB-Systeme explizit prüfen.
  • [ ] Weitere kritische Code-, Admin- und Softwareverteilungsfreigaben inventarisieren.
  • [ ] Ausnahmen mit Owner, Begründung, Ablaufdatum und Review-Termin dokumentieren.
  • [ ] Monitoring auf neue GroupPolicy- und NetworkProvider-Fehler nach dem Rollout einrichten.