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 using a SOAP UI to send some XML request to a web service hosted in IIS. it has integrated windows auth enabled and basic auth enabled. when i have both integrated and basic enabled, it works sometimes and it fails other times with 401 response code , i can see the http headers traffic sending authorization key when it fails as well. but when i have basic auth only enabled it works all the time. any ideas guys?

this is how my IIS logs looks when it fails instead of going 401, 401 ,200 it goes 401,

401, 401

 2011-07-15 00:16:41 W3SVC1 POST /test/Service.asmx - 80 - Jakarta+Commons-HttpClient/3.1 - 401 2 2148074254 0
 2011-07-15 00:16:41 W3SVC1 POST /test/Service.asmx - 80 - Jakarta+Commons-HttpClient/3.1 $Version=0; 401 1 0 0
 2011-07-15 00:16:41 W3SVC1 POST /test/Service.asmx - 80 - Jakarta+Commons-HttpClient/3.1 $Version=0; 401 1 2148074248 0

Also My webserver is part of webfarm. and my app pool for the web service runs under network_service

share|improve this question
up vote 1 down vote accepted

When you see 401.2, 401.1, (supposed to be 200) that's a client doing an NTLM dance with the server.

If you only ever see 401, 200 for working clients, they're either using Basic or Kerberos.

It's possible that working clients doing Integrated are working because Kerb is working for them, and that the reverse is also true, or that they're already in a multi-hop scenario without using kerberos.

There's one thing I will call out, which is that running an App Pool in a farm under Network Service will break Kerb authentication. The log pattern above doesn't tell me that's what's happening - the client's pretty clearly doing NTLM and failing - but I thought I'd mention it for completeness.

Soo... all that comes back to: troubleshoot it from the client.

share|improve this answer
its the same client that works sometime and don't the other time – Natasha Thapa Jul 15 '11 at 14:30
So you need to troubleshoot why the client is doing that, from the client. Get a network capture on the client, wait for a problem, then look at why Kerberos fails (assuming Kerberos is desired). Or, find DelegConfig and use that to validate your setup is as it should be. As a word of caution, inconsistent results with "no changes" can indicate a DC or DNS problem. – TristanK Jul 16 '11 at 11:49
And if NTLM's abjectly failing and shouldn't, that's a different troubleshooting path again- look at the security log, and if it's not already on, audit logon failures, and look at the reason for the failed logon. – TristanK Jul 16 '11 at 11:51
on audit faulier i am seeing that the Domain name is set to the local computer name instead of Domain name. when its sent from client side its always set to domain name. so the audit error says the bad username or password. do you know how a domain name could be missing somehow or dropped. this web box sits behind the loadbalancer and the web app is a virtual directory under default site. – Natasha Thapa Jul 18 '11 at 1:06
Sorry, I don't understand what you mean - when the client sends the domain name it works? How is the client programmed to send those credentials? What might cause the client to send the wrong credential? Is it always NTLM or Kerberos when it works? (i.e. does this correlate with failure/success?) – TristanK Jul 18 '11 at 12:00

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.