Windows authentication failing in IIS 7.5

Question

I'm building a simple internal application for my company, and it requires Windows Authentication for security. All other authentication modes are disabled. I'm stuck in a situation where internet explorer prompts for credentials 3 times, then fails with this error:

Not Authorized

HTTP Error 401. The requested resource requires user authentication.

I then created a bare-bones website to test this out. I created a new site in IIS, put it on its own port (:8111, chosen at random), put one static "default.htm" file in there, disabled anonymous authentication, then enabled windows authentication. Everything else was left at default settings. The port number was assigned because we have multiple sites on this machine all sharing the same IP.

Here are a few scenarios:

• Browsing from the web server itself, to http://localhost:8111/ works fine

• Browsing from another computer, to http://ServerIPaddress:8111/ works fine

• Browsing from another computer, to http://ServerName:8111/ FAILS (asks for credentials 3 times, then gives 401 error)

I've been searching online and trying to find a solution with no luck thus far. Either I haven't found it, or I don't understand well enough what I'm reading. Any help would be greatly appreciated.

Romilda

Answer 1

Just worked out the solution with the help of a coworker after 2 days of fighting with this issue. Here is what he wrote:

There are 2 providers for Windows Authentication (Negotiate and NTLM). When setting the Website Authentication to Windows Authentication, while Windows Authentication is highlighted, click on the Providers link on the right pane or IIS Manager and move NTLM to the top. By default Negotiate is on top which is why you are getting an authentication prompt.

Romilda

+1 That did it for me, while a more in-depth and correct answer would be to look into why Negotiate was failing this does quickly highlight what is wrong. – Uproarious

lost a half a day because of this. Thanks for the fix. – Brigette

This solved for me too. In my case, I was getting 504 Gateway Timeout error. – Outspan

@seph - I have posted a new answer below which references an msdn article that shows the fix for this in order to use Negotiate. – Thereafter

I removed Negotiate and it fixed it but why?? An explanation would be great. – Dogface

This seems to say that Negotiate effectively means use Kerberos and Kerberos is failing. It's quite possible Kerberos is failing but if I don't have it in my providers why would it use it? #7337554 – Dogface

This fixed my issue after a full day of trying things. – Howlet

Curiously I was dealing with an HTTP 400: Headers to large. On a whim I tried this trick and it worked. Just making note of it in case someone else stumbles across this. – Anemic

Answer 2

Error 401.1 when you browse a Web site that uses Integrated Authentication.

Solution

Disable the loopback check

* In Registry Editor, locate and then click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

* Right-click Lsa, point to New, and then click DWORD Value.
* Type DisableLoopbackCheck, and then press ENTER.
* Right-click DisableLoopbackCheck, and then click Modify.
* In the Value data box, type 1, and then click OK.

http://support.microsoft.com/kb/896861

Nebulize

Thank you!!! This worked for me and I am relieved from developer agony and frustration for the past few hours. – Speiss

Thank you for this. I just glanced and saw this registry edit. When the above NTLM fix doesn't work, I recommend this is the definite next step. Just validated a lot of work hours I've spent trying to figure this out! – Ullrich

This would only affect windows authentication when browsing from the same machine the web site is hosted on – Drummond

This is dangerous. Don't globally disable the loopback check... it's there for a reason. – Chicoine

I used to be a sharepoint developer and had to do this on every single dev server build... But I've been in MVC land for a while now and completely forgot, so thanks for this. – Strang

Answer 3

If it still does not work after moving NTML to top in the list of providers try to remove Negotiate completely so there is only NTML left.

That fixed it for me - moving NTML to top did not help on Windows Server 2012 and IIS 8.5. I found the solution in the following stackoverflow issue: IIS 7.5 Windows Authentication Not Working in Chrome

Boehm

Answer 4

I personally recommend NOT disabling the loopbackcheck globally on your server (IE: Do NOT set DisableLoopbackCheck to a value of 1 in your registry). This is a security vulnerability. Please only disable for known hosts.

Here's a Powershell function to get you pointed in the right direction.

function Add-LoopbackFix
{
    param(
        [parameter(Mandatory=$true,position=0)] [string] $siteHostName
    )

    $ErrorActionPreference = "Stop"

    Write-Host "Adding loopback fix for $siteHostName" -NoNewLine

    $str = Get-ItemProperty -Name "BackConnectionHostNames" -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -erroraction silentlycontinue

    if ($str) { 
        if($($str.BackConnectionHostNames) -like "*$siteHostName*")
        {
            Write-Host "`tAlready in place" -f Cyan
        } else{
            $str.BackConnectionHostNames += "`n$siteHostName"
            Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "BackConnectionHostNames" -Value $str.BackConnectionHostNames 
            Write-Host "`tDone" -f Green
        }
    } else {
        New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "BackConnectionHostNames" -Value $siteHostName -PropertyType "MultiString" 
        Write-Host "`tDone" -f Green
    }

    Write-Host "`tnote: we are not disabling the loopback check all together, we are simply adding $siteHostName to an allowed list." -f DarkGray
}

> Add-LoopbackFix "ServerName"

Source

Chicoine

Disabling it on internal dev servers should pose no risk. If it's a production server you will likely be hitting it remotely and can leave loopback alone anyways. – Strang

@Ryios, even in Dev, the recommended way is to do it per-domain and not globally. In production, we have lots of apps (SOA) that call other apps on the same server. – Chicoine

Answer 5

It's been a while since this question was asked, but I know numerous people run into it a lot. A more proper fix for this is described here: Kernel-mode authentication. We implemented this several months back, and it works fine.

Another good explanation here: MORE 2008 AND KERBEROS: AUTHENTICATION DENIED, APP POOL ACCOUNT BEING INGNORED

To apply to a single site:

cd %windir%\system32\inetsrv
set SiteName=TheSiteName
appcmd.exe set config "%SiteName%" -section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:"True" /useAppPoolCredentials:"True" /commit:apphost

Or to apply to all sites:

%windir%\system32\inetsrv\appcmd.exe set config -section:windowsAuthentication /useAppPoolCredentials:"True" /commit:apphost

Thereafter

Well I was hoping for an explanation of why removing Negotiate magically fixed it but it isn't here. I tried unticking Kernel Mode and put Negotiate back in and it did't fix it. Removing Negotiate did fix it... but why? – Dogface

This is definitely the fix I needed. On another note I noticed another weird issue where setting autoStart="true" on the appPool under system.applicationHost->applicationPools was the only thing necessary on another server. – Carmencita