Windows Integrated Authentication fails ONLY if web svcs client is on same machine as IIS server

I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.

I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.

I'm testing the web service using a powershell 开发者_如何转开发script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com

However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.

In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.

So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.

I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.

When I look at the IIS logs, I see the 401 unauthorized line but very little other information.

I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.

I found the answer after several hours:

By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.

More details here:

http://support.microsoft.com/kb/896861

The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.

Thanks to those who gave assistance.

Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.

For example, on your box your credentials are running as...

MYDOMAIN\MYNAME

and the server will be something like...

SYSTEM\SYSTEM_ACCOUNT

and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.

If this is the case, you can fix the problem in one of two ways.

1. Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).

2. Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.