locked
Safari unable to Authenticate to IIS RRS feed

  • Question

  • User655457284 posted

    Hi, I have an ASP.NET application on PC with IIS 7.5. The firewall is turned off.

    I have mac's on the network and with Firefox and Safari. Both can browse the site and see the public pages. Both can authenticate and see the private pages. Firefox has no problems, however IIS sometimes stops responding to posts from safari. Clear cache/cookies stop/start IIS, then it works again for a while. When the problem accurs, if I continue trying safair, IIS can stop responding to any request for about 2 minutes. 

    Using wireshark I can see that when there is a problem IIS does not respond to the POST from safari.  The log below shows a post from safari that IIs did not respond to,

    Thanks in advance, Michael

     

    More details

    I'm using .ASPXAUTH cookie (For testing purposes it's set to expire after 10 minutes of inactivity)

    Safari - Warn when visiting fradulent website = FALSE

    Safari - Accept Cookies = Always

    Firefox successful authentication IIS Log

    #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
    2010-05-14 14:58:49 192.168.10.37 POST /Account/LogOn ReturnUrl=%2fHome%2fReports 80 - 192.168.10.98 Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10.5;+en-US;

    +rv:1.9.2.3)+Gecko/20100401+Firefox/3.6.3 302 0 0 297
    2010-05-14 14:58:49 192.168.10.37 GET /Home/Reports - 80 martinweir123@gmail.com 192.168.10.98 Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10.5;+en-US;

    +rv:1.9.2.3)+Gecko/20100401+Firefox/3.6.3 302 0 0 20
    2010-05-14 14:58:49 192.168.10.37 GET /WebForms/ReportsHome.aspx - 80 martinweir123@gmail.com 192.168.10.98 Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10.5;+en-US;

    +rv:1.9.2.3)+Gecko/20100401+Firefox/3.6.3 200 0 0 35

     

    Safari unsuccessful authentication log

    #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
    2010-05-14 15:02:29 192.168.10.37 POST /Account/LogOn ReturnUrl=%2fHome%2fReports 80 - 192.168.10.98 Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10_5_8;+en-us)+AppleWebKit/531.22.7+(KHTML,

    +like+Gecko)+Version/4.0.5+Safari/531.22.7 200 0 64 133598

     

    Friday, May 14, 2010 1:21 PM

Answers

  • User690216013 posted
    You must experience some problem when interpret the Wireshark log, as the one you paste is a simple TCP ACK which does not contain any hint on the full conversation. There can be a problem, but only the full capture can tell. If possible, you can involve Apple support team, or Microsoft support team to further assist you on troubleshooting. Regards,
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, May 17, 2010 7:50 PM

All replies

  • User690216013 posted
    Your analysis of the scenario is not comprehensive, so I cannot tell more from what you pasted. If Firefox always works and Safari fails often. Please consult Apple on Safari issues. IIS cannot control how Safari works.
    Friday, May 14, 2010 8:37 PM
  • User655457284 posted
    Hi Lex,

    Thanks for responding.  What I noticed from Wireshark was that in the case of a 'Successful Log In'  IIs responds to the form POST with a 302 redirect and includes the ASP.NET membership cookie.

    But in the case of an 'Unsuccessful Log In' IIs responds to the form POST with the message below only, no redirect and no Cookie, and Safari is left waiting for a response until IIs times out. The IIs log shows that the POST was received from Safari.

    Would this suggest the problem is with IIs? The only thing in this message is an acknowledgment of the POST from Safari.

    Why didn't IIs send a 302 redirect in this case ? Let me know if there is any other information that would be helpful,

    Thanks again,

    Michael

     

    IIs server response to Log In Form POST from Safari............

    Frame 8 (66 bytes on wire, 66 bytes captured)
        Arrival Time: may 17, 2010 13:20:43.661652000
        [Time delta from previous captured frame: 0.000015000 seconds]
        [Time delta from previous displayed frame: 0.000015000 seconds]
        [Time since reference or first frame: 21.366885000 seconds]
        Frame Number: 8
        Frame Length: 66 bytes
        Capture Length: 66 bytes
        [Frame is marked: False]
        [Protocols in frame: eth:ip:tcp]
        [coloring Rule Name: checksum Errors]
        [coloring Rule string: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || mstp.checksum_bad==1]
    Ethernet 11, src: intelcor_37:31:9c (00:1c:c0:37:31:9c), Dst: Apple_31:cc:68 (00:1f:5b:31:cc:68)
        Destination: Apple_31:cc:68 (00:1f:5b:31:cc:68)
            Address: Apple_31:cc:68 (00:1f:5b:31:cc:68)
            .... ...0 .... .... .... .... = 1G bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Source: intelcor_37:31:9c (00:1c:c0:37:31:9c)
            Address: intelcor_37:31:9c (00:1c:c0:37:31:9c)
            .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
            .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        Type: IP (0x0800)
    Internet Protocol, Src: 192.168.10.37 (192.168.10.37), Dst: 192.168.10.98 (192.168.10.98)
        Version: 4
        Header length: 20 bytes
        Differentiated services Field: 0x00 (OSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated services codepoint: Default (0x00)
            .... ..0. = ECN-capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 52
        Identification: 0x4105 (16645)
        Flags: 0x02 (Don't Fragment)
            0.. = Reserved bit: Not Set
            .1. = Don't fragment: set
            ..0 = more fragments: Not set
        Fragment offset: 0
        Time to live: 128
        Protocol: TCP (0x06)
        Header checksum: 0x0000 [incorrect, should be 0x23e7]
            [Good: False]
            [Bad : True]
                [Expert Info (Error/checksum): Bad checksum]
                [Message: Bad checksum]
                [Severity level: Error]
                [Group: checksum]
        Source: 192.168.10.37 (192.168.10.37)
        Destination: 192.168.10.98 (192.168.10.98)
    Transmission control Protocol, Src Port: http (80), Dst Port: 54782 (54782), Seq: 1, Ack: 672, Len: 0
        Source port: http (80)
        Destination port: 54782 (54782)
        [stream index: 1]
        Sequence number: 1    (relative sequence number)
        Acknowledgement number: 672    (relative ack number)
        Header length: 32 bytes
        Flags: 0x10 (ACK)
            0... .... = Congestion window Reduced (cwR): Not set
            .0.. .... = ECN-Echo: Not set
            ..0. .... = Urgent: Not set
            ...1 .... = Acknowledgement: Set
            .... 0... = Push: Not set
            .... .0.. = Reset: Not set
            .... ..0. = Syn: Not set
            .... ...0 = Fin: Not set
        Window size: 66304 (scaled)
        Checksum: 0x95fe [validation disabled]
            [Good checksum: False]
            [Bad checksum: False]
        Options: (12 bytes)
            NOP
            NOP
            Timestamps: TSval 28008925, TSecr 460675049
        [SEQ/ACK analysis]
            [This is an ACK to the segment in frame: 7]
            [The RTT to ACK the Segment was: 0.000015000 seconds] 

    Monday, May 17, 2010 5:26 PM
  • User690216013 posted
    You must experience some problem when interpret the Wireshark log, as the one you paste is a simple TCP ACK which does not contain any hint on the full conversation. There can be a problem, but only the full capture can tell. If possible, you can involve Apple support team, or Microsoft support team to further assist you on troubleshooting. Regards,
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, May 17, 2010 7:50 PM