🏢Active DirectoryNetworkMonitoring

Domain Controller LDAPS Weak TLS, Print Spooler, Time Sync Audit: A Network Hygiene Checklist

Weak TLS on LDAPS, a Print Spooler nobody disabled, and clock drift past the Kerberos tolerance: three DC network settings that skip most AD reviews. Here's how to audit and fix all three.

Younes AZABARBy Younes AZABAR9 min read
Domain Controller LDAPS Weak TLS, Print Spooler, Time Sync Audit: A Network Hygiene Checklist

This is a domain controller ldaps weak tls print spooler time sync audit: a practical checklist for three network-facing settings that Active Directory reviews built around ACLs and group nesting routinely miss. Each one is quick to check, and each one quietly breaks a different security guarantee once a domain controller drifts from its baseline.

Domain Controller LDAPS Weak TLS, Print Spooler, Time Sync Audit

Most Active Directory hardening reviews chase ACLs, group nesting, and delegation paths — and skip the domain controller's own network surface. If you're working from a broader priorities list, Hardening Active Directory: What to Lock Down First covers where protocol hardening like this fits relative to privileged access and reusable secrets. The three findings below rarely show up in a permissions report, but every one of them is cheap to check and cheap to fix once you know where to look:

IssueWhere it livesWhat breaksDefault state
Weak TLS on LDAPSSchannel, port 636/3269Encrypted-bind guaranteeNegotiates down to TLS 1.0/1.1 unless hardened
Print Spooler reachableSpooler service on the DCCoercion / RCE surfaceEnabled and running out of the box
Clock driftW32Time, PDC Emulator hierarchyKerberos authenticationNo alerting once drift exceeds the 5-minute tolerance

None of these three is new. What makes them worth grouping into one review pass is that they fail silently — a DC with a downgraded LDAPS listener, a live spooler, or a few minutes of clock drift looks completely healthy in a standard health check until something forces the issue.

Weak TLS on LDAPS

Installing a valid certificate in the DC's Local Computer Personal store automatically enables LDAPS on port 636 (and 3269 for Global Catalog) — Microsoft's own guidance on configuring LDAP over SSL certificates confirms no extra service configuration is required once the certificate is trusted by both the DC and its clients. The problem is that "LDAPS is on" says nothing about which TLS versions and cipher suites it will still accept. A DC that has never had Schannel hardened will negotiate TLS 1.0 or 1.1, and weak CBC/SHA1 cipher suites, with any client willing to offer them — as detailed in DSInternals' walkthrough on enforcing TLS 1.2+ for LDAPS on domain controllers. That matters because LDAP simple binds carry credential material on the wire; a downgraded cipher on the encrypted channel meant to protect them defeats the point of running LDAPS at all.

Detection

Enable Schannel diagnostic logging before you touch anything — you want evidence of what's actually connecting before you disable a protocol version:

# Verbose Schannel event logging (per-connection protocol/cipher detail via Event ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Enumerate the cipher suites currently enabled for TLS on this DC
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite returns the ordered cipher suite list Windows will negotiate — Microsoft documents the full cmdlet reference at Get-TlsCipherSuite (TLS). With EventLogging set, every Schannel handshake to and from the DC lands in the System log under Event ID 36880 with the negotiated protocol version and cipher suite spelled out — that's your evidence of which clients or tools are still forcing a downgrade before you disable anything.

ℹ️

ℹ️ Note: LDAPS weak TLS is a different finding from LDAP signing. If your clients are also sending unsigned SASL or cleartext simple binds, see LDAP Signing Disabled: How Unsigned Binds Expose Active Directory — the two checks are independent and both need to pass.

Remediation

  1. Confirm no legitimate client still needs TLS 1.0/1.1 using the Event ID 36880 evidence above.
  2. Disable TLS 1.0 and TLS 1.1 server-side via the Schannel Protocols registry keys, or use Disable-TlsCipherSuite to strip weak CBC/SHA1 suites while leaving TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384-class suites enabled.
  3. Reboot the DC — Schannel protocol changes only take effect after restart.
  4. Re-run Get-TlsCipherSuite and re-check Event ID 36880 to confirm only strong suites are negotiating.
⚠️

⚠️ Warning: changing Schannel defaults can break older appliances or LDAP clients that only speak TLS 1.0. Roll the change through one DC first and watch the Schannel event log for a full patch cycle before touching the rest.

Domain controllers don't print anything for themselves, so the Print Spooler service has no operational reason to be running on one — yet it ships enabled by default. CISA's PrintNightmare advisory (CVE-2021-34527, CVSS 8.8) turned that default into a low-privilege, authenticated remote-code-execution path — NVD's scoring (PR:L) confirms it takes nothing more than a standard domain account, not admin rights — and CISA's Emergency Directive 21-04 told federal agencies to disable the spooler on every DC — not just patch it.

Patching doesn't retire the underlying design problem, either. Since 2018, the "Printer Bug" (an abuse of the RpcRemoteFindFirstPrinterChangeNotification call in MS-RPRN) lets any authenticated user coerce a DC with the spooler running into authenticating to an attacker-controlled host — documented in Sean Metcalf's Domain Controller Print Server + Unconstrained Kerberos Delegation writeup. Chained with an account that has unconstrained delegation, that coercion hands over the DC's own credential material; chained with a relay, it feeds straight into an NTLM relay attack — the same family of exposure covered in SMB Signing Disabled: Why It Still Enables NTLM Relay. Microsoft Defender for Identity now ships this as a standing security assessment recommending Print Spooler be disabled on DCs.

Detection

Check every DC in the domain in one pass — don't rely on checking the one DC you remember configuring:

$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
}

Also confirm there are no published print queues depending on a DC before you touch it:

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

Remediation

  1. For each DC where Status is Running or StartType is not Disabled, stop and disable the service:
Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName
  1. Enforce it domain-wide with a GPO applied to the Domain Controllers OU (Computer Configuration > Preferences > Control Panel Settings > Services, Spooler set to Stopped/Disabled) so a reboot or manual restart doesn't silently re-enable it.
  2. Re-run the detection loop after the next GPO refresh cycle to confirm the setting stuck across all DCs, including any newly promoted ones — a freshly promoted DC starts with the Spooler service back at its default (running).

Clock Drift Nobody Is Watching

Kerberos timestamps its tickets to block replay attacks, which means authentication depends on every DC's clock staying close to the domain's time source. The tolerance is governed by the Maximum tolerance for computer clock synchronization Kerberos policy — 5 minutes by default, set under Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, per Microsoft's security policy reference. Cross that tolerance and Kerberos authentication fails outright with a KRB_AP_ERR_SKEW response — which gets misread as an application or network problem far more often than it gets correctly diagnosed as clock drift.

The domain's time hierarchy only has one authoritative root: the PDC Emulator. Every other DC syncs from a domain hierarchy peer, and workstations sync from their authenticating DC. If the PDC Emulator itself isn't pointed at a reliable external source, the whole domain can drift together with nothing to disagree against — the failure mode Microsoft's guidance on configuring the root PDC with an authoritative time source is written to prevent. A DC that has quietly been pointed at its own independent NTP source instead of the domain hierarchy is just as much of a problem: it becomes a second, competing time authority that other DCs have no reason to trust over the PDC Emulator, and troubleshooting the resulting intermittent Kerberos failures without that context can burn hours before anyone thinks to check w32tm at all.

Detection

# Current sync status and source on this DC
w32tm /query /status

# Compare offsets across every DC in the domain in one pass
w32tm /monitor

Watch the System log for Event ID 4713 (Kerberos policy changed — DC-only, worth an alert if unexpected) alongside authentication failures that reference KRB_AP_ERR_SKEW; correlated, they point straight at time sync rather than a broken trust or expired credential.

Remediation

💡

💡 Tip: fix the PDC Emulator first. Every other DC and every workstation ultimately measures itself against that one clock.

  1. Identify which DC holds the PDC Emulator role and confirm it — not a peer DC — is configured against an external, reliable NTP source rather than the internal hardware clock.
  2. If the PDC Emulator is drifting or misconfigured, Microsoft's huge time offset remediation guide covers correcting large offsets safely — a naive time jump on a DC can itself break in-flight Kerberos tickets.
  3. Confirm every other DC inherits time from the domain hierarchy (NT5DS) rather than an independent source of its own.
  4. Re-run w32tm /monitor after convergence and confirm all offsets sit comfortably under the 5-minute Kerberos tolerance, not just under it.

Making This a Repeatable Check, Not a One-Time Fix

All three findings above have a habit of quietly regressing: a newly promoted DC restores the Spooler service to its default (running), a replaced certificate can silently reintroduce a weak cipher fallback, and a decommissioned NTP appliance can leave the PDC Emulator without warning. None of it gets caught unless the audit categories that would log it are actually enabled — see Active Directory Audit Policy Configuration Gaps if Schannel or Kerberos policy events aren't showing up where you expect them.

Treat this checklist the same way you'd treat any other drift-prone control: re-run it on a schedule, not just after the first fix. A quarterly pass across all three checks — cipher suites, spooler status, and time offsets — catches the regression before it becomes an incident, and it's a fraction of the effort of the original remediation. The three PowerShell snippets above are short enough to wrap in a scheduled task or CI job rather than run by hand each time.

How EtcSec Detects This

EtcSec's Network category checks all three of these findings on every AD audit: DC_LDAPS_WEAK_TLS flags domain controllers whose LDAPS listener still negotiates a weak TLS version, DC_SPOOLER_ACCESSIBLE flags any domain controller with the Print Spooler service reachable, and DC_TIME_SYNC_ISSUE (paired with NTP_NOT_CONFIGURED) flags DCs drifting from the domain's authoritative time source or missing a configured NTP peer entirely.

ℹ️

ℹ️ Note: EtcSec automatically checks for this vulnerability during every AD/Azure audit. Run a free audit to verify your environment.

Explore the identity security pages that support this topic