IIS 7.0 and Windows Integrated Authentication?

Discussion in 'ASP .Net' started by sqlman, Jul 23, 2009.

  1. sqlman

    sqlman Guest

    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?
     
    sqlman, Jul 23, 2009
    #1
    1. Advertisements

  2. sqlman

    David Wang Guest

    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
    //
     
    David Wang, Jul 28, 2009
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.