Skip to content


Account failed to log on (0xc000006d) – Unable to load website from local server

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×0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: tsd
Account Domain: MyDomain

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0×0

Process Information:
Caller Process ID: 0×0
Caller Process Name: -

Network Information:
Workstation Name: codejourney
Source Network Address: 10.1.1.185
Source Port: 57256

Detailed 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.

DeliciousDiggTwitterFacebookLinkedInTechNetStumbleUponNewsVineTechnorati FavoritesSlashdotMSDNShare

Related posts:

  1. The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID…
  2. The IIS Admin Service or the World Wide Web Publishing Service, or a service dependent on them failed to start – 0xc00e03f1

Posted in IIS, Windows Errors.


7 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Scott Morrison says

    Saved my bacon, dude. Was troubleshooting issues with NLB, Kerberos, and AAM. Not aware of the local vs remote browsing issue.

  2. muthuvel says

    It Works…
    Thanks for your valuable suggestion….

  3. Lucian N says

    Thank you!

Continuing the Discussion

  1. How to change Central Administration website URL - even after messing up AAM | Code-Journey.com linked to this post on September 26, 2009

    [...] this post on how to do [...]

  2. Change from SharePoint Server name to Fully Qualified Domain Name (FQDN) | Code-Journey.com linked to this post on September 26, 2009

    [...] 3: Edit Local Loopback Settings You have probably noticed by now that you are prompted for a login no matter what you type in as credentials now. That’s by design as you now log in to a local IIS site that has another adress than the servername. To fix it read this post [...]

  3. Terminal Server access « RaSor’s Blog linked to this post on November 24, 2010

    [...] http://code-journey.com/2009/09/17/account-failed-to-log-on-0xc000006d-unable-to-load-website-from-l… Leave a Comment LikeBe the first to like this post.Leave a Comment » [...]



Some HTML is OK

or, reply to this post via trackback.



Page optimized by WP Minify WordPress Plugin