IIS 7.0 and Windows Integrated Authentication?

  • Thread starter Thread starter sqlman
  • Start date Start date
S

sqlman

Windows 2008 Server, IIS 7.0
ASP.NET 1.1 web service, app pool in Classic mode

I have an ASP.NET 1.1 web service hosted on IIS 7.0, and it works fine
in Anonymous authentication mode. However, I could not make Windows
Integrated Authentication mode work all the way. I installed the
appropriate role on the server, and configured the web service
application to use Windows Integrated. The authentication works when
I use IE8 to test the web service asmx page (IE prompts me for login
and then shows the page.), but my custom .NET client cannot connect
due to IIS simply not responding at all.

Here is how the communication works in both cases between the client
(C) and the server (S):

When using IE
-------------------
C: GET /ws.asmx HTTP/1.1
Accept: <...>
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; Info
Path.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30;
..NET CLR 3
..0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR
3.5.30729)
Accept-Encoding: gzip, deflate
Host: xxx.xxx.xxx
Connection: Keep-Alive

S: HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Thu, 23 Jul 2009 17:48:24 GMT
Content-Length: 6318
<...>

C: GET /ws.asmx HTTP/1.1
Accept: <...>
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; Info
Path.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30;
..NET CLR 3
..0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR
3.5.30729)
Accept-Encoding: gzip, deflate
Host: xxx.xxx.xxx
Connection: Keep-Alive
Authorization: Negotiate xxxxxxx=
=

S: HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: Negotiate XXXXXXXXXXX...
Date: Thu, 23 Jul 2009 17:48:43 GMT
Content-Length: 341
<...>

C: GET /ws.asmx HTTP/1.1
Accept: <...>
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; Info
Path.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30;
..NET CLR 3
..0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR
3.5.30729)
Accept-Encoding: gzip, deflate
Host: xxx.xxx.xxx
Connection: Keep-Alive
Authorization: Negotiate XXXXXXX.....

S: HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 3842
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
X-AspNet-Version: 1.1.4322
X-Powered-By: ASP.NET
Date: Thu, 23 Jul 2009 17:48:43 GMT
<...>


When using .NET client:
--------------------------------

C: POST /ws.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client
Protocol 1
..1.4322.2407)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://xxx.xxx.xxx/ws/GetInfo"
Content-Length: 396
Expect: 100-continue
Connection: Keep-Alive
Host: xxx.xxx.xxx
<?xml version="1.0" encoding="utf-8"?><soap:Envelope>
<...>
</soap:Envelope>

S: ...no response, so the client simply timeouts...
(but should respond with HTTP/1.1 401 Unauthorized challenge instead)


The only notable difference between the IE and client calls is that IE
uses GET and the client uses POST method. (Also IE calls the web
service page, while the client actually calls Soap Action.)

Any suggestions?
 
It looks like the custom .NET client is the issue.

You POST with 100-continue and just blast the entire entity body over
on the initial request. That is bad. If you send 100-continue header,
the client is supposed to wait on sending the entity body over until
the server responds with either a 100 continue response or alternative
response (i.e. 401 for continue authentication negotiation).

Standard System.Net networking classes negotiate authentication and
work with SOAP just fine, Integrated Authentication and all.

At this point, I conclude the problem is with the custom .NET client.
Standard .Net clients and web browsers have been proven to work just
fine.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
 
Back
Top