Today I was changing which URLs were used for our company Intranet / Extranet.
What I changed was the “Alternate Access Mappings” and also bindings directly in IIS.
The reason for this was that I was setting up Google Analytics for SharePoint, and I did not want the internal employees to enter the MOSS site by simply using the SharePoint servers machine name (http://codejourney for instance).
After editing the Alternate Access Mappings and also bindings in IIS I noticed I was not able to enter the moss server using the new Fully Qualified Domain Name, FQDN (http://code-journey.com for instance).
Basically it did not work when logging on locally, but it worked when logging on remotely.
I also got the same error multiple times in the EventLog. One for each attempt to log in.
401.1 error. EventID 4625.
Error:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0×0Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: tsd
Account Domain: MyDomainFailure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0×0Process Information:
Caller Process ID: 0×0
Caller Process Name: -Network Information:
Workstation Name: codejourney
Source Network Address: 10.1.1.185
Source Port: 57256Detailed Authentication Information:
Logon Process:
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Turns out this is quite normal and by design, but I figured I would blog about it since I am surely not the only one with this “problem”. It has nothing to do with SharePoint. It’s a safety precaution in IIS.
When you use integrated authentication and you have the website as a local IIS site, then you will only be able to access the website using the machine name (http://codejourney). You will not be able to access it using a FQDN.
This is by design and to quote Microsoft:
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.(http://support.microsoft.com/kb/896861)
Naturally this means it’s in effect in later OS versions too. I had the problem on a Windows Server 2008.
Read about reflection attacks here.
How to disable loopback check for local IIS websites:
There are 2 ways to get past this anoyance.
In my case I could have just ignored it and loaded up SharePoint from another computer, but it would be anoying to not be able to see the sharepoint webpage from the MOSS server.
Both solutions require registry editing, so remember to create a backup first.
Solution 1 (Preferred): Specify which host names that does not cause loopback check.
1: Open up the registry editor by typing regedit under Run.
2: Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3: Right-click MSV1_0 and click New and choose to make it a Multi-String Value.
4: Enter BackConnectionHostNames as name for the entry, and double-click it to modify it.
5: Type the hostnames you need to use (code-journey.com for instance).
6: Restart IISAdmin Service (“Start” -> “Administrative Tools” -> “Services”)
Solution 2 (Not recommended):
1: Open up the registry editor by typing regedit under Run.
2: Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3: Right-click Lsa and click New and choose to make it a DWORD Value.
4: Enter DisableLoopbackCheck as name for the entry, and double-click it to modify it.
5: Set the value to 1 and click OK
You should now be able to log in to SharePoint, or any other IIS website, locally from the server.
Related posts:
Saved my bacon, dude. Was troubleshooting issues with NLB, Kerberos, and AAM. Not aware of the local vs remote browsing issue.
It Works…
Thanks for your valuable suggestion….
Thank you!