iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Audit NTLM before you block it. Build an inventory of accounts, applications, devices, source hosts, destination hosts, and reasons for NTLM use; then replace avoidable dependencies with Kerberos or modern application authentication, pilot restrictions, and expand enforcement only after production-like validation. Windows’ enhanced NTLM auditing and Advanced Audit Policy provide the evidence needed to see which logons would break and which activity is suspicious.
Why should you strengthen Active Directory authentication now?
NTLM is a legacy challenge-response authentication protocol. It can still be required by old applications, appliances, workgroup-style connections, and poorly configured services, but it provides less useful identity assurance and fewer modern protections than Kerberos or application-specific authentication. Treating every NTLM event as an attack is inaccurate; allowing unexplained NTLM indefinitely is unsafe.
The practical objective is controlled reduction: know where NTLM is used, determine whether each use is legitimate, migrate what can be migrated, and block only after you can support the remaining business functions. That approach also gives investigators a baseline for distinguishing normal service activity from password spraying, lateral movement, or misuse of privileged accounts.
How do I audit NTLM before disabling it?
Use two complementary telemetry layers: enhanced NTLM auditing on supported Windows releases, and Advanced Audit Policy in the Windows Security log. The first explains NTLM-specific context; the second supplies the logon and account activity needed to correlate a complete incident.
#1 Best Overall
1. Separate the environment into useful scopes
- Domain controllers: monitor authentication decisions, directory changes, policy changes, and privileged activity.
- Member servers: identify services accepting network logons and the applications that initiate them.
- Workstations: identify workstation-to-workstation authentication, scripts, scheduled tasks, and unmanaged software.
- Trusts and critical services: document external trusts, file shares, line-of-business applications, appliances, and service accounts before changing policy.
Record the owner and business purpose for each critical service. An account or host without an owner is a remediation risk because no one can validate a proposed authentication change or approve an exception.
2. Turn on Advanced Audit Policy
Configure Advanced Audit Policy in Group Policy for consistent deployment. The relevant categories are Logon/Logoff, Account Management, Policy Change, and selected Directory Service and Object Access subcategories. Microsoft’s guidance recommends enabling success and failure auditing where appropriate, especially for logon and policy-change activity.
For a controlled test computer, the same settings can be applied with auditpol.exe. For example:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enableUse the exact subcategory names exposed by the operating system and your organization’s baseline. Group Policy should remain the authoritative configuration in production; local auditpol changes can be overwritten at the next policy refresh.
3. Control event volume deliberately
Object access and process tracking can produce substantial noise and storage demand. Enable them for a defined investigative purpose, on a defined set of systems, with a retention and review plan. Broad collection without ownership makes it harder to find meaningful signals and can increase the exposure of sensitive log data.
Which Windows events reveal suspicious Active Directory logons?
Start with four Security log events, then correlate them with NTLM-specific records and directory or policy events. Event IDs are evidence, not verdicts: a single event needs account, source, destination, process, time, and business context.
| Event | What it records | How to use it |
|---|---|---|
| 4624 | Successful logon | Build a normal-activity baseline. Compare account, logon type, source host, destination host, and time with the account’s expected behavior. |
| 4625 | Failed logon | Investigate bursts, new source hosts, unusual destinations, and repeated service-account failures. A sudden cluster after a policy change can identify a broken dependency. |
| 4648 | Logon attempt using explicit credentials | Review runas, scheduled tasks, scripts, deployment tools, and applications that provide a username and password directly. |
| 4675 | Filtered SIDs during logon | Examine unusual privilege or token-filtering behavior and correlate it with the account, host, and logon sequence. |
| 4024 | NTLMv1-derived credential use during the transition described by Microsoft | Use it to locate NTLMv1 dependencies while moving to enforcement, then identify the owning application or device. |
Keep the full event fields, not just the ID. Account name, domain, logon type, source network address, workstation name, authentication package, process information, and status or substatus codes often determine whether an event is a stale password, a misconfigured service, or an intrusion attempt.
Where do enhanced NTLM audit records appear?
On supported releases, enhanced records are in the Microsoft-Windows-NTLM/Operational channel. Microsoft describes these records as answering three operational questions: who used NTLM, why NTLM was selected, and where the authentication occurred. Review the account, process, source host, destination host, and reason fields together rather than filtering only for a username.
Enhanced NTLM auditing is supported on Windows 11 version 24H2 and later, and on Windows Server 2019, Windows Server 2022, and Windows Server 2025. Older systems may still generate Security log events, but they do not necessarily provide the same enhanced context. Mark the operating-system version and collection capability in your inventory so an apparent absence of NTLM evidence is not mistaken for an absence of NTLM use.
How should I investigate NTLM dependencies?
Prioritize dependencies that create the most security or outage risk, then confirm ownership before changing anything.
Investigate these cases first
- NTLMv1: treat any occurrence as a migration blocker because it is the protocol version targeted by the upcoming default enforcement behavior.
- Unexpected service accounts: check whether a service is using a user account, whether its password is managed, and whether it can use a managed service identity or Kerberos.
- Workstation-to-workstation authentication: validate whether peer access is required. Unusual peer patterns can indicate lateral movement or an unmanaged tool.
- Repeated 4625 failures: distinguish an expired password, a scheduled task with old credentials, a disabled account, and password spraying by comparing source hosts and timing.
- Explicit-credential events (4648): identify scripts, automation, remote-support tools, and deployment jobs that embed or pass credentials.
Trace one authentication attempt end to end
- Start with the NTLM Operational record and note the account, reason, source, destination, process, and timestamp.
- Find the corresponding 4624 or 4625 on the destination system. Confirm the logon type and authentication package.
- Search the source system for 4648, process-creation telemetry, scheduled-task activity, or service restarts at the same time.
- Check whether the account is privileged, shared, expired, disabled, or used by other hosts.
- Ask the service owner to reproduce the connection in a test environment while observing the same fields.
- Document the dependency, its owner, replacement plan, test result, and a dated exception expiration if a temporary exception is unavoidable.
How can I block NTLMv1 without breaking legacy applications?
Do not begin with a domain-wide block. First identify every NTLMv1 consumer, move it to a supported authentication method or replacement, and test the change with realistic workloads.
Use a staged migration
- Baseline: collect NTLM Operational records and Security events long enough to capture routine schedules, backups, month-end jobs, and infrequent maintenance.
- Classify: label each use as Kerberos-capable, upgradeable, replaceable, business-critical legacy, or unexplained.
- Remediate: prefer Kerberos for domain services; update clients, drivers, appliances, and applications that support a modern method; remove hard-coded credentials where possible.
- Pilot: apply restrictions to a pilot organizational unit or controlled server group. Include representative users, service accounts, scheduled tasks, and integrations.
- Observe: watch 4625 failures, NTLM-related errors, service health, and help-desk reports. Compare the pilot’s events with the pre-change baseline.
- Expand: move to additional groups only after owners sign off and rollback steps are verified.
Account for the 2026 NTLMv1 default change
Microsoft states that after the October 13, 2026 Windows security update, an unset BlockNtlmv1SSO value defaults to Enforce mode. That behavior blocks NTLMv1-derived Single Sign-On credentials. Because the date has passed, systems receiving that update should be treated as potentially enforcing the setting even when administrators did not explicitly configure the value.
Use event 4024 and related failure events to find remaining NTLMv1-derived credential use. Verify the update level and effective policy on each affected system, then remediate the application or device instead of creating an indefinite bypass. If a temporary exception is technically necessary, record the exact system, owner, reason, compensating controls, and expiration date.
What is the difference between auditing and enforcement?
Auditing records behavior while allowing it; enforcement rejects behavior. The choice affects visibility, compatibility, storage, rollback, and who must respond when an authentication attempt fails.
| Approach | Visibility | Compatibility impact | Operational requirement |
|---|---|---|---|
| Audit only | Shows users, processes, sources, destinations, and reasons without intentionally blocking the dependency. | Low immediate disruption, but legacy use continues. | Central collection, triage ownership, and a migration backlog. |
| Pilot restriction | Combines evidence with real failure signals in a bounded group. | Manageable if the group is representative and rollback is tested. | Application owners, help-desk readiness, and rapid rollback. |
| Broad enforcement | Provides the strongest reduction in unwanted NTLM use. | Highest risk to unmodernized applications, appliances, and trusts. | Documented exceptions, change control, continuous alerting, and executive ownership of residual risk. |
Choose an approach by asking whether you can correlate account, process, source, and destination; whether event volume and storage are affordable; how quickly you can roll back; and who will triage alerts. A technically strong block with no owner for failures is an outage plan, not a security program.
Free tools Windows power users keep installed
One-click scans. No signup required.
What should I monitor on domain controllers and workstations?
Send Windows Security and NTLM Operational events to a protected central platform so an attacker cannot erase the only copy on a compromised host. Restrict access to the logs, synchronize system clocks, and define retention according to incident-response, legal, and regulatory requirements.
Domain-controller detections
- New or unusual source hosts authenticating to privileged accounts.
- Bursts of 4625 failures across many accounts or destinations.
- 4624 successes for privileged identities outside approved administrative windows.
- 4648 events from unusual processes or non-administrative workstations.
- Policy changes, directory-service modifications, and changes to sensitive groups or objects.
Workstation and server detections
- NTLM use between peers that has no documented business purpose.
- New processes initiating explicit-credential logons.
- Service accounts authenticating interactively or from an unexpected host.
- Repeated failures immediately after a restriction is applied.
- Authentication from a geography, network segment, or device type inconsistent with the account’s role.
Pair authentication monitoring with least privilege, temporary privileged access, secure administrative hosts, and monitoring of sensitive directory objects. NTLM controls reduce one attack path; they do not replace credential hygiene, patching, endpoint protection, or review of directory permissions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do I validate an NTLM restriction before production?
Microsoft advises administrators to review, test, and validate audit policy before deploying it in production. Apply the same discipline to restrictions.
- Export the proposed policy and record its scope, precedence, and effective settings.
- Test ordinary user logon, file access, printing, scheduled tasks, backup, monitoring, software deployment, and administrative workflows.
- Test failure and recovery: confirm that the expected event is generated, the service reports a useful error, and rollback restores operation.
- Measure event volume and central-ingestion capacity during both normal and peak schedules.
- Obtain sign-off from security, infrastructure, and each affected service owner.
- Schedule a change window with a named rollback operator and a communication path for users.
After deployment, compare events with the baseline rather than assuming silence means success. A missing event can mean a collection failure, an unsupported operating system, or a policy that never applied.
Recommended Free Tools
What are the most common failure modes?
- “We enabled auditing but found nothing.” Check the effective Group Policy, channel state, operating-system support, time synchronization, and central collector permissions.
- “A service broke after the pilot.” Correlate the failure time with 4625 and NTLM Operational records, then identify the process and service account before reverting the entire policy.
- “The logs are overwhelming.” Narrow object-access and process-tracking scopes, retain high-value fields, and route only actionable detections to alert queues.
- “The owner says NTLM is required forever.” Ask the vendor or internal team for a supported Kerberos or modern-authentication path, an upgrade date, and a compensating-control plan with an expiration.
- “A domain-wide change produced inconsistent results.” Check organizational-unit inheritance, conflicting policies, system version, update level, and whether the connection crossed a trust or device boundary.
What does a sustainable NTLM-control program look like?
Make the inventory and exception register living operational records. Review new NTLM uses, privileged-account activity, policy changes, directory modifications, and unusual source hosts on a defined cadence. Re-test exceptions when applications, operating systems, trusts, or security updates change.
Set a clear ownership model: security defines detection and risk thresholds; infrastructure manages policy and collection; application owners remove dependencies; and service management tracks deadlines. This turns NTLM reduction from a one-time switch into a repeatable control that improves as legacy systems are retired.
Frequently Asked Questions
Does blocking NTLM disable Kerberos as well?
No. NTLM restrictions target NTLM authentication; Kerberos remains the normal domain authentication protocol when clients, services, DNS, time synchronization, and service-principal configuration support it. A failed Kerberos setup can cause a client to fall back to NTLM, so test name resolution and service configuration before enforcing a block.
Can a local Windows account still log on when NTLM is restricted?
The effect depends on the specific policy and logon path. Local interactive logon, network authentication, service logon, and Single Sign-On are different scenarios; document which path is being restricted and test each one on the operating-system versions in scope.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallHow long should Windows Security and NTLM logs be retained?
There is no universal retention period in the cited Microsoft guidance. Set retention from your incident-response objectives, regulatory duties, storage capacity, and the time needed to investigate delayed discoveries, and protect the central copies from unauthorized deletion.
Why might an NTLM event show a source host I do not recognize?
The source can be a proxying service, scheduled task host, management system, or translated network address rather than the person at the keyboard. Resolve the address, inspect the process and account fields, and compare the timestamp with service, task, and network-device records before classifying it as malicious.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
