Windows Server, IIS/SharePoint, and NULL SID ‘Audit Failure’ Security Errors
I stumbled across this issue, while troubleshooting errors accessing host-named SharePoint sites locally from within a web server (sites with specified host headers different from local server name).
While I had no problems accessing the same site from another computer, I could not login and access any pages locally. I was constantly prompted for user name and password receiving access errors, while my Security event log was getting filled with ‘Audit Failure’ log messages about NULL SID: “An account failed to log on. Security ID: NULL SID”.
After eliminating all possible causes – NLB, SharePoint site configuration, IIS security and settings – it turned out that it wasn’t even IIS- or SharePoint-related issue at all. Starting with Windows Server 2003 SP1 and higher (Windows Server 2008 and R2 editions in that list as well), as a security measure Microsoft introduced a loopback check to prevent man-in-the-middle (MITM) attack, when a malicious application (such as spyware) can try to eavesdrop communication with a remote server by introducing itself locally as a remote host. Please note: loopback check happens only when host headers do not match local computer name.
The symptoms and solutions are described in Microsoft KB article: http://support.microsoft.com/kb/896861
Additionally a few other related issues (accessing network shares, etc) are outlined in two more KB articles: http://support.microsoft.com/kb/887993 and http://support.microsoft.com/kb/926642.
To deal with this issue you have two options: either explicitly specify all host headers in the registry (the most secure, but also the most cumbersome solution), or disable loopback check entirely.
If you decide to opt for completely disabling loopback check (on a development or test server), here is one command line you can achieve it through. Please remember to restart your server after changing the registry!
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /t REG_DWORD /d 1
[...] Post From SharePoint Security – Google Blog Search: Errors accessing host-named SharePoint sites [...]
[...] from: Windows Server, IIS/SharePoint, and NULL SID Audit Failure | artykul8 Share and [...]
It worked out!!
You have tested it and writing form your personal experience or you find some information online?
You can also disable the loopback check with PowerShell with: New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -Value “1″ -PropertyType dword
[...] artykul8 [...]
Thanks, this was really pissing me off today.
Very well written post. It will be supportive to anybody who usess it, as well as yours truly
. Keep doing what you are doing – can’r wait to read more posts.
Many thanks for the tremendous content contained throughout your site, this is a little quiz for your blog site visitors. What person said the following quote? . . . .I have no other view than to promote the public good, and am unambitious of honors not founded in the approbation of my Country.
Been fighting audit failures for three weeks, finally stumbled across this post after I narrowed the issue down to IIS. Thanks sooooo much for the help! Bookmarked, and posting as many links to this as I can manage! Awesome work!
Just want to say, this worked perfectly on our new SP 2010 installation on Windows 2008 R2 x64. THANK YOU!
Thank you so much, it works. I have been trying to resolve this issue for 3 wweeks. Greatly appreciated