Unable to get windows authentication to work through local IIS

Solution 1:

You have to whitelist a domain specified in the hosts file in order for windows authentication to work:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
3. Right-click Parameters, click New, and then click DWORD (32-bit) Value.
4. Type DisableStrictNameChecking and press ENTER.
5. Double-click the DisableStrictNameChecking registry value and type 1 in the Value data box, click OK
6. In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
7. Right-click MSV1_0, point to New, and then click Multi-String Value.
8. Type BackConnectionHostNames, and then press ENTER.
9. Right-click BackConnectionHostNames, and then click Modify.
10. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
11. Quit Registry Editor, and then restart the IISAdmin service.

NOTE: The original Microsoft KB links on this answer were broken and have been removed. This article provided the instructions for setting DisableStrictNameChecking.

Solution 2:

I recently spent three days trying to solve the same problem and it drove me crazy. It was happening on a load-balanced setup where one of the servers was authenticating correctly while the other failed. Investigating the problem - and eventually solving it - it turned out to be unrelated to the load-balanced environment, it could happen with any server when authenticating using Windows Authentication and the server is called with a name other than the one recognized by Active Directory

1. Enable Kerberos logging

To correctly diagnose your issue, you will need to enable Kerberos logging on the machine hosting your IIS site. To do so, add the following registry entry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Add Registry Value LogLevel with ValueType REG_DWORD and value 0x1.

Once you turn on logging, then you try to authenticate, you will get errors logged in your Windows Application Log. You can ignore the error KDC_ERR_PREAUTH_REQUIRED (this is just part of the handshake) but if you get the error KDC_ERR_C_PRINCIPAL_UNKNOWN that means your AD controller doesn't recognize your server therefore you need to follow the steps below.

2. KDC_ERR_C_PRINCIPAL_UNKNOWN

if you're getting KDC_ERR_C_PRINCIPAL_UNKNOWN, that means the name "mysite.mydomain.com" is different from how the AD recognizes your machine so it's unable to provide a valid kerberos ticket. In that case, you need to register a Service Principal Name (SPN) for " 'www.mysite.mydomain" on the AD.

On your AD controller, run this command - you will need Domain Admin privilege:

Setspn -A HTTP/mysite.mydomain YOUR_MACHINE_HOSTNAME

3. Use a custom identity for your Application pool

Finally, make you Application pool use a custom account that belongs to the Active Directory instead of using NetworkService. This can be done in advanced settings of your application pool.

and .. voila.

Notes: The problem could (unlikely) be related to having multiple SPNs registered to the same machine, in that case you will need to run a command to remove duplicate SPNs, but I doubt this is the case. Also try adding a different binding to your site (that doesn't use a custom name) something like htttp://localhost:custom_port_number and see if authentication works. If it works, this is an extra indication that you're suffering from the same problem I had.