Starting point: authentication is often too permissive

In many Active Directory environments, servers, clients and services can still trigger outbound authentication very broadly. A system tries to reach a printer, check a file share, contact a WebDAV target or talk to a remote component through RPC. In daily operations this is barely visible because these paths have grown over years.

From a defensive perspective, coerce attacks use exactly that property: a system is made to authenticate to another destination. The critical point is not one specific exploit, but the combination of uncontrolled outbound authentication, remaining NTLM usage, relay-capable services and limited visibility.

This is therefore not a "apply one patch and move on" topic. Patches matter, but the target state is broader: systems should not be allowed to send authentication to arbitrary networks, untrusted servers or sensitive services.

Target state: authentication has clear guardrails

A workable target state looks like this:

  1. Tier-0 systems do not authenticate outbound unexpectedly. Domain Controllers, CA servers, admin jump hosts and management servers have restrictive outbound paths.
  2. NTLM is visible and reduced. Where Kerberos is possible, NTLM is not accepted as a convenient fallback.
  3. Relay targets are hardened. SMB signing, LDAP signing, LDAP channel binding and Extended Protection are enforced where they fit the service.
  4. Unneeded services are disabled. Print Spooler, WebClient and legacy RPC-dependent roles run only where there is a documented need.
  5. Firewall rules are intentional. Servers are not allowed to talk to arbitrary SMB, HTTP or RPC targets by default.
  6. Exceptions have owners and expiry dates. No permanent "legacy only" openings without review.

The goal is not to block every Windows communication path. The goal is to contain forced authentication as a risk and make operational paths deliberate.

Implementation: make paths visible, then restrict them

1) Identify critical systems and outbound paths

Start with a simple question: which systems would be high impact if they exposed their identity to the wrong destination or became usable through NTLM?

Typical scope:

  • Domain Controllers
  • AD CS servers and enrollment endpoints
  • Admin jump hosts, PAWs and management servers
  • Backup, deployment and monitoring systems
  • File servers with administrative shares
  • Application servers running privileged service accounts

Then you need visibility into outbound connections: SMB, HTTP/HTTPS, WebDAV, RPC, print services, LDAP and NTLM usage. This does not require a large sensor program for the first pass. Firewall logs, Windows event logs, NTLM auditing and the existing EDR stack are often enough to prioritize.

2) Enable NTLM auditing and sort dependencies

Coerce risk becomes much larger when NTLM is still normal in critical paths. Start with auditing, not immediate hard blocking.

Practical questions:

  • Which servers still accept NTLM for administrative or business services?
  • Which clients or applications use NTLM even though Kerberos should be possible?
  • Which targets receive NTLM from Tier-0 systems?
  • Are there external, DMZ or partner targets with NTLM dependencies?
  • Which systems would fail immediately if NTLM was restricted?

After that, restrict in waves: first Tier 0 and management paths, then critical server roles, then broader server and client groups. A blanket NTLM shutdown without inventory is rarely clean. Permanent tolerance without a plan is not acceptable either.

3) Restrict outbound authentication from servers

Servers rarely need arbitrary outbound access to SMB, WebDAV or internal HTTP endpoints. That is where firewall design pays off.

Useful guardrails:

  • Domain Controllers can only talk to defined management, backup, monitoring and replication targets.
  • CA servers can reach PKI-relevant paths, not arbitrary file servers or WebDAV targets.
  • Admin jump hosts receive restrictive outbound rules and no open legacy paths.
  • Server-to-server SMB is handled with allowlists.
  • Internet egress from Tier-0 systems is an exception, not a default.

This is not an "block everything" project. Start in audit or pilot mode, document legitimate destinations and then close the obvious gaps.

4) Reduce services that can trigger authentication

Many coerce paths depend on Windows services and roles that were never decided cleanly in server baselines.

Review especially:

  • Print Spooler: not required on Domain Controllers and most servers.
  • WebClient/WebDAV: often unnecessary on servers and risky for authentication redirection.
  • Legacy file and print paths: old applications sometimes force messy exceptions.
  • RPC-dependent roles: do not disable blindly, but require a role-specific reason.
  • AD CS web components: enrollment web pages and HTTP-based endpoints should only run when needed and hardened.

The clean approach is a role baseline: which services belong on DCs, CA servers, file servers and jump hosts? Everything else needs a reason.

5) Harden relay targets, not just triggers

Coerce reduction only works if potential target systems are hardened as well. Otherwise the path remains even when individual triggers disappear.

Important controls:

  • Require SMB signing on critical server paths.
  • Plan and enforce LDAP signing and LDAP channel binding for Domain Controllers.
  • Review Extended Protection for suitable HTTP-based Windows and AD CS services.
  • Block insecure guest logons and anonymous enumeration.
  • Prevent NTLM fallbacks from returning unnoticed.
  • Assess AD CS templates, enrollment rights and web enrollment separately.

This does not prevent every form of forced authentication. It does remove impact from many relay-style scenarios.

6) Treat administrative paths separately

Admin jump hosts, PAWs, management servers and backup systems are not normal client scope. If these systems authenticate unexpectedly to arbitrary destinations, the result can quickly become Tier-0 risk.

Apply stricter rules:

  • no normal user or server-admin logons on Tier-0 systems,
  • document and restrict outbound network paths,
  • avoid stored credentials,
  • reduce local admin rights,
  • centralize EDR and firewall events,
  • bring new servers into the right baselines automatically.

Administrative systems need a small and understandable communication matrix. If nobody can explain where a jump host must talk, that is a finding in itself.

7) Roll out changes in waves

A pragmatic sequence:

  1. Inventory Tier-0 and management systems.
  2. Collect NTLM and outbound connection data.
  3. Disable clearly unneeded services in pilot groups.
  4. Test firewall allowlists for critical server roles.
  5. Harden SMB, LDAP and HTTP targets against relay.
  6. Document exceptions with owner, reason and expiry date.
  7. Move the baseline into GPO, endpoint management or the server build process.

The order matters. Do not wait for a perfect architecture. Start with the riskiest systems and add measurable guardrails there.

Advantages (explicit)

  • Reduces relay impact: forced authentication is less likely to lead to usable follow-on paths.
  • Protects Tier 0 better: DCs, CAs and admin systems send less unexpected authentication to the wrong destinations.
  • Exposes legacy dependencies: NTLM, WebDAV, print and RPC dependencies become measurable instead of assumed.
  • Improves operating architecture: server roles receive clearer communication rules.
  • Complements existing baselines: SMB signing, LDAP signing, NTLM reduction and Spooler hardening work together.

Disadvantages and limits (explicit)

  • Inventory takes time: without connection data, firewall and NTLM changes become guesswork.
  • Legacy can break: old applications, print workflows, scanners, backup agents and appliances sometimes use unexpected paths.
  • Not every trigger can be disabled: some RPC or management functions are business requirements.
  • Controls only work together: disabling one service helps little if relay targets remain weak.
  • Exceptions need maintenance: a good allowlist becomes stale when server roles and applications are not reviewed.

Common project pitfalls

  • Searching only for famous attack names: the authentication path matters more than the tool or technique name.
  • Treating Tier 0 like normal servers: DCs, CAs and jump hosts need stricter outbound rules.
  • Blocking NTLM immediately: without an audit phase, outages and rollbacks are likely.
  • Missing WebClient: WebDAV is often unnecessary on servers, but server baselines leave it undecided.
  • Excluding AD CS: enrollment endpoints and web components are especially sensitive in relay reviews.
  • Firewall rules without owners: nobody removes exceptions if they are not documented.
  • Hardening inbound only: outbound authentication matters just as much for this risk.

Project checklist

  • [ ] Define Tier-0 systems, management servers and critical application servers as the first scope.
  • [ ] Enable NTLM auditing and centralize the results.
  • [ ] Collect outbound SMB, HTTP/WebDAV, RPC and LDAP paths for critical systems.
  • [ ] Review Print Spooler, WebClient and unneeded roles per server baseline.
  • [ ] Plan SMB signing, LDAP signing, LDAP channel binding and Extended Protection by role.
  • [ ] Review AD CS web components, templates and enrollment rights separately.
  • [ ] Pilot firewall allowlists for DCs, CAs, jump hosts and management servers.
  • [ ] Document exceptions with owner, business reason, expiry date and review cycle.
  • [ ] Monitor for new NTLM paths and unexpected outbound authentication.
  • [ ] Move the baseline into GPO, endpoint management and the server build process.