Domain Controller LDAPS schwaches TLS, Print Spooler, Zeitsynchronisation Audit: Eine Checkliste für die Netzwerkhygiene

Dies ist ein Domain Controller LDAPS Weak TLS Print Spooler Time Sync Audit: eine praktische Checkliste für drei netzwerkseitige Einstellungen, die Active-Directory-Reviews rund um ACLs und Gruppenverschachtelung routinemäßig übersehen. Jede davon ist schnell zu prüfen, und jede unterläuft still eine andere Sicherheitsgarantie, sobald ein Domain Controller von seiner Baseline abweicht.

Domain Controller LDAPS mit schwachem TLS, Print Spooler, Zeitsynchronisation im Audit

Die meisten Active-Directory-Härtungsreviews jagen ACLs, Gruppenverschachtelung und Delegationspfade nach — und überspringen die eigene Netzwerkoberfläche des Domain Controllers. Wenn Sie von einer breiteren Prioritätenliste aus arbeiten, deckt Active Directory härten: Was Sie zuerst absichern und wie Sie es validieren ab, wo Protokollhärtung wie diese im Verhältnis zu privilegiertem Zugriff und wiederverwendbaren Geheimnissen einzuordnen ist. Die drei folgenden Befunde tauchen selten in einem Berechtigungsbericht auf, aber jeder einzelne ist günstig zu prüfen und günstig zu beheben, sobald man weiß, wo man hinsehen muss:

Keiner dieser drei Punkte ist neu. Was es lohnt, sie zu einem gemeinsamen Review-Durchgang zu bündeln, ist, dass sie still versagen — ein DC mit einem heruntergestuften LDAPS-Listener, einem laufenden Spooler oder ein paar Minuten Uhrzeitabweichung sieht in einem Standard-Health-Check vollkommen gesund aus, bis etwas das Problem erzwingt.

Schwaches TLS auf LDAPS

Die Installation eines gültigen Zertifikats im Zertifikatspeicher „Lokaler Computer\Eigene Zertifikate" des DC aktiviert LDAPS auf Port 636 (und 3269 für den Global Catalog) automatisch — Microsofts eigene Anleitung zum Konfigurieren von Zertifikaten für LDAP über SSL bestätigt, dass keine zusätzliche Dienstkonfiguration nötig ist, sobald das Zertifikat sowohl vom DC als auch von seinen Clients vertraut wird. Das Problem ist, dass „LDAPS ist an" nichts darüber aussagt, welche TLS-Versionen und Cipher Suites weiterhin akzeptiert werden. Ein DC, dessen Schannel nie gehärtet wurde, handelt mit jedem Client, der sie anbietet, auf TLS 1.0 oder 1.1 sowie schwache CBC-/SHA1-Cipher-Suites herunter — wie in DSInternals' Anleitung zum Erzwingen von TLS 1.2+ für LDAPS auf Domain Controllern im Detail beschrieben. Das ist relevant, weil einfache LDAP-Bindungen Zugangsdatenmaterial auf der Leitung übertragen; eine heruntergestufte Chiffre auf dem verschlüsselten Kanal, der genau das schützen soll, unterläuft den ganzen Sinn, LDAPS überhaupt zu betreiben.

Erkennung

Aktivieren Sie das Schannel-Diagnoseprotokoll, bevor Sie irgendetwas anfassen — Sie wollen Belege dafür, was tatsächlich verbindet, bevor Sie eine Protokollversion deaktivieren:

# Ausführliches Schannel-Event-Logging (Protokoll-/Cipher-Detail pro Verbindung über Event-ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Die auf diesem DC aktuell für TLS aktivierten Cipher Suites auflisten
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite liefert die geordnete Cipher-Suite-Liste, die Windows aushandeln wird — Microsoft dokumentiert die vollständige Cmdlet-Referenz unter Get-TlsCipherSuite (TLS). Mit gesetztem EventLogging landet jeder Schannel-Handshake von und zum DC im System-Log unter Event-ID 36880 mit ausbuchstabierter ausgehandelter Protokollversion und Cipher Suite — das ist Ihr Beleg dafür, welche Clients oder Tools noch ein Downgrade erzwingen, bevor Sie irgendetwas deaktivieren.

Behebung

1. Bestätigen Sie anhand der oben genannten Event-ID-36880-Belege, dass kein legitimer Client noch TLS 1.0/1.1 benötigt.
2. Deaktivieren Sie TLS 1.0 und TLS 1.1 serverseitig über die Schannel-Protocols-Registry-Schlüssel, oder nutzen Sie Disable-TlsCipherSuite, um schwache CBC-/SHA1-Suites zu entfernen und dabei Suites der Klasse TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 aktiviert zu lassen.
3. Starten Sie den DC neu — Schannel-Protokolländerungen greifen erst nach einem Neustart.
4. Führen Sie Get-TlsCipherSuite erneut aus und prüfen Sie Event-ID 36880 erneut, um zu bestätigen, dass nur noch starke Suites ausgehandelt werden.

Print Spooler läuft auf einem Domain Controller

Domain Controller drucken selbst nichts, daher hat der Print-Spooler-Dienst keinen betrieblichen Grund, auf einem DC zu laufen — trotzdem wird er standardmäßig aktiviert ausgeliefert. CISAs PrintNightmare-Advisory (CVE-2021-34527, CVSS 8.8) machte aus diesem Standard einen niedrigprivilegierten, authentifizierten Remote-Code-Execution-Pfad — die NVD-Bewertung (PR:L) bestätigt, dass dafür nichts weiter als ein Standard-Domänenkonto nötig ist, keine Admin-Rechte — und CISAs Emergency Directive 21-04 forderte Bundesbehörden auf, den Spooler auf jedem DC zu deaktivieren — nicht nur zu patchen.

Patchen löst das zugrunde liegende Designproblem ebenfalls nicht auf. Seit 2018 erlaubt der „Printer Bug" (ein Missbrauch des RpcRemoteFindFirstPrinterChangeNotification-Aufrufs in MS-RPRN) jedem authentifizierten Benutzer, einen DC mit laufendem Spooler zur Authentifizierung gegenüber einem angreiferkontrollierten Host zu zwingen — dokumentiert in Sean Metcalfs Domain Controller Print Server + Unconstrained Kerberos Delegation-Beitrag. Verkettet mit einem Konto, das über uneingeschränkte Delegation verfügt, liefert diese Coercion das eigene Zugangsdatenmaterial des DC aus; verkettet mit einem Relay speist sie direkt in einen NTLM-Relay-Angriff — dieselbe Familie von Exposure, die in SMB-Signierung deaktiviert: Warum das weiter NTLM-Relay ermöglicht behandelt wird. Microsoft Defender for Identity liefert dies inzwischen als feste Sicherheitsbewertung, die empfiehlt, den Print Spooler auf DCs zu deaktivieren.

Erkennung

Prüfen Sie jeden DC in der Domäne in einem Durchgang — verlassen Sie sich nicht darauf, nur den einen DC zu prüfen, an den Sie sich erinnern:

$dcs = Get-ADDomainController -Filter * | Sort-Object HostName
foreach ($dc in $dcs) {
    Get-Service -Name Spooler -ComputerName $dc.HostName |
        Select-Object @{N='DC';E={$dc.HostName}}, Status, StartType
}

Bestätigen Sie außerdem, dass keine veröffentlichten Druckerwarteschlangen von einem DC abhängen, bevor Sie ihn anfassen:

Get-ADObject -Filter "ObjectCategory -eq 'printQueue'"

Behebung

1. Stoppen und deaktivieren Sie für jeden DC, bei dem Status gleich Running ist oder StartType ungleich Disabled ist, den Dienst:

Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName

2. Erzwingen Sie das domänenweit über eine GPO, die auf die Domain-Controllers-OU angewendet wird (Computer Configuration > Preferences > Control Panel Settings > Services, Spooler auf Stopped/Disabled gesetzt), damit ein Neustart oder manueller Restart den Dienst nicht still wieder aktiviert.
3. Führen Sie die Erkennungsschleife nach dem nächsten GPO-Refresh-Zyklus erneut aus, um zu bestätigen, dass die Einstellung auf allen DCs hält, einschließlich neu heraufgestufter DCs — ein frisch heraufgestufter DC startet mit dem Spooler-Dienst wieder im Standardzustand (laufend).

Uhrzeitabweichung, die niemand überwacht

Kerberos versieht seine Tickets mit Zeitstempeln, um Replay-Angriffe zu verhindern, das heißt, Authentifizierung hängt davon ab, dass die Uhr jedes DC nahe an der Zeitquelle der Domäne bleibt. Die Toleranz wird durch die Kerberos-Richtlinie Maximale Toleranz für die Synchronisation der Computeruhr bestimmt — standardmäßig 5 Minuten, festgelegt unter Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, gemäß Microsofts Referenz zu Sicherheitsrichtlinien. Wird diese Toleranz überschritten, schlägt die Kerberos-Authentifizierung mit einer KRB_AP_ERR_SKEW-Antwort vollständig fehl — was weitaus häufiger als Anwendungs- oder Netzwerkproblem fehlinterpretiert wird, als es korrekt als Uhrzeitabweichung diagnostiziert wird.

Die Zeithierarchie der Domäne hat nur eine autoritative Wurzel: den PDC-Emulator. Jeder andere DC synchronisiert sich mit einem Peer in der Domänenhierarchie, und Workstations synchronisieren sich mit ihrem authentifizierenden DC. Wenn der PDC-Emulator selbst nicht auf eine zuverlässige externe Quelle zeigt, kann die gesamte Domäne gemeinsam driften, ohne dass etwas dagegen widerspricht — genau das Fehlerbild, das Microsofts Anleitung zum Konfigurieren des Root-PDC mit einer autoritativen Zeitquelle verhindern soll. Ein DC, der still auf eine eigene unabhängige NTP-Quelle statt auf die Domänenhierarchie gestellt wurde, ist ebenso problematisch: Er wird zu einer zweiten, konkurrierenden Zeitautorität, der andere DCs keinen Grund haben, mehr zu vertrauen als dem PDC-Emulator, und die resultierenden intermittierenden Kerberos-Fehler ohne diesen Kontext zu troubleshooten, kann Stunden kosten, bevor überhaupt jemand daran denkt, w32tm zu prüfen.

Erkennung

# Aktueller Synchronisationsstatus und Quelle auf diesem DC
w32tm /query /status

# Offsets über alle DCs der Domäne in einem Durchgang vergleichen
w32tm /monitor

Beobachten Sie das System-Log auf Event-ID 4713 (Kerberos-Richtlinie geändert — nur DC, eine Alarmierung wert, wenn unerwartet) zusammen mit Authentifizierungsfehlern, die auf KRB_AP_ERR_SKEW verweisen; korreliert weisen sie direkt auf Zeitsynchronisation statt auf ein defektes Trust oder abgelaufene Zugangsdaten hin.

Behebung

1. Identifizieren Sie, welcher DC die PDC-Emulator-Rolle innehat, und bestätigen Sie, dass er — nicht ein Peer-DC — gegen eine externe, zuverlässige NTP-Quelle statt gegen die interne Hardware-Uhr konfiguriert ist.
2. Wenn der PDC-Emulator driftet oder falsch konfiguriert ist, deckt Microsofts Leitfaden zur Behebung großer Zeitabweichungen ab, wie sich große Offsets sicher korrigieren lassen — ein naiver Zeitsprung auf einem DC kann selbst laufende Kerberos-Tickets brechen.
3. Bestätigen Sie, dass jeder andere DC seine Zeit aus der Domänenhierarchie (NT5DS) bezieht statt aus einer eigenen unabhängigen Quelle.
4. Führen Sie w32tm /monitor nach der Konvergenz erneut aus und bestätigen Sie, dass alle Offsets komfortabel unter der 5-Minuten-Kerberos-Toleranz liegen, nicht nur knapp darunter.

Diese Prüfung wiederholbar machen, nicht nur einmalig beheben

Alle drei oben genannten Befunde neigen dazu, still zu regressieren: Ein frisch heraufgestufter DC setzt den Spooler-Dienst auf seinen Standardzustand (laufend) zurück, ein ersetztes Zertifikat kann still einen Fallback auf eine schwache Chiffre wieder einführen, und eine stillgelegte NTP-Appliance kann den PDC-Emulator ohne Warnung zurücklassen. Nichts davon wird erkannt, wenn die Audit-Kategorien, die es protokollieren würden, nicht tatsächlich aktiviert sind — siehe Active Directory Auditrichtlinien: Konfigurationslücken, falls Schannel- oder Kerberos-Richtlinienereignisse nicht dort auftauchen, wo Sie sie erwarten.

Behandeln Sie diese Checkliste genauso wie jede andere driftanfällige Kontrolle: Führen Sie sie nach einem Zeitplan erneut aus, nicht nur nach der ersten Behebung. Ein vierteljährlicher Durchgang über alle drei Prüfungen — Cipher Suites, Spooler-Status und Zeitoffsets — fängt die Regression ab, bevor sie zum Incident wird, und das mit einem Bruchteil des Aufwands der ursprünglichen Behebung. Die drei PowerShell-Snippets oben sind kurz genug, um sie in einen Scheduled Task oder CI-Job zu verpacken, statt sie jedes Mal von Hand auszuführen.

Wie EtcSec das erkennt

EtcSecs Netzwerk-Kategorie prüft alle drei dieser Befunde bei jedem AD-Audit: DC_LDAPS_WEAK_TLS markiert Domain Controller, deren LDAPS-Listener noch eine schwache TLS-Version aushandelt, DC_SPOOLER_ACCESSIBLE markiert jeden Domain Controller mit erreichbarem Print-Spooler-Dienst, und DC_TIME_SYNC_ISSUE (gepaart mit NTP_NOT_CONFIGURED) markiert DCs, die von der autoritativen Zeitquelle der Domäne abweichen oder denen ein konfigurierter NTP-Peer ganz fehlt.