Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am running SharePoint Server 2007 with SP1 on our test server. It's a single-server installation. It has a single SharePoint application running on port 80. It's using Windows authentication. It's using both Windows (with NTLM) and basic authentication for IIS auth settings. There is one site collection running on this application.

Ordinarily, we log in with our Windows domain accounts to interact with the system, but we have a couple local machine user accounts that we created in order to test some things and run little utility scripts. The problem is that now we can't log into this site with those local machine users unless we're running the browser on the server itself. On the server, I can log in with those users. From any other box, I am rejected with a 401.1 error. With domain-based accounts, I can successfully log in from any of these machines. I am certain that this used to work, but because other people have unfettered access to the server, I can't promise that no settings have changed since then.

What could be happening? Is this a SharePoint problem or an IIS problem? And how can I re-enable login access to these local machine users?


I don't see how this is necessarily related to the impersonation settings suggested by TheCleaner. Our production server uses the same type of local machine users, and there is no problem logging into that SharePoint site with those local machine users (same IIS configuration and same web.config as is used in the problematic test server). Also, the articles suggested by TheCleaner are intended for audiences who are trying to access other resources as a specific identity after that identity is already logged into SharePoint. I can't even get logged into SharePoint. Am I just confused?

share|improve this question

I have seen very similar things happen when the ASP .NET impersonation settings are incorrect or have changed. The same scenario of "unless we run it on the server itself" points me to believe this may be the issue. Have you check the impersonation settings?

share|improve this answer
Thanks for the response, but I am not sure exactly what you mean. The web.config for the IIS virtual root has <identity impersonate="true" />. The timestamp on this file is 4 months ago, though, and I am sure it behaved differently at that time. What exactly should I be looking for with respect to the impersonation settings? – Chris Farmer Oct 2 '09 at 22:10
I don't see how those are necessarily relevant. They seem to be trying to address either the double-hop problem or simple elevation of privileges to accomplish an action that the logged-in user would not otherwise be able to perform. In my case, on my test server, I can't even get to the point where those tools would be useful. Am I misunderstanding your suggestion? – Chris Farmer Oct 5 '09 at 16:06
I'm not certain that it does, I'm not a Sharepoint expert. However, we found that the Impersonation Settings "options" in the web.config file for Sharepoint had a lot to do with scenarios when you could login just fine through the server's browser, but not another system. – TheCleaner Oct 5 '09 at 16:19
For instance, we changed "impersonate" to actually use a specific userID and password in the web.config. When we did this, remote access worked, but then it broke things like search and Mysites. We had to change it back to the defaults and recode the webapp we were working on. See here: That explains "In this instance, ASP.NET impersonates the token passed to it by IIS, which is either an authenticated user or the anonymous Internet user account (IUSR_machinename)." A local account might not be an "authenticated user". – TheCleaner Oct 5 '09 at 16:24

It's interesting - what it looks like is that you're not logging in via Basic from remote machines, but rather NTLM that's failing (since the accounts are local only to the server, not to the client). What's the Win32 code for the 401.1 error? What does Fiddler say the authentication is?

Can you log in via NTLM on the servers (Automatic NTLM login is typically disabled due to ESC - Enhanced Server Configuration)?

What exactly where the "scripts" that you ran and what did they do?

Finally, what internet zone does the site appear on the server and the clients that are failing?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.