NTLM authentication blocked by policy: reading the NTLM operational log

Fix it now

The credential is not the problem: one of the Restrict NTLM settings was configured to deny, and it denied. Your two honest options are to exempt the specific server deliberately, or to give the service a Kerberos identity so the exemption is not needed.

gpresult /h C:\ntlm-report.html
setspn -L CONTOSO\svc_app
setspn -S HTTP/app.contoso.com CONTOSO\svc_app
gpupdate /force

1. Open the NTLM operational log on the machine that refused: Applications and Services Logs, Microsoft, Windows, NTLM. That is where the Restrict NTLM policies write.
2. Open the report from gpresult and read every setting under Security Options that begins “Network security: Restrict NTLM”. One of them is set to deny, and which one tells you whether the block is on the client, the server or the domain controller.
3. To restore service now, add the target server to the matching exception list rather than turning the policy off. One server name per line.
4. For the durable fix, register the missing service principal name on the account the service runs as, so clients negotiate Kerberos instead.

Before changing anything in production, set the auditing versions of these policies. They record what would be blocked without blocking it, which is how you size the problem before you create it.

If the application works again you can stop here. The next section covers what the policies do, and which events are actually published for them.

Why it happens

The Restrict NTLM family of security options exists to remove NTLM from a domain in stages. There are settings for outgoing traffic from a client, incoming traffic to a server, and NTLM authentication in the domain as a whole, each with an auditing counterpart that logs without blocking. When one of them denies, the authentication fails with the credential completely valid: it is the protocol carrying it that was refused.

The events land in an operational log rather than the Security log. Microsoft’s documentation for these policies states that the events are recorded in Applications and Services Log, Microsoft, Windows, NTLM – and, notably, that there are no security audit event policies to configure for viewing that output. That is the log to open, and it is worth knowing that Microsoft does not publish an event ID table for it.

What Microsoft does publish, on the domain controller side, is Event ID 8004 for NTLM authentication auditing, which is the event that records NTLM authentication activity once the three Restrict NTLM audit settings are enabled. If you are building a picture of who still uses NTLM before you turn blocking on, 8004 on the domain controllers is the documented source.

Full reference

The settings, and where each one applies

What is published, and what is not

Microsoft documents the operational log path for these policies but does not publish an event ID table for it, so treat any event number you are given for “NTLM blocked” – including 4001 – as unverified until you see it in your own log. What is documented is Event ID 8004 on domain controllers for NTLM authentication auditing, and Event ID 101 in the Authentication Policy Failures log for an NTLM sign-in refused because an authentication policy is configured. Build reporting on those two, and use the operational log for the detail of a single failure in front of you.

Sizing the problem before you cause one

1. Set the three audit policies on the domain controllers: outgoing NTLM traffic to Audit all, NTLM authentication in this domain to Enable all, and incoming NTLM traffic to Enable auditing for all accounts.
2. Collect Event 8004 for a fortnight, so weekly and monthly jobs are included.
3. Group by server name and by account. Each server name is a candidate for an SPN rather than an exception.
4. Register the missing service principal names, then re-collect and see what is left.
5. Only then move the enforcement settings from audit to block, and expect the remaining list to be the exception list.

Statuses you will see alongside this

Why the exception list is not a resting place

An exception is a named server that is allowed to keep using NTLM. It is a reasonable step while an application is being fixed, and a poor one as an end state: nothing expires it, nothing reviews it, and the servers on it are the ones an attacker would relay credentials to first. Give every entry an owner and a date at the point you add it, in the same change record, because there is no built-in list to review later.

Every code this article covers

Confirm the fix worked

1. The application authenticates without a credential prompt, from a machine that was failing.
2. setspn -L <account> lists the name clients actually use, and setspn -X -F reports no duplicate for it.
3. A network capture or the client’s ticket cache shows Kerberos rather than NTLM for that server.
4. Event 8004 on the domain controllers no longer records NTLM for that server name.
5. Every entry in an exception list has an owner and a date recorded with the change.

Questions people ask about this