+972 52-548-6969
More auth issues: 0xc000006d on Windows 2008 R2
Next on the schedule of problems we had an issue with again, with everything working fine remotely and not working when running locally. This time, it didn’t take as long to figure out what was going on, the root of the problem was “Account failed to log on (0xc000006d)”, and the explanation for that is here:
The basic idea is that you can’t authenticate against the local server using anything except the local server name.
And it still didn’t work.
The server is Windows 2008 R2, and the documentation said that I had to set a registry key at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
That did not work, but what did work was setting the DisableLoopbackCheck at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
No idea why, and if there is a problem at the documentation for Windows 2008 R2, but this is how I got it working on my end. I would probably like it more if I was able to use the recommended solution, and not the solution explicitly not recommended.
Any ideas?
Comments
Can you post/send the reg entries you used for the preferred solution?
Did you try to restart the computer? As the KB article states to restart the server, not IIS.
http://support.microsoft.com/kb/926642
// Ryan
I know it's not a popular answer, but why are you using windows Auth? I've never had any love from it.
The guys on the last post had it right when they were talking about setting up an SPN, but that only holds true if you're going from one web server to another (Which it sounds like you are not).
Configuring windows servers to pass windows authentication tokens from one to another is all I've been doing for the past couple of months so if you want a more detailed discussion/help feel free to drop me an e-mail.
(Actually, you might need to use an SPN if you're connecting via anything other than the existing name of the machine, as otherwise it will drop back to NTLM)
Ryan, Yes, I restarted the machine.
Who cares about the recommended solution. This security feature didn't exist for a while and all of a sudden got pushed through Windows Update and broke a bunch of (SP) websites I maintained at the time. This feature is specifically one of the reasons server admins are wary to apply recommended MS patches.
Anyway. Theoretically, malicious hackers can subvert security by launching an elevated-permissions website from a non-elevated-permissions request from your own machine, but who cares. Just don't run any other websites other than the app you intend.
Still a little angry about the first time I encountered this bug, angry just remembering it. So dumb.
Comment preview