Issue with Windows Authentication Type on IIS with Multiple Host Bindings

Question

I'm facing an issue with Windows Authentication when deploying my Single Sign-On (SSO) application using Duende SSO on IIS. The application is secured using an SSL certificate with the following subject alternative names:

• mymachine
• mymachine.home

In IIS, I have configured the following bindings for my SSO:

• https://mymachine.home:5007
• https://mymachine:5007

Problem: When I send an authentication request to https://mymachine.home:5007, the method GetWindowsPrincipal() returns an authenticationType of "" (empty string), which causes the authentication to fail.

However, when I send the request to https://mymachine:5007, the method returns authenticationType = "Negotiate", and the authentication process works as expected using NTLM.

Here’s the code for the GetWindowsPrincipal() method:

Copy code
private WindowsPrincipal? GetWindowsPrincipal()
{
    NativeMethods.HttpGetAuthenticationInformation(_requestNativeHandle, out var authenticationType, out var token);

    if (token != IntPtr.Zero && authenticationType != null)
    {
        if ((authenticationType.Equals(NtlmString, StringComparison.OrdinalIgnoreCase)
            || authenticationType.Equals(NegotiateString, StringComparison.OrdinalIgnoreCase)
            || authenticationType.Equals(BasicString, StringComparison.OrdinalIgnoreCase)))
        {
            return new WindowsPrincipal(new WindowsIdentity(token, authenticationType));
        }
    }
    return null;
}

Question: Why does the authenticationType return an empty string when using the https://mymachine.home:5007 binding, and how can I resolve this issue to ensure that the authentication works for both bindings?

I've ensured that the SSL certificate is correctly configured and includes both mymachine and mymachine.home as subject alternative names. Is there a specific IIS setting or additional configuration required to handle this scenario?

Answer 1

I found the solution to the issue I was facing with NTLM authentication in my Duende IdentityServer SSO when deployed on IIS.

Problem Recap:

I was experiencing a problem where the GetWindowsPrincipal() method returned an empty authenticationType when accessing the SSO application via the FQDN (https://mymachine.home:5007). However, it worked fine when accessed via the simple hostname (https://mymachine:5007), returning authenticationType = "Negotiate" and successfully authenticating using NTLM.

Solution:

After some research, I discovered that the issue was related to a Windows security feature called the loopback check, which is designed to prevent reflection attacks on NTLM credentials when accessing a server locally using its FQDN or CNAME alias.

The loopback check was blocking NTLM authentication requests when I accessed the server using the FQDN, which is why the authenticationType was empty.

To resolve this, I applied the following solution:

Steps to Fix:

Modify the Windows Registry:

To allow NTLM authentication for the FQDN (mymachine.home), I added the FQDN to the BackConnectionHostNames list in the Windows Registry.

Here’s how I did it:

Opened the Registry Editor by typing regedit in the Run dialog (Win + R). Navigated to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Right-clicked on MSV1_0, selected New > Multi-String Value, and named it BackConnectionHostNames. Double-clicked BackConnectionHostNames and added the following entries:

• mymachine.home
• mymachine

Clicked OK and closed the Registry Editor. Restart the Server:

After making the registry changes, I restarted the server to apply the new settings.

Explanation:

The loopback check was preventing NTLM authentication when the server was accessed using the FQDN (mymachine.home) because it treats such requests as potential security risks. By adding the FQDN to the BackConnectionHostNames, I was able to bypass this restriction, allowing NTLM authentication to proceed as expected.

Now, the GetWindowsPrincipal() method correctly identifies the authenticationType as "Negotiate" for both mymachine.home and mymachine, resolving the authentication issue.

Conclusion:

If anyone else encounters a similar issue where NTLM authentication fails when using an FQDN, this solution should help resolve it. Adding the FQDN to the BackConnectionHostNames registry entry ensures that the loopback check does not block legitimate NTLM authentication requests.