Today I would like to share my experience with troubleshooting a overcommitted security admin with less knowledge than it would be required (In fact, I’m talking about me here). Some month ago, I read about NTLM (v2 as well), and I decided to restrict NTLM in my LAB, to check what is working afterwards, and what stops working. To my surprise, everything went smooth, and I could not find an issue. So I forgot about this setting, everything seems to work, and it did.
Lastly I decided to cut off Direct Access, since Microsoft does not invest in its future, and for other reasons, I’m not required to have a permanent connection to the LAB from remote, a VPN would be sufficient. I’m using WorkFolders as well, and secured it with Azure MFA, the same should apply to my VPN connection, the authentication should be not only be covered by Username and Password. With this, the goal was set, and I built up the LAB. Everything went nice, until the first VPN client wanted to connect. The NPS Server gave me the error:
“The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.”
The status for the Event was:
Status: 0x80090302
Sub Status: 0xC0000418
Where the SubStatus error type helped me a lot. After a search, I found the following explanation for this error (source):
The authentication failed because NTLM was blocked.
With this error in my hand, I made a classic gpresult, and found the NTLM restriction setting. For more Information about the NTLM restrictions, see this blog: https://www.rootusers.com/implement-ntlm-blocking-in-windows-server-2016/
May this helps somebody facing the same issue.
I’ve been troubleshooting a similar issue in my homelab and I’m glad I found this post. I also configured “Restrict NTLM: NTLM authentication in this domain” for my homelab which broke connectivity to my non domain joined Synology NAS. Configuring the exceptions ended up fixing the issue. Thanks for posting this 🙂
Thanks, this just helped me resolve an authentication issue we were experiencing on our domain. One of the domain controllers had the Restrict NTLM setting enabled which was causing auth failures for certain clients when they would hit that particular DC. The event ID 4625 itself wasn’t super helpful but the sub status code solved the mystery.