Unable to get windows authentication to work through local IIS

Question

So I've created a new ASP.NET MVC project using the intranet template. web.config contains the appropriate values (e.g. <authentication mode="windows"/>).

If I fire up the web app using the VS webserver, it all looks fine - the page shows my Windows domain and username and all. However, this works in Opera and Safari as well as IE and FF, which says to me it's not using Windows auth at all (since to the best of my knowledge this doesn't work in any browser except IE/FF).

Next step is to get it working through local IIS. I create a hosts file entry pointing www.mysite.mydomain to 127.0.0.1. So in IIS I create website with a binding to www.mysite.mydomain and enable Windows authentication and disable anonymous authentication.

I have set up IE and FF to enable Windows auth as follows:

IE

1. Add URL to intranet group
2. Ensure Windows auth is enabled in the advanced settings

FF

Put 'www.mysite.mydomain' into network.automatic-ntlm-auth.trusted-uris config setting.

But when I dial up www.mysite.mydomain in IE / FF I get a login prompt. Interestingly, even when I type in my Windows login here, it still fails and shows me the login prompt again.

We don't have active directory here but my understanding is that it should work fine with a local account.

I can't think of anything else I need to do. Any suggestions?

Edit: we've recently switched to using Active Directory and the problem remains.

Edit: when I cancel the login prompt, I get taken to an 'IIS 7.5 Detailed Error' page with the following information:

HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers.**

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.

Solution 3

Did you try putting the domain in front of the user name?

DOMAIN\username

If you don't have a domain account, try prefixing your username with the machine name:

MYCOMPUTER\myusername

Solution 4

You should check to see if you have Windows Authentication installed/enabled. That may sound weird but in IIS 7 you have to install and enable the various authentication methods. Check out http://support.microsoft.com/kb/942043/ for more info, see quoted section below.

Cause 1
The Web application is configured to use Integrated Windows authentication. However, the Windows Authentication feature is not turned on. Or, the Integrated Windows authentication native module section of the ApplicationHost.config file or of the Web.config file is not valid. To resolve this problem, see Resolution 1.

Original
Usually when you try to view an asp.net web page hosted on IIS and receive a login prompt it doesn't mean your credentials weren't received or that you aren't authenticated. What it means is that the account that your website is running under doesn't have the right permissions to work with the files.

In IIS 6 and 7 you can easily change the user account that your app pool runs under. Try changing the app pool identity to an account with more access specifically designed for this. Or if you want to stick with the existing account (IUSR_? Network Service?) you can grant that account more permissions on the directory where your website is stored.

This article is specifically targeted at BizTalk but has almost no references to it and focuses on troubleshooting permissions issues with IIS and app pools: http://msdn.microsoft.com/en-us/library/aa954062.aspx

Solution 5

Why local IIS? Can you use local IIS Express?

If so, try this. It seems that IIS Express by default has Windows Authentication set to false.

Change

<windowsAuthentication enabled="false">

to "true" in applicationhost.config file (under 'C:\Users[Profile]\Documents\IISExpress\config' folder). This works for me.

View more solutions

Comments

[David]

Thanks for the suggestion. It's not folder permissions. I can tell the app pool to use my admin account and the problem remains. Also, I get a particular message regarding authentication headers from IIS (added to the question above).

[Peter]

@David - Updated my answer with some new info.

[David]

This is a very interesting suggestion. Unfortunately I no longer work where I had this problem, so I can't verify this answer.

[David]

It would also explain why the problem disappeared when I deployed to a different machine.

[Jozef Krchňavý]

I can verify this answer. I've spent hours googling and finally this regedit answer helped. Thank you!

[myhrmans]

I've verified this using Win8 and IIS8 - The main issue was defining a custom host name and then using it in the host header of my site. also, I did not set the DisableStrictNameChecking to 1, and steps 2 - 8 worked.

[Jeremy Cook]

Verified steps 2-8 on Win7. Performing step 1, set DisableStrictNameChecking to 1, was not needed.

[Kevin Stricker]

Yes, it really should be Step 1 OR Steps 2-8 I would think (judging from the actual step anyway).

[Xin]

This method fixed my issue, on both test and live environment. Cool

[David van Dugteren]

This solution fixed my issue on local IIS on Windows 8.1

[Max Kiselev]

The problem is actually not with IIS but with Windows authentication itself. Please note that the solution disables SMB Reflection attack protection for the host names specified in BackConnectionHostNames. A good explanation of the attack can be found here.

[Squazz]

It is indeed very possible to have both anonymous and Windows authentication at the same time. I do the following in web.config: <system.web> <compilation targetFramework="4.5" /> <httpRuntime targetFramework="4.5" /> <authorization> <deny users="?" /> </authorization> <customErrors mode="Off"></customErrors> <authentication mode="Windows" /> </system.web> <location path="RemoteData"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> </location>

[Kurkula]

authentication mode="Forms" ? when you are trying to achieve windows authentication? Will that be authentication mode="Windows"?

[MDB]

BackConnectionHostNames is indeed the only thing necessary in Windows 7. Thank you for the answer!

[Krishnaraj Barvathaya]

Even for me steps from 2-8 worked, step 1 was not required. Tried on Windows 10.

[bendodge]

Steps 2-8 were still necessary for me to authenticate to a FQDN on localhost with IIS 10 on Server 2016.

[Roland]

You made me fix my problem, see my answer. +1

[Morgs]

Step 2-8 helped me solve this monstrous problem! I've been struggling with this for over 1 week, even missed my deadline!

[RichieMN]

So, it's down voted without any context or explanation? Perhaps it's not a great answer, and I can certainly fix it, if I understood WHY it was down voted. But yeah, I'm sure you feel pretty powerful now.