Windows Server 2025 SMB NTLM blocking: verify Kerberos and retire exceptions

Before enabling SMB client NTLM blocking, identify the applications, services, and scheduled tasks that still use NTLM. Then test fresh connections in their actual execution contexts, collect evidence of Kerberos session authentication, and remove exceptions through a controlled change.

Windows Server 2025 introduced outbound SMB client NTLM blocking. For teams adopting supported clients, the practical opportunity is to turn that capability into a repeatable migration process. Windows Server 2025 capabilities

The client requires Windows Server 2025 or Windows 11 24H2 or later; the destination can use Kerberos or PKU2U. This AD validation procedure requires evidence of Kerberos. Microsoft’s configuration guidance dates to November 2024, so this is an adoption-stage project, not a new October 2026 feature. SMB NTLM blocking guidance

Map dependencies before enforcement

Start with a representative pilot containing user workstations, an administrative workstation, and clients running services or scheduled tasks. Agree on an observation period that includes the relevant business cycles, backups, and infrequent jobs. Record which devices are missing from collection; silence from an unmonitored device is not evidence of readiness.

Create one inventory row per client → destination → share → application, service, or task. Capture:

• The exact UNC path, including any short name, FQDN, alias, or IP address.
• Client OS version and build, destination, and actual execution identity and logon context.
• Application, service, or task name; technical and business owners; business impact; and operating schedule.
• Observed authentication, supporting records, collection gaps, remediation plan, and next test date.

Ask owners to include mapped drives, backup software, scanners, appliances, and unattended jobs. Reconcile their answers with observations rather than assuming that either source is complete.

For pre-enforcement discovery, configure Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers as Audit all on the Windows clients in scope. Find it under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Collect Microsoft-Windows-NTLM/Operational from those clients. This audits outgoing NTLM requests, covering both NTLMv1 and NTLMv2 rather than filtering for NTLMv1 alone. Its scope extends beyond SMB. Outgoing NTLM audit policy

Verify policy delivery and log forwarding on each pilot client. Correlate timestamps, client, account, destination, and available process information with application configuration and controlled executions. Attribute each candidate dependency to SMB before adding it to the SMB exception register. Where records cannot identify the application or protocol, reproduce the operation while collecting a trace. Include non-Windows and unmonitored clients through destination evidence and owner-led tests; mark unresolved coverage explicitly.

Collect successful-logon auditing on Windows file servers as well. Event 4624 is generated on the accessed computer, so domain-controller records do not inventory logons to member file servers. For NTLM records, inspect the authentication package and NTLM package-version field where populated. Event 4624 reference

Apply Microsoft’s narrower NTLMv1 interpretation warning: an anonymous session can appear as NTLMv1 because no NTLMv2 key material exists. Exclude ANONYMOUS LOGON from conclusions about protocol-version usage. NTLMv1 audit interpretation

Verify the actual SMB session

Use an isolated test account for preliminary troubleshooting only. Acceptance testing must run the real application, service, or scheduled task with its configured identity, credential source, and logon context. An administrator opening the same share does not validate an unattended job.

Treat ticket acquisition as a diagnostic. klist defaults to the current user’s logon session; use klist sessions and the appropriate -li and, when needed, -lh values to inspect the intended context with suitable privileges. klist get cifs/fileserver.example.com requests a ticket; it does not prove that the application used it. klist reference

Use this acceptance sequence:

1. Record the current policy, local client settings, exceptions, and mapping options so each change can be reversed. Identify the exact destination and execution context being tested.
2. Apply blocking and verify the effective client state. Confirm that no applicable destination exception remains. Save the resulting policy report and client configuration, not just the intended GPO settings.
3. Arrange a maintenance window for the affected process. Close its files, stop the application or task as appropriate, and disconnect its mappings and other SMB connections to the destination in the relevant logon context. Check that the old session is gone using client and server session information. Removing one drive mapping is insufficient if another connection still shares the session.
4. If targeted cleanup cannot establish a clean starting point, use an isolated pilot client and restart it before launching the real process. For a service or scheduled task, retain its normal configured identity and launch mechanism. Do not substitute an interactive administrator session.
5. Start evidence collection before the process reconnects. Require a new authentication event or SMB Session Setup exchange; a reopened file on an existing session does not qualify.
6. Complete the real operation: for example, open, modify, save, and close a document, run the scheduled transfer, or perform the agreed backup or restore test.

For authentication evidence, use a destination-side 4624 network logon with Authentication Package: Kerberos, correlated to the actual operation. Match account, time, source information where available, and session or application evidence. Fields may be absent; a record showing only Negotiate is insufficient for this acceptance criterion. Event 4624 authentication fields

If server records cannot establish the association, capture the fresh SMB Session Setup exchange. Inspect the authentication token for a Kerberos AP-REQ targeting the relevant cifs/ service, confirm successful setup, and follow that session into the tested share operation. Microsoft provides contrasting Kerberos and NTLMSSP SMB traces. Merely seeing Kerberos in the offered mechanism list is insufficient. Microsoft’s SMB authentication trace examples

Accept the path only when effective blocking, absence of an applicable exception, fresh authentication, correlated Kerberos evidence, and successful business execution are all documented. Otherwise record the result as failed or inconclusive.

Configure the pilot and prepare rollback

The GPO setting is Block NTLM (LM, NTLM, NTLMv2) under Computer Configuration > Administrative Templates > Network > Lanman Workstation. Alternatives are Set-SmbClientConfiguration -BlockNTLM $true and per-mapping New-SmbMapping -RemotePath \\fileserver.example.com\share -BlockNTLM $true or NET USE \\fileserver.example.com\share /BLOCKNTLM. Configuration methods

Prefer one managed configuration method for the pilot. If testing uses several mechanisms, record each separately and prepare these rollback actions:

Stop expansion if an agreed critical operation fails. Restore only the affected pilot configuration or approve a temporary destination exception after assessing its full scope. Reconnect freshly, verify the resulting authentication and business operation, and record any return to NTLM. A successful rollback restores service; it does not constitute migration success.

Make exceptions explicit and temporary

Block NTLM Server Exception List accepts remote-machine IP addresses, NetBIOS names, and FQDNs. Its scope is the destination machine, not an individual share or application. Exception configuration

Consequently, an exception permits NTLM to that destination across shares and applications, services, or tasks from the affected clients, subject to other controls. The detailed inventory explains why the exception exists; it does not narrow what the policy permits. Limit the client group receiving the exception and assess every known use of that destination.

Keep governance metadata in a separate register: destination identifiers, affected client group, dependent processes, technical and business owners, approval, observed use, compensating controls, remediation plan, and expiration date. Assign a named policy administrator to remove the entry or implement an explicitly approved renewal by that date. Assign an escalation owner for overdue decisions. A date in the register does not remove a policy entry automatically.

Investigate failed paths before approving exceptions. Compare the configured UNC and identity with a controlled test using the intended server name; involve AD and file-service owners in any naming, SPN, or identity changes. Retest the final application configuration. Do not assume that changing a name or obtaining a ticket completes the migration.

Retire exceptions through fresh authentication

Schedule removal with the owners of all known dependencies on the destination. Then:

1. Remove the destination’s applicable exception entries from the authoritative configuration.
2. Apply policy to the affected clients and verify that blocking is effective and the entries are absent.
3. End existing connections using the cleanup procedure above.
4. Launch each affected application, service, or task in its actual context and establish a fresh connection.
5. Capture correlated Kerberos authentication evidence and complete the real business operation.
6. Monitor those processes throughout their normal operating cycle, including infrequent jobs. Close the exception only after the agreed acceptance criteria pass.

If removal fails, use the recorded rollback procedure. Any restored exception needs a new review date and an accountable owner. Retain the failed test and the reason for renewal.

Report active exceptions, upcoming and overdue expirations, collection gaps, and verified retirements from your own register. For optional guidance on presenting business impact, see Reporting and risk. For related identity-management background, see LAPS, gMSAs, and tiered administration.

FAQ

Does a cached cifs/ ticket prove the application used Kerberos? No. Require evidence tied to its fresh SMB session and successful execution in its real logon context.

Does a clean pilot establish that NTLM is gone everywhere? No. Limit the conclusion to the observed clients, destinations, processes, and operating cycles. Track older clients, other protocols, and collection gaps separately.

Can a legacy destination keep an exception? Only as an explicit operational risk decision in this procedure, with a responsible owner, constrained client scope, a remediation or replacement plan, and a scheduled removal or renewal action.