Disable Legacy Protocols (NTLMv1, LLMNR): What Breaks and How to Replace

What you’re actually fixing (threat model, not vibes)

Disabling NTLMv1 and LLMNR is less about being “modern” and more about cutting off two classes of failures:
(1) weak or replayable authentication, and (2) name-resolution behavior that lets attackers insert themselves into your traffic.

NTLMv1: weak challenge/response, legacy defaults, and a long tail of “it still works”

NTLM is a Windows authentication protocol family. NTLMv1 is the oldest and weakest form you still see in real
enterprises. The problem isn’t just cryptographic strength; it’s how easy NTLM traffic is to coerce, relay, or
downgrade when you have mixed clients and permissive policies.

When NTLMv1 is allowed, you’ve created a soft landing for old clients and misconfigured apps. Some of those “apps”
are actually scheduled tasks, printers, NAS appliances, and mystery services that were installed in 2014 and never
touched again because they “just work.”

LLMNR: helpful on small networks, dangerous on real ones

LLMNR (Link-Local Multicast Name Resolution) is what machines do when DNS fails or isn’t configured right and they
still want to resolve fileserver or printer-7. It uses multicast on the local segment.
It’s convenient. It’s also a gift to anyone running responder-style tooling on the same network.

If you disable LLMNR but keep DNS messy, users will complain that “the network is broken.” The network wasn’t broken.
It was improvising.

One reliability rule applies hard here: make name resolution deterministic, and authentication strict. Everything else is theater.

One quote, paraphrased idea: Gene Kranz’s idea (paraphrased): “Be tough and competent” — systems don’t care about excuses, only outcomes.

Joke #1: Disabling NTLMv1 is like cleaning the attic: you’ll find a lot of old stuff, and at least one thing that hisses at you.

Interesting facts and history you can use in meetings

• NTLM is older than your cloud strategy. NTLM traces back to Windows NT-era designs; Kerberos arrived with Active Directory to replace it for domain auth.
• NTLMv1 uses older DES-based constructions. It’s one reason it’s considered materially weaker than NTLMv2, especially under capture-and-crack scenarios.
• NTLM persists because it’s “just SMB auth.” Many people assume NTLM is only about file shares. It shows up in HTTP, LDAP binds, RPC, and odd corners.
• LLMNR was meant to reduce dependency on DNS in small networks. It’s essentially “DNS-like behavior” without the admin overhead, which is exactly why it becomes a crutch.
• LLMNR often pairs with NBT-NS. On Windows networks, disabling one but leaving the other can still allow name-poisoning and credential capture attempts.
• Credential coercion attacks love multicast. When endpoints ask “who is FILESERVER?”, an attacker can answer faster than the real server and prompt authentication.
• Kerberos can fail for boring reasons. Time skew, SPN mistakes, and DNS errors can push clients toward NTLM fallbacks unless you close the door.
• Hardening broke things long before “Zero Trust” was branded. Most outages from disabling legacy auth come from undiscovered dependencies, not from the protocol change itself.

What breaks when you disable NTLMv1 and LLMNR

When you disable NTLMv1: what actually fails

“Disable NTLMv1” sounds simple until you realize most environments don’t have “NTLMv1-only clients.” They have
a handful of devices and services that still negotiate down, often silently. Common breakage modes:

• Old NAS and appliances joining AD: Some embedded SMB stacks still attempt NTLMv1 or do NTLM sign/seal weirdly.
  Symptom: share access prompts repeat, or “The specified network password is not correct.”
• Legacy scanners/printers using “scan to folder”: They often store credentials and attempt SMB auth with old dialects.
  Symptom: scans stop arriving; device UI says “login failed.”
• Custom apps using old libraries: Especially anything doing integrated auth over HTTP to IIS or reverse proxies.
  Symptom: 401 loops, authentication fallback, or app silently switches to “local accounts.”
• Old Windows versions or misconfigured security policies: Some endpoints will negotiate poorly if policies are inconsistent.
  Symptom: sudden spikes in helpdesk calls after a GPO change, affecting a subset of machines.
• Service accounts with missing SPNs: If Kerberos can’t be used, clients may try NTLM; if you block NTLM family too aggressively, the service looks down.
  Symptom: “server not available,” but only for domain users.

When you disable LLMNR: what actually fails

LLMNR is less about “authentication breaking” and more about “people stop being able to find things by vibes.”
Specifically, anything relying on short names, single-label hostnames, or stale DNS will hurt.

• Users mapping drives via short names: \\fileserver\share works until DNS is wrong and LLMNR used to rescue it.
• RDP to short hostnames: People type rdp fileserver and it “worked” due to multicast or cached junk.
• Scripts using unqualified names: Automation that assumes local broadcast name resolution will now fail fast.
• Multi-subnet environments: LLMNR doesn’t cross routers the way DNS does. If it was “helping,” you already had a bigger DNS design problem.

Disabling LLMNR doesn’t create the underlying failure. It makes it visible. That’s the kind of break you want in production:
a broken assumption, not a broken protocol.

What to use instead (the replacements that work)

Replace NTLMv1 with: Kerberos first, NTLMv2 only as a controlled fallback

The practical target isn’t “no NTLM ever” on day one. It’s:

1. Kill NTLMv1 everywhere you can.
2. Require NTLMv2 where NTLM still exists.
3. Drive Kerberos adoption by fixing DNS, SPNs, and time sync.
4. Constrain and monitor NTLM with auditing, allowlists, and eventually blocking.

If your environment is AD-backed and you can’t make Kerberos reliable, you don’t have an “auth protocol” problem.
You have a fundamentals problem: DNS correctness, time correctness, identity hygiene.

Replace LLMNR with: good DNS and good client behavior

LLMNR exists because DNS often isn’t trustworthy enough for endpoints. So the replacement is boring:

• Accurate DNS A/AAAA records for servers and appliances.
• Consistent search suffixes via DHCP options or GPO so single-label names resolve predictably (or don’t resolve at all).
• Stop using single-label names in scripts and runbooks; use FQDNs.
• Disable LLMNR and NBT-NS where possible, together, and measure the fallout.

Security controls that make the transition less painful

• SMB signing where feasible, especially for admin shares and server-to-server access.
• LDAP signing/channel binding to cut off downgrade paths and relays that often travel with NTLM abuse.
• Firewall segmentation so random endpoints can’t talk to random endpoints on SMB/HTTP/RPC and “helpfully” authenticate.
• Credential guard / LSA protections on endpoints to reduce credential material exposure.

Joke #2: LLMNR is like asking a crowded room who your friend is, then handing your wallet to the first person who answers.

Fast diagnosis playbook (first/second/third checks)

You disabled NTLMv1 or LLMNR and now something is broken. Do not start by rolling back the policy “just to get Monday going.”
Start by proving what broke and where the dependency lives. Here’s the fastest path.

First: identify whether it’s name resolution or authentication

• Can the client resolve the server via DNS? If not, LLMNR/NBT-NS used to patch the hole.
• Can the client reach the server on the expected port? If not, it’s routing/firewall, not auth.
• Is the failure “access denied” vs “host not found”? That splits the problem cleanly.

Second: determine which auth protocol was attempted

• Kerberos vs NTLM? Check Windows security events, server logs, or packet capture on a test box.
• NTLMv1 vs NTLMv2? If you’re still allowing NTLMv2, the only break should be truly ancient clients or mis-negotiation.

Third: locate the dependency and choose a replacement

• If it’s an appliance, check firmware/SMB settings and whether it supports NTLMv2 or Kerberos.
• If it’s an app, check whether it can use Kerberos/Negotiate, modern libraries, or service principal names.
• If it’s a user habit, fix the runbooks and scripts and enforce FQDN usage.

The “bottleneck” in these incidents is rarely CPU or network. It’s ambiguity: uncertain name resolution and silent auth fallback.
Your job is to remove ambiguity.

Practical tasks: commands, outputs, and decisions

Below are hands-on tasks you can run from a Linux admin host (or troubleshooting VM) that’s on the same network and can reach AD services.
Some tasks also interrogate Windows behavior via Samba tooling. For Windows-native commands, you’d normally use PowerShell;
here, we focus on commands you can actually run from a shell in incident mode.

Task 1 — Detect LLMNR on the wire (are clients still shouting?)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:31:02.114890 IP 10.20.1.45.56724 > 224.0.0.252.5355: UDP, length 62
12:31:02.114932 IP 10.20.1.71.57811 > 224.0.0.252.5355: UDP, length 62
5 packets captured

What it means: You’re seeing LLMNR multicast (224.0.0.252:5355). Clients are still attempting it.

Decision: If you intended LLMNR to be disabled, verify GPO scope/MDM coverage; also validate DNS so clients stop needing it.

Task 2 — Detect NBT-NS (the other legacy name poison vector)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 137 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:32:19.901220 IP 10.20.1.45.137 > 10.20.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; name="FILESERVER<00>"
5 packets captured

What it means: NetBIOS Name Service broadcasts are still in play.

Decision: Plan to disable NetBIOS over TCP/IP where possible, or contain it via segmentation. Disabling LLMNR alone is not the whole story.

Task 3 — See whether DNS can resolve the host users keep typing

cr0x@server:~$ getent hosts fileserver

What it means: No output usually means it’s not resolvable via configured resolvers/search domains.

Decision: Fix DNS records and/or search suffix configuration. If you want to ban single-label names, make scripts use FQDNs and enforce it culturally.

Task 4 — Validate DNS from a specific resolver (stop guessing)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example A +noall +answer
fileserver.corp.example. 300 IN A 10.20.5.20

What it means: DNS knows the answer and TTL is sane.

Decision: If DNS is correct but clients still use LLMNR, check client DNS suffix list and whether they’re querying the right DNS servers.

Task 5 — Check reverse DNS (Kerberos and logging sanity benefit)

cr0x@server:~$ dig @10.20.0.10 -x 10.20.5.20 +noall +answer
20.5.20.10.in-addr.arpa. 300 IN PTR fileserver.corp.example.

What it means: PTR exists. That helps with audits, some tooling, and reduces “mystery IP” operational pain.

Decision: Missing reverse DNS won’t always break Kerberos, but it will break your ability to diagnose quickly. Fix it anyway.

Task 6 — Check time sync on Linux (because Kerberos is allergic to time travel)

cr0x@server:~$ timedatectl status
               Local time: Tue 2026-02-05 12:35:10 UTC
           Universal time: Tue 2026-02-05 12:35:10 UTC
                 RTC time: Tue 2026-02-05 12:35:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

What it means: Time is synchronized. Good.

Decision: If auth is failing mysteriously, verify time on clients, servers, and domain controllers. Fix skew before blaming Kerberos.

Task 7 — Obtain a Kerberos ticket for a domain user (proves Kerberos path works)

cr0x@server:~$ kinit user1@CORP.EXAMPLE
Password for user1@CORP.EXAMPLE:

What it means: If it returns to the prompt without error, you got a TGT.

Decision: If this fails, look at DNS to KDCs, time skew, realm config, and firewalling to DCs before touching NTLM policies.

Task 8 — Inspect the ticket cache (confirm realm/KDC details)

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user1@CORP.EXAMPLE

Valid starting     Expires            Service principal
02/05/26 12:36:20  02/05/26 22:36:20  krbtgt/CORP.EXAMPLE@CORP.EXAMPLE

What it means: You have a TGT; Kerberos basics are functioning.

Decision: If clients still use NTLM, the issue is likely SPN/service config, not “Kerberos is down.”

Task 9 — Verify SPN-style access to a CIFS service using Kerberos (SMB with Kerberos)

cr0x@server:~$ smbclient -k -L //fileserver.corp.example -m SMB3
Anonymous login successful

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share
SMB1 disabled -- no workgroup available

What it means: -k uses Kerberos. Seeing shares means Kerberos auth succeeded (despite the confusing “Anonymous login successful” line smbclient sometimes prints).

Decision: If Kerberos works from a test host but Windows clients fall back to NTLM, inspect SPNs and how clients resolve the server name.

Task 10 — Force NTLMSSP in smbclient (to prove NTLM is still being used somewhere)

cr0x@server:~$ smbclient -U 'CORP\user1' -L //fileserver.corp.example -m SMB3 --option='client use spnego=no'
Password for [CORP\user1]:

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share

What it means: You just authenticated using NTLMSSP (NTLM family). Whether it negotiated v1 or v2 depends on client/server policy.

Decision: If disabling NTLMv1 breaks this, you have a legacy negotiation problem—often an old appliance or an old server-side setting.

Task 11 — Enumerate SMB dialect support (find SMB1 landmines)

cr0x@server:~$ smbclient -L //fileserver.corp.example -m SMB1
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

What it means: SMB1 is not supported/disabled on the server (good). Many NTLMv1 holdouts correlate with SMB1-era devices.

Decision: If your appliance only supports SMB1, don’t “make an exception.” Replace or isolate it. Exceptions become permanent.

Task 12 — Scan for LLMNR responders (you want zero)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:40:11.004321 IP 10.20.1.45.5355 > 224.0.0.252.5355: 1234+ A? wpad. (34)
12:40:11.006002 IP 10.20.1.200.5355 > 10.20.1.45.5355: 1234* 1/0/0 A 10.20.1.200 (50)

What it means: A host (10.20.1.200) answered an LLMNR query for wpad. That is either a misconfiguration or an active poisoning risk.

Decision: Identify that host immediately. If it’s not a sanctioned resolver, quarantine it and investigate. Also: fix DNS so clients aren’t asking multicast for WPAD.

Task 13 — Check whether WPAD is resolvable via DNS (avoid “helpful” proxy auto-detect drama)

cr0x@server:~$ dig @10.20.0.10 wpad.corp.example A +noall +answer

What it means: No DNS record. If clients have proxy auto-detect enabled, they may try LLMNR/NBT-NS for WPAD.

Decision: Either properly implement WPAD with tight controls, or explicitly disable proxy auto-detect. Don’t leave it in a half-state.

Task 14 — Quick port reachability to a domain controller (auth failures that are actually firewalls)

cr0x@server:~$ nc -vz dc1.corp.example 88
Connection to dc1.corp.example 88 port [tcp/kerberos] succeeded!

What it means: Kerberos TCP/88 is reachable. (UDP also matters, but this is a fast signal.)

Decision: If this fails from certain subnets, you have segmentation issues. Fix routing/firewalls before blaming NTLM changes.

Three corporate mini-stories from the field

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company decided to “just disable NTLMv1” because a security scanner flagged it. The IAM team applied a GPO
targeting “All Workstations,” then sent a celebratory message about progress.

Monday morning, operations couldn’t access a set of file shares used by a manufacturing line. Not everyone—just the kiosks on the shop floor.
The helpdesk treated it like an outage and began rebooting everything that had a power button. That’s not troubleshooting; that’s ritual.

The wrong assumption: “Those kiosks are Windows 10, so they must be using NTLMv2 or Kerberos.” They were Windows 10,
but the real dependency was a decade-old NAS, joined to the domain long ago. It supported NTLM, but its SMB stack negotiated
down in ways the team never tested. The kiosks weren’t the problem. The server was.

Once the NAS was identified, the resolution was brutally simple: move the shares to a supported file server, then
isolate the NAS for archival-only access. The real lesson wasn’t “don’t disable NTLMv1.” It was “don’t let production depend on
devices you can’t patch and can’t observe.”

Mini-story 2: The optimization that backfired

Another org wanted to reduce log volume and “noise” in their SIEM. They tuned out a set of authentication events because
“it’s all normal Windows chatter.” This happened right before a project to disable LLMNR.

After LLMNR was disabled, a subset of users started seeing intermittent login prompts when accessing internal web apps.
The team suspected the new policy, then suspected the load balancer, then suspected the IdP. They spent two days bouncing between teams,
because the logs that would have proven the auth protocol downgrade were now filtered out.

The backfire: by optimizing away “noisy” authentication telemetry, they made root-cause analysis slower and more political.
Eventually a packet capture showed clients failing to resolve the correct backend name via DNS, then trying fallback paths.
NTLM was being triggered via a legacy hostname, and disabling LLMNR just removed the accidental success cases.

Fixes were boring: correct DNS records, enforce FQDNs in app configs, and reinstate the security events—this time with smarter
parsing and alerting rather than blunt suppression. The operational takeaway: if you’re about to change auth behavior, keep the auth logs.

Mini-story 3: The boring but correct practice that saved the day

A large enterprise did the whole thing the unsexy way. Before touching GPOs, they ran NTLM auditing for weeks and tagged every event
with the source client, target server, and application owner. They created a simple workflow: “If you own the target, you own the fix.”

They also maintained a test OU that mirrored production policies. Every candidate change—disable LLMNR, require NTLMv2,
restrict NTLM—was applied there first. They forced key business apps to run from that OU for a day each, with a rollback window.
It wasn’t glamorous. It was effective.

When they finally disabled NTLMv1 broadly, the only outages were pre-identified: a couple of scanners, an old Java app,
and one vendor appliance. They had remediation plans ready: firmware upgrades, migration to SFTP, and one vendor escalation
with a hard deadline.

The practice that saved them: strict change management with instrumentation, not paperwork. They didn’t “hope” nothing depended on NTLMv1.
They collected proof, then made the change. Reliability sometimes looks like being the person who insists on measuring things.

Common mistakes (symptoms → root cause → fix)

1) “Users can’t access shares anymore” after disabling NTLMv1

Symptoms: repeated credential prompts; “access denied”; some clients work, others don’t.

Root cause: a storage appliance or old server negotiates NTLMv1 or SMB1-era auth behavior; Kerberos isn’t being used due to SPN/DNS issues.

Fix: confirm Kerberos works to the CIFS SPN name; fix DNS/FQDN usage; upgrade/migrate the appliance; require NTLMv2 as a stepping stone.

2) “Disabling LLMNR broke everything” (it didn’t; your DNS did)

Symptoms: short hostnames stop resolving; drive mappings fail; scripts fail on one subnet.

Root cause: missing DNS records, incorrect DHCP DNS servers, missing search suffixes, or reliance on single-label names.

Fix: correct A/PTR records; ensure DHCP pushes proper DNS servers and suffix; update scripts to FQDNs; remove reliance on broadcast name resolution.

3) “Kerberos is flaky, so we need NTLM”

Symptoms: intermittent auth failures; works after reboot; works for some users.

Root cause: time skew; SPN collisions; clients resolving different names than the SPN expects; constrained delegation misconfigurations.

Fix: enforce NTP; audit SPNs; standardize hostnames and certificates; treat DNS as production-critical, not “network team stuff.”

4) “We blocked NTLM and now an app is down”

Symptoms: internal web app returns 401; authentication loops; service-to-service calls fail.

Root cause: app pool identity/SPN not configured; the app uses NTLM explicitly instead of Negotiate; proxy/load balancer breaks Kerberos.

Fix: configure SPNs for the service account; ensure clients use the correct FQDN; check delegation requirements; if necessary, keep NTLMv2 temporarily but constrain it.

5) “We disabled LLMNR but Responder still captures things in a test”

Symptoms: multicast/broadcast name traffic still present; credential prompts triggered by bogus names.

Root cause: NBT-NS still enabled; WPAD/proxy auto-detect still active; other discovery protocols are in play.

Fix: disable NBT-NS where possible; control WPAD; segment networks; reduce lateral reachability (SMB/RPC) between clients.

Checklists / step-by-step plan

Phase 0 — Make it observable (don’t change what you can’t see)

1. Enable and centralize authentication telemetry (NTLM usage, failures, fallbacks).
2. Start capturing LLMNR/NBT-NS traffic samples per VLAN to understand where it’s used.
3. Build an inventory list: file servers, NAS, printers/scanners, app servers, load balancers, domain controllers.
4. Identify “non-human” access paths: service accounts, scheduled tasks, device-stored creds.

Phase 1 — Fix DNS so LLMNR becomes irrelevant

1. Ensure every server has correct A/AAAA and PTR records.
2. Standardize search suffix distribution (DHCP/GPO) and verify clients receive it.
3. Update drive mappings, scripts, and runbooks to use FQDNs.
4. Decide on policy for single-label names: discourage or outright block in tooling.

Phase 2 — Disable LLMNR (and preferably NBT-NS) in controlled scope

1. Apply GPO/MDM to a pilot OU first (IT, power users, a representative business unit).
2. Watch for name-resolution incidents; when they occur, fix DNS, not policy.
3. Expand scope VLAN by VLAN or site by site.

Phase 3 — Remove NTLMv1 and tighten NTLMv2

1. Set clients and servers to refuse NTLMv1; require NTLMv2 where NTLM remains.
2. Fix Kerberos blockers: time sync, SPNs, service account hygiene, DNS correctness.
3. Upgrade or replace appliances that can’t do NTLMv2 or Kerberos.
4. Keep an exception register with expiration dates. If it doesn’t have an expiration, it’s not an exception; it’s policy.

Phase 4 — Constrain or eliminate NTLM (optional, but where you want to end up)

1. Block NTLM to high-value servers first (domain controllers, admin endpoints, management planes).
2. Use allowlists for unavoidable legacy dependencies, then burn them down over time.
3. Validate that all new apps and vendors support Kerberos or modern auth patterns.

FAQ

1) If we disable NTLMv1, do we automatically get Kerberos everywhere?

No. You get failures where Kerberos can’t be used (SPN/DNS/time issues) and where clients/devices only know NTLMv1.
The win is forcing those problems into the light so you can fix them.

2) Is disabling LLMNR enough, or do we also need to disable NBT-NS?

If you want to reduce name-poisoning and responder-style attacks, you typically need both. LLMNR and NBT-NS are cousins.
Disabling just one often leaves an alternate path.

3) Why did things “work” before if DNS was wrong?

Because multicast/broadcast name resolution and caches create accidental success. It’s like a system that “works” because retries hide the bug.
You don’t have reliability; you have luck.

4) What’s the safest order: disable LLMNR first or NTLMv1 first?

Usually fix DNS → disable LLMNR/NBT-NS → then remove NTLMv1. LLMNR changes are mostly name resolution and user habit.
NTLMv1 changes can break devices and auth flows more sharply.

5) We have printers/scanners that can’t do Kerberos. What’s the least bad option?

Prefer devices that support modern SMB and NTLMv2 at minimum, or switch the workflow: scan to email, SFTP, HTTPS upload,
or a broker service. If you must keep legacy SMB, isolate it on a dedicated VLAN and restrict which servers it can talk to.

6) Does SMB signing replace the need to disable NTLMv1?

No. SMB signing helps prevent certain tampering and some relay scenarios, but it doesn’t magically upgrade weak authentication.
You still want NTLMv1 gone, and ideally Kerberos for domain access.

7) How do we avoid a helpdesk flood when disabling LLMNR?

Preemptively fix DNS for top-used services (file servers, print servers, intranet endpoints), push search suffixes consistently,
and update drive mapping GPOs/scripts to FQDNs. Also: communicate the new “use FQDN” rule in IT-run docs.

8) What’s the telltale sign that Kerberos isn’t being used?

Repeated login prompts, NTLM-related server events, and authentication succeeding only when using an IP address or a short hostname.
Kerberos is name-sensitive. If you access a service via a name that doesn’t match its SPN, Kerberos won’t happen.

9) Can we just block all NTLM immediately?

You can, if you enjoy unplanned downtime and emergency “temporary” exceptions. A staged approach with auditing and targeted blocking
gets you to the same destination without setting fire to operations.

Next steps that won’t ruin your weekend

If you want a practical, low-drama plan, do this in order:

1. Measure current state: capture LLMNR/NBT-NS traffic; audit NTLM usage; list the top talkers.
2. Fix DNS: A/PTR records, suffixes, and FQDN usage in configs and scripts.
3. Pilot-disable LLMNR (and ideally NBT-NS): small scope, fast feedback, fix root causes.
4. Disable NTLMv1: require NTLMv2; migrate or isolate devices that can’t comply.
5. Make exceptions expensive: every exception has an owner, a reason, and an expiration date.
6. Keep auth logs: don’t “optimize” away the telemetry that tells you whether your environment is improving.

The end state is simple: endpoints resolve names via DNS, authenticate via Kerberos, and fall back to NTLMv2 only where you explicitly allow it.
Everything else is legacy inertia. Burn it down carefully.