IIS 6.0 and 401.2 and 401.1 Errors

[h***@nospam.nospam]

I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.

My questions are:
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?

Code Count
===== =======
401 827,314
200 652,067

The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165

The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)

Client tries to get copy of menu.css, gets 304, file on client is OK to use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110

A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30

A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10

A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[WenJun Zhang[msft]]

Hi,

This is expected behavior. The 401.2 and 401.1 response code isn't an
error here. They come from 2 causes:

1) IE always tries anonymous access before than any kind of
authentication attemps.

2) The 2nd 401.1 response is a part of the integrated authentication
handshake.

An entire integrated auth handshake(NTLM) need exchange 3 parts of
hash between the server and client, which cannot be finished in 1
http request/response.

The whole scenario of NTLM is like:

IE --------> IIS (anonymous access attemp)

IE <--------- IIS (401.2 authentication failed due to server
configuration, list all allowed auth type in response header)

IE --------> IIS (NTLM auth, the 1st hash)

IE <--------- IIS (401.1, the 2nd hash)

IE --------> IIS (the 3rd hash)

IE <--------- IIS (200 or 304, authenticated)

That's the reason why we always see the 401.2 - 401.1 - 200 sequences
in IIS log. It's quite normal. :-)

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[David Wang [Msft]]

Additionally, you should realize that NTLM is connection-based
authentication -- client and server first negotiate authentication that
first time as described earlier, and then subsequent requests over that
authenticated connection is considered "authenticated" and directly succeed.

So, if you see repeated 401.2 for the same resource from the same client, it
means that the client and server are NOT keeping their previously
authenticated connection and instead RENEGOTIATING a new connection. It is
this unnecessary renegotiation that is causing extra authentication trips
and draining throughput.

You can easily verify this by installing "Network Monitor" from Windows
Server 2003 Add/Remove Programs, Windows Components and then watch the
traffic between two distinct client/server machines. You will see the
client and server continuously renegotiate and use different ports, which
constitute different connections, and each are getting re-authenticated.

Now, NTLM requires "connection keep-alive" to be enabled to function, and
IIS6 will aggressively maintain connection keep-alive status whenever
possible -- so repeated re-negotiation can suggest:
1. The load balancer is not maintaining clients to talk to the same web
server (to minimize number of connection [hence authentication] attempts)
2. The application is explicitly closing connections (which IIS6 will obey)
3. Browser uses HTTP Pipelining inefficiently -- I have observed this from
IE with IIS6 and any authentication
4. Product bug in IIS6 regarding keep-alive

Network Monitor is pretty much the only direct way you can distinguish
between the above four possibilities. You will need to post a network
capture illustrating the issue.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
""WenJun Zhang[msft]"" <v-***@online.microsoft.com> wrote in message news:***@cpmsftngxa10.phx.gbl...
Hi,

This is expected behavior. The 401.2 and 401.1 response code isn't an
error here. They come from 2 causes:

1) IE always tries anonymous access before than any kind of
authentication attemps.

2) The 2nd 401.1 response is a part of the integrated authentication
handshake.

An entire integrated auth handshake(NTLM) need exchange 3 parts of
hash between the server and client, which cannot be finished in 1
http request/response.

The whole scenario of NTLM is like:

IE --------> IIS (anonymous access attemp)

IE <--------- IIS (401.2 authentication failed due to server
configuration, list all allowed auth type in response header)

IE --------> IIS (NTLM auth, the 1st hash)

IE <--------- IIS (401.1, the 2nd hash)

IE --------> IIS (the 3rd hash)

IE <--------- IIS (200 or 304, authenticated)

That's the reason why we always see the 401.2 - 401.1 - 200 sequences
in IIS log. It's quite normal. :-)

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[h***@nospam.nospam]

I ran some packet traces yesterday. Is there some way I can mail them
directly to you? I am doing my testing in virtual PC, and not using NLB.
The logs look the same so I guess we can rule out #1 below.

Thanks for the good information!!!

Post by David Wang [Msft]
Additionally, you should realize that NTLM is connection-based
authentication -- client and server first negotiate authentication that
first time as described earlier, and then subsequent requests over that
authenticated connection is considered "authenticated" and directly succeed.
So, if you see repeated 401.2 for the same resource from the same client, it
means that the client and server are NOT keeping their previously
authenticated connection and instead RENEGOTIATING a new connection. It is
this unnecessary renegotiation that is causing extra authentication trips
and draining throughput.
You can easily verify this by installing "Network Monitor" from Windows
Server 2003 Add/Remove Programs, Windows Components and then watch the
traffic between two distinct client/server machines. You will see the
client and server continuously renegotiate and use different ports, which
constitute different connections, and each are getting re-authenticated.
Now, NTLM requires "connection keep-alive" to be enabled to function, and
IIS6 will aggressively maintain connection keep-alive status whenever
1. The load balancer is not maintaining clients to talk to the same web
server (to minimize number of connection [hence authentication] attempts)
2. The application is explicitly closing connections (which IIS6 will obey)
3. Browser uses HTTP Pipelining inefficiently -- I have observed this from
IE with IIS6 and any authentication
4. Product bug in IIS6 regarding keep-alive
Network Monitor is pretty much the only direct way you can distinguish
between the above four possibilities. You will need to post a network
capture illustrating the issue.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
Hi,
This is expected behavior. The 401.2 and 401.1 response code isn't an
1) IE always tries anonymous access before than any kind of
authentication attemps.
2) The 2nd 401.1 response is a part of the integrated authentication
handshake.
An entire integrated auth handshake(NTLM) need exchange 3 parts of
hash between the server and client, which cannot be finished in 1
http request/response.
IE --------> IIS (anonymous access attemp)
IE <--------- IIS (401.2 authentication failed due to server
configuration, list all allowed auth type in response header)
IE --------> IIS (NTLM auth, the 1st hash)
IE <--------- IIS (401.1, the 2nd hash)
IE --------> IIS (the 3rd hash)
IE <--------- IIS (200 or 304, authenticated)
That's the reason why we always see the 401.2 - 401.1 - 200 sequences
in IIS log. It's quite normal. :-)
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Get Secure! - www.microsoft.com/security

[WenJun Zhang[msft]]

Hi,

I'd also recommend you review HTTP.sys log in
\WINDOWS\system32\LogFiles\HTTPERR to check if there are many
abnormal connection closed records.

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[WenJun Zhang[msft]]

Hi,
Is there any update on this issue?

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

[David Wang [Msft]]

Make sure that the Netmon capture is done between two machines -- not from
host to itself.

Virtual PC has some interaction with the networking stack -- I recommend
running NetMon on the non-Virtual PC machine involved to capture network
traffic.

The capture should be small enough to send as attachment or HTTP URL link
for download.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<***@nospam.nospam> wrote in message news:E34B03B1-B833-4576-A5CE-***@microsoft.com...
I ran some packet traces yesterday. Is there some way I can mail them
directly to you? I am doing my testing in virtual PC, and not using NLB.
The logs look the same so I guess we can rule out #1 below.

Thanks for the good information!!!

Post by David Wang [Msft]
Additionally, you should realize that NTLM is connection-based
authentication -- client and server first negotiate authentication that
first time as described earlier, and then subsequent requests over that
authenticated connection is considered "authenticated" and directly succeed.
So, if you see repeated 401.2 for the same resource from the same client, it
means that the client and server are NOT keeping their previously
authenticated connection and instead RENEGOTIATING a new connection. It is
this unnecessary renegotiation that is causing extra authentication trips
and draining throughput.
You can easily verify this by installing "Network Monitor" from Windows
Server 2003 Add/Remove Programs, Windows Components and then watch the
traffic between two distinct client/server machines. You will see the
client and server continuously renegotiate and use different ports, which
constitute different connections, and each are getting re-authenticated.
Now, NTLM requires "connection keep-alive" to be enabled to function, and
IIS6 will aggressively maintain connection keep-alive status whenever
1. The load balancer is not maintaining clients to talk to the same web
server (to minimize number of connection [hence authentication] attempts)
2. The application is explicitly closing connections (which IIS6 will obey)
3. Browser uses HTTP Pipelining inefficiently -- I have observed this from
IE with IIS6 and any authentication
4. Product bug in IIS6 regarding keep-alive
Network Monitor is pretty much the only direct way you can distinguish
between the above four possibilities. You will need to post a network
capture illustrating the issue.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
Hi,
This is expected behavior. The 401.2 and 401.1 response code isn't an
1) IE always tries anonymous access before than any kind of
authentication attemps.
2) The 2nd 401.1 response is a part of the integrated authentication
handshake.
An entire integrated auth handshake(NTLM) need exchange 3 parts of
hash between the server and client, which cannot be finished in 1
http request/response.
IE --------> IIS (anonymous access attemp)
IE <--------- IIS (401.2 authentication failed due to server
configuration, list all allowed auth type in response header)
IE --------> IIS (NTLM auth, the 1st hash)
IE <--------- IIS (401.1, the 2nd hash)
IE --------> IIS (the 3rd hash)
IE <--------- IIS (200 or 304, authenticated)
That's the reason why we always see the 401.2 - 401.1 - 200 sequences
in IIS log. It's quite normal. :-)
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Get Secure! - www.microsoft.com/security

[Peoples Bank]

The problem I am having is I have SOME users that get prompted for
credentials when they access our internal Intranet website. It is running on
Windows 2003 SP1, IIS 6, and the clients are all IE6.0. The clients were
imaged from the same ghost image, so software configurations are all
identical. We use roaming profiles. Problems happen on local LAN from client
to webserver and across the WAN. If one user logs on to a PC (or any PC for
that matter) and attempts to browse to the Intranet (which is their
homepage), they get prompted to enter their login credentials. After entering
them, they get the site successfully. Now, if a different user logs on to the
same PC, they can get to the website without being prompted to enter login
credentials. I have noticed that if we delete the user's profile, and log
them in with a fresh/clean profile, they no longer have the problem. But the
problem sometimes re-appears for that user at a later date, but not always. I
have run a trace on both a "good" and "bad" connection attempt. It will be
attached to the next post.

[Peoples Bank]

----------------------------
Packet 1 from a "BAD" client
----------------------------
1 2.725859 LOCAL 000FFEAE56DB TCP Control Bits: .A..S., len: 0,
seq:2152554056-2152554057, ack:1411174386, win:16384, src: 80 dst: 2042
INTRANET1 FiservLab2 IP
FRAME: Base frame properties
FRAME: Time of capture = 3/15/2006 11:39:36 AM
FRAME: Time delta from previous physical frame: 0 microseconds
FRAME: Frame number: 1
FRAME: Total frame length: 62 bytes
FRAME: Capture frame length: 62 bytes
FRAME: Frame data: Number of data bytes remaining = 62 (0x003E)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 000FFEAE56DB
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 0012793C56EC
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 34702; Total IP
Length = 48; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 48 (0x30)
IP: Identification = 34702 (0x878E)
IP: Fragmentation Summary = 0 (0x0)
IP: .0.............. = May fragment datagram if necessary
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 10.10.1.95
IP: Destination Address = 10.10.2.51
TCP: Control Bits: .A..S., len: 0, seq:2152554056-2152554057,
ack:1411174386, win:16384, src: 80 dst: 2042
TCP: Source Port = World Wide Web HTTP
TCP: Destination Port = 0x07FA
TCP: Sequence Number = 2152554056 (0x804D5E48)
TCP: Acknowledgement Number = 1411174386 (0x541CCFF2)
TCP: Data Offset = 28 bytes
TCP: 0111.... = Data Offset (28 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x12 : .A..S.
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = Not the end of the data
TCP: Window = 16384 (0x4000)
TCP: Checksum = 0x207B
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Maximum Segment Size Option
TCP: Option Type = Maximum Segment Size
TCP: Option Length = 4 (0x4)
TCP: Maximum Segment Size = 1460 (0x5B4)
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
TCP: SACK Permitted Option
TCP: Option Type = Sack Permitted
TCP: Option Length = 2 (0x2)
00000: 00 0F FE AE 56 DB 00 12 79 3C 56 EC 08 00 45 00 ..þ®VÛ..y<Vì..E.
00010: 00 30 87 8E 00 00 80 06 00 00 0A 0A 01 5F 0A 0A .0‡Ž..€......_..
00020: 02 33 00 50 07 FA 80 4D 5E 48 54 1C CF F2 70 12 .3.P.ú€M^HT.Ïòp.
00030: 40 00 20 7B 00 00 02 04 05 B4 01 01 04 02 @. {.....´....

----------------------------
Packet 2 from a "BAD" client
----------------------------
2 2.725859 LOCAL 000FFEAE56DB HTTP Response to Client; HTTP/1.1; Status Code
= 401 - Unauthorized INTRANET1 FiservLab2 IP
FRAME: Base frame properties
FRAME: Time of capture = 3/15/2006 11:39:36 AM
FRAME: Time delta from previous physical frame: 0 microseconds
FRAME: Frame number: 2
FRAME: Total frame length: 1514 bytes
FRAME: Capture frame length: 1514 bytes
FRAME: Frame data: Number of data bytes remaining = 1514 (0x05EA)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 000FFEAE56DB
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 0012793C56EC
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 34703; Total IP
Length = 1500; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 1500 (0x5DC)
IP: Identification = 34703 (0x878F)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 10.10.1.95
IP: Destination Address = 10.10.2.51
TCP: Control Bits: .A...., len: 1460, seq:2152554057-2152555517,
ack:1411174601, win:65320, src: 80 dst: 2042
TCP: Source Port = World Wide Web HTTP
TCP: Destination Port = 0x07FA
TCP: Sequence Number = 2152554057 (0x804D5E49)
TCP: Acknowledgement Number = 1411174601 (0x541CD0C9)
TCP: Data Offset = 20 bytes
TCP: 0101.... = Data Offset (20 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 65320 (0xFF28)
TCP: Checksum = ERROR: CheckSum is 0x1D74, Should be 0xFF59
TCP: Urgent Pointer = 0 (0x0)
HTTP: Response to Client; HTTP/1.1; Status Code = 401 - Unauthorized
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Unauthorized
HTTP: Reason =Unauthorized
HTTP: Content-Length =1656
HTTP: Content-Type =text/html
HTTP: Server =Microsoft-IIS/6.0
HTTP: WWW-Authenticate =Negotiate
HTTP: WWW-Authenticate =NTLM
HTTP: MicrosoftOfficeWebServer =5.0_Pub
HTTP: X-Powered-By = ASP.NET
HTTP: Date =Wed, 15 Mar 2006 16:39:36 GMT
HTTP: Data: Number of data bytes remaining = 1209 (0x04B9)
00000: 00 0F FE AE 56 DB 00 12 79 3C 56 EC 08 00 45 00 ..þ®VÛ..y<Vì..E.
00010: 05 DC 87 8F 40 00 80 06 00 00 0A 0A 01 5F 0A 0A .܇@.€......_..
00020: 02 33 00 50 07 FA 80 4D 5E 49 54 1C D0 C9 50 10 .3.P.ú€M^IT.ÐÉP.
00030: FF 28 1D 74 00 00 48 54 54 50 2F 31 2E 31 20 34 ÿ(.t..HTTP/1.1 4
00040: 30 31 20 55 6E 61 75 74 68 6F 72 69 7A 65 64 0D 01 Unauthorized.
00050: 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A .Content-Length:
00060: 20 31 36 35 36 0D 0A 43 6F 6E 74 65 6E 74 2D 54 1656..Content-T
00070: 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D 0A ype: text/html..
00080: 53 65 72 76 65 72 3A 20 4D 69 63 72 6F 73 6F 66 Server: Microsof
00090: 74 2D 49 49 53 2F 36 2E 30 0D 0A 57 57 57 2D 41 t-IIS/6.0..WWW-A
000A0: 75 74 68 65 6E 74 69 63 61 74 65 3A 20 4E 65 67 uthenticate: Neg
000B0: 6F 74 69 61 74 65 0D 0A 57 57 57 2D 41 75 74 68 otiate..WWW-Auth
000C0: 65 6E 74 69 63 61 74 65 3A 20 4E 54 4C 4D 0D 0A enticate: NTLM..
000D0: 4D 69 63 72 6F 73 6F 66 74 4F 66 66 69 63 65 57 MicrosoftOfficeW
000E0: 65 62 53 65 72 76 65 72 3A 20 35 2E 30 5F 50 75 ebServer: 5.0_Pu
000F0: 62 0D 0A 58 2D 50 6F 77 65 72 65 64 2D 42 79 3A b..X-Powered-By:
00100: 20 41 53 50 2E 4E 45 54 0D 0A 44 61 74 65 3A 20 ASP.NET..Date:
00110: 57 65 64 2C 20 31 35 20 4D 61 72 20 32 30 30 36 Wed, 15 Mar 2006
00120: 20 31 36 3A 33 39 3A 33 36 20 47 4D 54 0D 0A 0D 16:39:36 GMT...
00130: 0A 3C 21 44 4F 43 54 59 50 45 20 48 54 4D 4C 20 .<!DOCTYPE HTML
00140: 50 55 42 4C 49 43 20 22 2D 2F 2F 57 33 43 2F 2F PUBLIC "-//W3C//
00150: 44 54 44 20 48 54 4D 4C 20 34 2E 30 31 2F 2F 45 DTD HTML 4.01//E
00160: 4E 22 20 22 68 74 74 70 3A 2F 2F 77 77 77 2E 77 N" "http://www.w
00170: 33 2E 6F 72 67 2F 54 52 2F 68 74 6D 6C 34 2F 73 3.org/TR/html4/s
00180: 74 72 69 63 74 2E 64 74 64 22 3E 0D 0A 3C 48 54 trict.dtd">..<HT
00190: 4D 4C 3E 3C 48 45 41 44 3E 3C 54 49 54 4C 45 3E ML><HEAD><TITLE>
001A0: 59 6F 75 20 61 72 65 20 6E 6F 74 20 61 75 74 68 You are not auth
001B0: 6F 72 69 7A 65 64 20 74 6F 20 76 69 65 77 20 74 orized to view t
001C0: 68 69 73 20 70 61 67 65 3C 2F 54 49 54 4C 45 3E his page</TITLE>
001D0: 0D 0A 3C 4D 45 54 41 20 48 54 54 50 2D 45 51 55 ..<META HTTP-EQU
001E0: 49 56 3D 22 43 6F 6E 74 65 6E 74 2D 54 79 70 65 IV="Content-Type
001F0: 22 20 43 6F 6E 74 65 6E 74 3D 22 74 65 78 74 2F " Content="text/
00200: 68 74 6D 6C 3B 20 63 68 61 72 73 65 74 3D 57 69 html; charset=Wi
00210: 6E 64 6F 77 73 2D 31 32 35 32 22 3E 0D 0A 3C 53 ndows-1252">..<S
00220: 54 59 4C 45 20 74 79 70 65 3D 22 74 65 78 74 2F TYLE type="text/
00230: 63 73 73 22 3E 0D 0A 20 20 42 4F 44 59 20 7B 20 css">.. BODY {
00240: 66 6F 6E 74 3A 20 38 70 74 2F 31 32 70 74 20 76 font: 8pt/12pt v
00250: 65 72 64 61 6E 61 20 7D 0D 0A 20 20 48 31 20 7B erdana }.. H1 {
00260: 20 66 6F 6E 74 3A 20 31 33 70 74 2F 31 35 70 74 font: 13pt/15pt
00270: 20 76 65 72 64 61 6E 61 20 7D 0D 0A 20 20 48 32 verdana }.. H2
00280: 20 7B 20 66 6F 6E 74 3A 20 38 70 74 2F 31 32 70 { font: 8pt/12p
00290: 74 20 76 65 72 64 61 6E 61 20 7D 0D 0A 20 20 41 t verdana }.. A
002A0: 3A 6C 69 6E 6B 20 7B 20 63 6F 6C 6F 72 3A 20 72 :link { color: r
002B0: 65 64 20 7D 0D 0A 20 20 41 3A 76 69 73 69 74 65 ed }.. A:visite
002C0: 64 20 7B 20 63 6F 6C 6F 72 3A 20 6D 61 72 6F 6F d { color: maroo
002D0: 6E 20 7D 0D 0A 3C 2F 53 54 59 4C 45 3E 0D 0A 3C n }..</STYLE>..<
002E0: 2F 48 45 41 44 3E 3C 42 4F 44 59 3E 3C 54 41 42 /HEAD><BODY><TAB
002F0: 4C 45 20 77 69 64 74 68 3D 35 30 30 20 62 6F 72 LE width=500 bor
00300: 64 65 72 3D 30 20 63 65 6C 6C 73 70 61 63 69 6E der=0 cellspacin
00310: 67 3D 31 30 3E 3C 54 52 3E 3C 54 44 3E 0D 0A 0D g=10><TR><TD>...
00320: 0A 3C 68 31 3E 59 6F 75 20 61 72 65 20 6E 6F 74 .<h1>You are not
00330: 20 61 75 74 68 6F 72 69 7A 65 64 20 74 6F 20 76 authorized to v
00340: 69 65 77 20 74 68 69 73 20 70 61 67 65 3C 2F 68 iew this page</h
00350: 31 3E 0D 0A 59 6F 75 20 64 6F 20 6E 6F 74 20 68 1>..You do not h
00360: 61 76 65 20 70 65 72 6D 69 73 73 69 6F 6E 20 74 ave permission t
00370: 6F 20 76 69 65 77 20 74 68 69 73 20 64 69 72 65 o view this dire
00380: 63 74 6F 72 79 20 6F 72 20 70 61 67 65 20 75 73 ctory or page us
00390: 69 6E 67 20 74 68 65 20 63 72 65 64 65 6E 74 69 ing the credenti
003A0: 61 6C 73 20 74 68 61 74 20 79 6F 75 20 73 75 70 als that you sup
003B0: 70 6C 69 65 64 20 62 65 63 61 75 73 65 20 79 6F plied because yo
003C0: 75 72 20 57 65 62 20 62 72 6F 77 73 65 72 20 69 ur Web browser i
003D0: 73 20 73 65 6E 64 69 6E 67 20 61 20 57 57 57 2D s sending a WWW-
003E0: 41 75 74 68 65 6E 74 69 63 61 74 65 20 68 65 61 Authenticate hea
003F0: 64 65 72 20 66 69 65 6C 64 20 74 68 61 74 20 74 der field that t
00400: 68 65 20 57 65 62 20 73 65 72 76 65 72 20 69 73 he Web server is
00410: 20 6E 6F 74 20 63 6F 6E 66 69 67 75 72 65 64 20 not configured
00420: 74 6F 20 61 63 63 65 70 74 2E 0D 0A 3C 68 72 3E to accept...<hr>
00430: 0D 0A 3C 70 3E 50 6C 65 61 73 65 20 74 72 79 20 ..<p>Please try
00440: 74 68 65 20 66 6F 6C 6C 6F 77 69 6E 67 3A 3C 2F the following:</
00450: 70 3E 0D 0A 3C 75 6C 3E 0D 0A 3C 6C 69 3E 43 6F p>..<ul>..<li>Co
00460: 6E 74 61 63 74 20 74 68 65 20 57 65 62 20 73 69 ntact the Web si
00470: 74 65 20 61 64 6D 69 6E 69 73 74 72 61 74 6F 72 te administrator
00480: 20 69 66 20 79 6F 75 20 62 65 6C 69 65 76 65 20 if you believe
00490: 79 6F 75 20 73 68 6F 75 6C 64 20 62 65 20 61 62 you should be ab
004A0: 6C 65 20 74 6F 20 76 69 65 77 20 74 68 69 73 20 le to view this
004B0: 64 69 72 65 63 74 6F 72 79 20 6F 72 20 70 61 67 directory or pag
004C0: 65 2E 3C 2F 6C 69 3E 0D 0A 3C 6C 69 3E 43 6C 69 e.</li>..<li>Cli
004D0: 63 6B 20 74 68 65 20 3C 61 20 68 72 65 66 3D 22 ck the <a href="
004E0: 6A 61 76 61 73 63 72 69 70 74 3A 6C 6F 63 61 74 javascript:locat
004F0: 69 6F 6E 2E 72 65 6C 6F 61 64 28 29 22 3E 52 65 ion.reload()">Re
00500: 66 72 65 73 68 3C 2F 61 3E 20 62 75 74 74 6F 6E fresh</a> button
00510: 20 74 6F 20 74 72 79 20 61 67 61 69 6E 20 77 69 to try again wi
00520: 74 68 20 64 69 66 66 65 72 65 6E 74 20 63 72 65 th different cre
00530: 64 65 6E 74 69 61 6C 73 2E 3C 2F 6C 69 3E 0D 0A dentials.</li>..
00540: 3C 2F 75 6C 3E 0D 0A 3C 68 32 3E 48 54 54 50 20 </ul>..<h2>HTTP
00550: 45 72 72 6F 72 20 34 30 31 2E 32 20 2D 20 55 6E Error 401.2 - Un
00560: 61 75 74 68 6F 72 69 7A 65 64 3A 20 41 63 63 65 authorized: Acce
00570: 73 73 20 69 73 20 64 65 6E 69 65 64 20 64 75 65 ss is denied due
00580: 20 74 6F 20 73 65 72 76 65 72 20 63 6F 6E 66 69 to server confi
00590: 67 75 72 61 74 69 6F 6E 2E 3C 62 72 3E 49 6E 74 guration.<br>Int
005A0: 65 72 6E 65 74 20 49 6E 66 6F 72 6D 61 74 69 6F ernet Informatio
005B0: 6E 20 53 65 72 76 69 63 65 73 20 28 49 49 53 29 n Services (IIS)
005C0: 3C 2F 68 32 3E 0D 0A 3C 68 72 3E 0D 0A 3C 70 3E </h2>..<hr>..<p>
005D0: 54 65 63 68 6E 69 63 61 6C 20 49 6E 66 6F 72 6D Technical Inform
005E0: 61 74 69 6F 6E 20 28 66 6F 72 ation (for

----------------------------
Packet 3 from a "BAD" client
----------------------------
3 2.725859 LOCAL 000FFEAE56DB HTTP Continuation Response Packet INTRANET1
FiservLab2 IP
FRAME: Base frame properties
FRAME: Time of capture = 3/15/2006 11:39:36 AM
FRAME: Time delta from previous physical frame: 0 microseconds
FRAME: Frame number: 3
FRAME: Total frame length: 501 bytes
FRAME: Capture frame length: 501 bytes
FRAME: Frame data: Number of data bytes remaining = 501 (0x01F5)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 000FFEAE56DB
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 0012793C56EC
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 34704; Total IP
Length = 487; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 487 (0x1E7)
IP: Identification = 34704 (0x8790)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 10.10.1.95
IP: Destination Address = 10.10.2.51
TCP: Control Bits: .AP..., len: 447, seq:2152555517-2152555964,
ack:1411174601, win:65320, src: 80 dst: 2042
TCP: Source Port = World Wide Web HTTP
TCP: Destination Port = 0x07FA
TCP: Sequence Number = 2152555517 (0x804D63FD)
TCP: Acknowledgement Number = 1411174601 (0x541CD0C9)
TCP: Data Offset = 20 bytes
TCP: 0101.... = Data Offset (20 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x18 : .AP...
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....1... = Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 65320 (0xFF28)
TCP: Checksum = ERROR: CheckSum is 0x197F, Should be 0xFAF2
TCP: Urgent Pointer = 0 (0x0)
HTTP: Continuation Response Packet
HTTP: Data: Number of data bytes remaining = 447 (0x01BF)
00000: 00 0F FE AE 56 DB 00 12 79 3C 56 EC 08 00 45 00 ..þ®VÛ..y<Vì..E.
00010: 01 E7 87 90 40 00 80 06 00 00 0A 0A 01 5F 0A 0A .燐@.€......_..
00020: 02 33 00 50 07 FA 80 4D 63 FD 54 1C D0 C9 50 18 .3.P.ú€McýT.ÐÉP.
00030: FF 28 19 7F 00 00 20 73 75 70 70 6F 72 74 20 70 ÿ(... support p
00040: 65 72 73 6F 6E 6E 65 6C 29 3C 2F 70 3E 0D 0A 3C ersonnel)</p>..<
00050: 75 6C 3E 0D 0A 3C 6C 69 3E 47 6F 20 74 6F 20 3C ul>..<li>Go to <
00060: 61 20 68 72 65 66 3D 22 68 74 74 70 3A 2F 2F 67 a href="http://g
00070: 6F 2E 6D 69 63 72 6F 73 6F 66 74 2E 63 6F 6D 2F o.microsoft.com/
00080: 66 77 6C 69 6E 6B 2F 3F 6C 69 6E 6B 69 64 3D 38 fwlink/?linkid=8
00090: 31 38 30 22 3E 4D 69 63 72 6F 73 6F 66 74 20 50 180">Microsoft P
000A0: 72 6F 64 75 63 74 20 53 75 70 70 6F 72 74 20 53 roduct Support S
000B0: 65 72 76 69 63 65 73 3C 2F 61 3E 20 61 6E 64 20 ervices</a> and
000C0: 70 65 72 66 6F 72 6D 20 61 20 74 69 74 6C 65 20 perform a title
000D0: 73 65 61 72 63 68 20 66 6F 72 20 74 68 65 20 77 search for the w
000E0: 6F 72 64 73 20 3C 62 3E 48 54 54 50 3C 2F 62 3E ords <b>HTTP</b>
000F0: 20 61 6E 64 20 3C 62 3E 34 30 31 3C 2F 62 3E 2E and <b>401</b>.
00100: 3C 2F 6C 69 3E 0D 0A 3C 6C 69 3E 4F 70 65 6E 20 </li>..<li>Open
00110: 3C 62 3E 49 49 53 20 48 65 6C 70 3C 2F 62 3E 2C <b>IIS Help</b>,
00120: 20 77 68 69 63 68 20 69 73 20 61 63 63 65 73 73 which is access
00130: 69 62 6C 65 20 69 6E 20 49 49 53 20 4D 61 6E 61 ible in IIS Mana
00140: 67 65 72 20 28 69 6E 65 74 6D 67 72 29 2C 0D 0A ger (inetmgr),..
00150: 20 61 6E 64 20 73 65 61 72 63 68 20 66 6F 72 20 and search for
00160: 74 6F 70 69 63 73 20 74 69 74 6C 65 64 20 3C 62 topics titled <b
00170: 3E 41 62 6F 75 74 20 53 65 63 75 72 69 74 79 3C >About Security<
00180: 2F 62 3E 2C 20 3C 62 3E 41 75 74 68 65 6E 74 69 /b>, <b>Authenti
00190: 63 61 74 69 6F 6E 3C 2F 62 3E 2C 20 61 6E 64 20 cation</b>, and
001A0: 3C 62 3E 41 62 6F 75 74 20 43 75 73 74 6F 6D 20 <b>About Custom
001B0: 45 72 72 6F 72 20 4D 65 73 73 61 67 65 73 3C 2F Error Messages</
001C0: 62 3E 2E 3C 2F 6C 69 3E 0D 0A 3C 2F 75 6C 3E 0D b>.</li>..</ul>.
001D0: 0A 0D 0A 3C 2F 54 44 3E 3C 2F 54 52 3E 3C 2F 54 ...</TD></TR></T
001E0: 41 42 4C 45 3E 3C 2F 42 4F 44 59 3E 3C 2F 48 54 ABLE></BODY></HT
001F0: 4D 4C 3E 0D 0A ML>..

----------------------------
Packet 4 from a "BAD" client
----------------------------
4 7.366484 LOCAL 000FFEAE56DB TCP Control Bits: .A...., len: 0,
seq:2152555964-2152555964, ack:1411176691, win:65535, src: 80 dst: 2042
INTRANET1 FiservLab2 IP
FRAME: Base frame properties
FRAME: Time of capture = 3/15/2006 11:39:41 AM
FRAME: Time delta from previous physical frame: 4640625 microseconds
FRAME: Frame number: 4
FRAME: Total frame length: 54 bytes
FRAME: Capture frame length: 54 bytes
FRAME: Frame data: Number of data bytes remaining = 54 (0x0036)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 000FFEAE56DB
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 0012793C56EC
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 34790; Total IP
Length = 40; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 40 (0x28)
IP: Identification = 34790 (0x87E6)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 10.10.1.95
IP: Destination Address = 10.10.2.51
TCP: Control Bits: .A...., len: 0, seq:2152555964-2152555964,
ack:1411176691, win:65535, src: 80 dst: 2042
TCP: Source Port = World Wide Web HTTP
TCP: Destination Port = 0x07FA
TCP: Sequence Number = 2152555964 (0x804D65BC)
TCP: Acknowledgement Number = 1411176691 (0x541CD8F3)
TCP: Data Offset = 20 bytes
TCP: 0101.... = Data Offset (20 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 65535 (0xFFFF)
TCP: Checksum = ERROR: CheckSum is 0x17C0, Should be 0x7CCB
TCP: Urgent Pointer = 0 (0x0)
00000: 00 0F FE AE 56 DB 00 12 79 3C 56 EC 08 00 45 00 ..þ®VÛ..y<Vì..E.
00010: 00 28 87 E6 40 00 80 06 00 00 0A 0A 01 5F 0A 0A .(‡æ@.€......_..
00020: 02 33 00 50 07 FA 80 4D 65 BC 54 1C D8 F3 50 10 .3.P.ú€Me¼T.ØóP.
00030: FF FF 17 C0 00 00 ÿÿ.À..

----------------------------
Packet 5 from a "BAD" client
----------------------------
5 7.491484 LOCAL 000FFEAE56DB HTTP Response to Client; HTTP/1.1; Status Code
= 200 - OK INTRANET1 FiservLab2 IP
FRAME: Base frame properties
FRAME: Time of capture = 3/15/2006 11:39:41 AM
FRAME: Time delta from previous physical frame: 125000 microseconds
FRAME: Frame number: 5
FRAME: Total frame length: 1514 bytes
FRAME: Capture frame length: 1514 bytes
FRAME: Frame data: Number of data bytes remaining = 1514 (0x05EA)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 000FFEAE56DB
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 0012793C56EC
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 35103; Total IP
Length = 1500; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 1500 (0x5DC)
IP: Identification = 35103 (0x891F)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 10.10.1.95
IP: Destination Address = 10.10.2.51
TCP: Control Bits: .A...., len: 1460, seq:2152555964-2152557424,
ack:1411176691, win:65535, src: 80 dst: 2042
TCP: Source Port = World Wide Web HTTP
TCP: Destination Port = 0x07FA
TCP: Sequence Number = 2152555964 (0x804D65BC)
TCP: Acknowledgement Number = 1411176691 (0x541CD8F3)
TCP: Data Offset = 20 bytes
TCP: 0101.... = Data Offset (20 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 65535 (0xFFFF)
TCP: Checksum = ERROR: CheckSum is 0x1D74, Should be 0xDEE8
TCP: Urgent Pointer = 0 (0x0)
HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = OK
HTTP: Reason =OK
HTTP: Date =Wed, 15 Mar 2006 16:39:41 GMT
HTTP: Server =Microsoft-IIS/6.0
HTTP: MicrosoftOfficeWebServer =5.0_Pub
HTTP: X-Powered-By = ASP.NET
HTTP: WWW-Authenticate =Negotiate
oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhk
HTTP: Content-Length =33111
HTTP: Content-Type =text/html
HTTP: Set-Cookie =ASPSESSIONIDSAQQSSSS=NCKPJFAAIKMHEILNMAMLKPFI; path=/
HTTP: Cache-Control =private
HTTP: Data: Number of data bytes remaining = 928 (0x03A0)
00000: 00 0F FE AE 56 DB 00 12 79 3C 56 EC 08 00 45 00 ..þ®VÛ..y<Vì..E.
00010: 05 DC 89 1F 40 00 80 06 00 00 0A 0A 01 5F 0A 0A .܉***@.€......_..
00020: 02 33 00 50 07 FA 80 4D 65 BC 54 1C D8 F3 50 10 .3.P.ú€Me¼T.ØóP.
00030: FF FF 1D 74 00 00 48 54 54 50 2F 31 2E 31 20 32 ÿÿ.t..HTTP/1.1 2
00040: 30 30 20 4F 4B 0D 0A 44 61 74 65 3A 20 57 65 64 00 OK..Date: Wed
00050: 2C 20 31 35 20 4D 61 72 20 32 30 30 36 20 31 36 , 15 Mar 2006 16
00060: 3A 33 39 3A 34 31 20 47 4D 54 0D 0A 53 65 72 76 :39:41 GMT..Serv
00070: 65 72 3A 20 4D 69 63 72 6F 73 6F 66 74 2D 49 49 er: Microsoft-II
00080: 53 2F 36 2E 30 0D 0A 4D 69 63 72 6F 73 6F 66 74 S/6.0..Microsoft
00090: 4F 66 66 69 63 65 57 65 62 53 65 72 76 65 72 3A OfficeWebServer:
000A0: 20 35 2E 30 5F 50 75 62 0D 0A 58 2D 50 6F 77 65 5.0_Pub..X-Powe
000B0: 72 65 64 2D 42 79 3A 20 41 53 50 2E 4E 45 54 0D red-By: ASP.NET.
000C0: 0A 57 57 57 2D 41 75 74 68 65 6E 74 69 63 61 74 .WWW-Authenticat
000D0: 65 3A 20 4E 65 67 6F 74 69 61 74 65 20 6F 59 47 e: Negotiate oYG
000E0: 67 4D 49 47 64 6F 41 4D 4B 41 51 43 68 43 77 59 gMIGdoAMKAQChCwY
000F0: 4A 4B 6F 5A 49 67 76 63 53 41 51 49 43 6F 6F 47 JKoZIgvcSAQICooG
00100: 49 42 49 47 46 59 49 47 43 42 67 6B 71 68 6B 69 IBIGFYIGCBgkqhki
00110: 47 39 78 49 42 41 67 49 43 41 47 39 7A 4D 48 47 G9xIBAgICAG9zMHG
00120: 67 41 77 49 42 42 61 45 44 41 67 45 50 6F 6D 55 gAwIBBaEDAgEPomU
00130: 77 59 36 41 44 41 67 45 58 6F 6C 77 45 57 67 4B wY6ADAgEXolwEWgK
00140: 51 31 54 67 76 5A 70 54 2B 33 58 6F 43 68 57 31 Q1TgvZpT+3XoChW1
00150: 61 61 65 44 66 62 77 78 52 43 4D 4B 4A 69 65 59 aaeDfbwxRCMKJieY
00160: 33 54 71 5A 72 64 57 70 68 63 5A 6D 41 48 58 77 3TqZrdWphcZmAHXw
00170: 37 5A 66 30 65 62 54 6E 4B 36 51 48 56 7A 6C 32 7Zf0ebTnK6QHVzl2
00180: 53 2F 69 35 30 53 41 2B 41 4B 6A 6E 67 52 47 61 S/i50SA+AKjngRGa
00190: 63 6D 71 4D 33 67 6E 38 6E 4E 77 57 37 46 50 37 cmqM3gn8nNwW7FP7
001A0: 34 2B 5A 4B 78 44 30 39 33 39 4E 4B 43 4B 6E 71 4+ZKxD0939NKCKnq
001B0: 4E 66 47 42 69 66 67 3D 3D 0D 0A 43 6F 6E 74 65 NfGBifg==..Conte
001C0: 6E 74 2D 4C 65 6E 67 74 68 3A 20 33 33 31 31 31 nt-Length: 33111
001D0: 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 ..Content-Type:
001E0: 74 65 78 74 2F 68 74 6D 6C 0D 0A 53 65 74 2D 43 text/html..Set-C
001F0: 6F 6F 6B 69 65 3A 20 41 53 50 53 45 53 53 49 4F ookie: ASPSESSIO
00200: 4E 49 44 53 41 51 51 53 53 53 53 3D 4E 43 4B 50 NIDSAQQSSSS=NCKP
00210: 4A 46 41 41 49 4B 4D 48 45 49 4C 4E 4D 41 4D 4C JFAAIKMHEILNMAML
00220: 4B 50 46 49 3B 20 70 61 74 68 3D 2F 0D 0A 43 61 KPFI; path=/..Ca
00230: 63 68 65 2D 63 6F 6E 74 72 6F 6C 3A 20 70 72 69 che-control: pri
00240: 76 61 74 65 0D 0A 0D 0A 0D 0A 3C 68 74 6D 6C 3E vate......<html>
00250: 0D 0A 0D 0A 3C 68 65 61 64 3E 0D 0A 3C 6D 65 74 ....<head>..<met
00260: 61 20 68 74 74 70 2D 65 71 75 69 76 3D 22 43 6F a http-equiv="Co
00270: 6E 74 65 6E 74 2D 4C 61 6E 67 75 61 67 65 22 20 ntent-Language"
00280: 63 6F 6E 74 65 6E 74 3D 22 65 6E 2D 75 73 22 3E content="en-us">
00290: 0D 0A 3C 6D 65 74 61 20 6E 61 6D 65 3D 22 47 45 ..<meta name="GE
002A0: 4E 45 52 41 54 4F 52 22 20 63 6F 6E 74 65 6E 74 NERATOR" content
002B0: 3D 22 4D 69 63 72 6F 73 6F 66 74 20 46 72 6F 6E ="Microsoft Fron
002C0: 74 50 61 67 65 20 36 2E 30 22 3E 0D 0A 3C 6D 65 tPage 6.0">..<me

[Ludwik]

Does anybody know what was the actual solution to this problem?

Post by h***@nospam.nospam
I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?
Code Count
===== =======
401 827,314
200 652,067
The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165
The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)
Client tries to get copy of menu.css, gets 304, file on client is OK to use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110
A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30
A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10
A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[h***@nospam.nospam]

Ludwik,

The fix for us was to not require authenitication. Here is a link to an
article that looks like it has the "real" soultion.

http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by Ludwik
Does anybody know what was the actual solution to this problem?

Post by h***@nospam.nospam
I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?
Code Count
===== =======
401 827,314
200 652,067
The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165
The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)
Client tries to get copy of menu.css, gets 304, file on client is OK to use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110
A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30
A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10
A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[David Wang [Msft]]

Umm, the user question requires authentication to be enabled, so your
suggestion is a non-starter.

Of course, if you turn off authentication you will remove 401.1 and 401.2
since the web server no longer requires authentication (that's why it sends
the 401.2 in the first place, and 401.1 is simply part of the authentication
protocol).

There's no "issue" here at all.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by h***@nospam.nospam
Ludwik,
The fix for us was to not require authenitication. Here is a link to an
article that looks like it has the "real" soultion.
http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by Ludwik
Does anybody know what was the actual solution to this problem?

Post by h***@nospam.nospam
I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?
Code Count
===== =======
401 827,314
200 652,067
The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165
The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)
Client tries to get copy of menu.css, gets 304, file on client is OK to use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110
A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30
A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10
A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[h***@nospam.nospam]

Umm David there is an issue here. IIS6 does not do authentication the same
way as IIS5. The fix for me was to turn off authentication because my
application does not need it. If Ludwik's app needs authentication and he is
running on IIS6 and he has noticed that authentication is not the same as in
IIS5, that he now has more round trips, he can take the time to read the
information provided on the linked page. If he is has clients with a high
latency to the web server he will see performance improvements by making the
changes recommended.

Did you read the linked page?

http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by David Wang [Msft]
Umm, the user question requires authentication to be enabled, so your
suggestion is a non-starter.
Of course, if you turn off authentication you will remove 401.1 and 401.2
since the web server no longer requires authentication (that's why it sends
the 401.2 in the first place, and 401.1 is simply part of the authentication
protocol).
There's no "issue" here at all.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by h***@nospam.nospam
Ludwik,
The fix for us was to not require authenitication. Here is a link to an
article that looks like it has the "real" soultion.
http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by Ludwik
Does anybody know what was the actual solution to this problem?

Post by h***@nospam.nospam
I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?
Code Count
===== =======
401 827,314
200 652,067
The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165
The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)
Client tries to get copy of menu.css, gets 304, file on client is OK to use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110
A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30
A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10
A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[David Wang [Msft]]

Hehehe... where do you think the information you quote ultimately came from?
:-)

I agree that if your application does not require authentication that
turning it off on IIS6 can improve your performance because of the Security
changes we made to IIS6 regarding NTLM.

I disagree with the suggestion that "The fix for us was to not require
authenitication [sic]" when the user said that authentication is required.

As for whether the performance impact is ok when you do require NTLM
authentication - clearly that is for you to decide. We default on the
security side of the line on IIS6. We presume that if it bugs you enough,
you will go find ways to change it (or else it doesn't really bother you
enough). But, the default will be secure to prevent mass worm attacks, at
minimum.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by h***@nospam.nospam
Umm David there is an issue here. IIS6 does not do authentication the same
way as IIS5. The fix for me was to turn off authentication because my
application does not need it. If Ludwik's app needs authentication and he is
running on IIS6 and he has noticed that authentication is not the same as in
IIS5, that he now has more round trips, he can take the time to read the
information provided on the linked page. If he is has clients with a high
latency to the web server he will see performance improvements by making the
changes recommended.
Did you read the linked page?
http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by David Wang [Msft]
Umm, the user question requires authentication to be enabled, so your
suggestion is a non-starter.
Of course, if you turn off authentication you will remove 401.1 and 401.2
since the web server no longer requires authentication (that's why it sends
the 401.2 in the first place, and 401.1 is simply part of the
authentication
protocol).
There's no "issue" here at all.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by h***@nospam.nospam
Ludwik,
The fix for us was to not require authenitication. Here is a link to an
article that looks like it has the "real" soultion.
http://blogs.technet.com/industry_insiders/articles/407751.aspx

Post by Ludwik
Does anybody know what was the actual solution to this problem?

Post by h***@nospam.nospam
I have a question about authentication and IIS 6.0. I am seeing a large
number
of 401.1 and 401.2 errors in my IIS log files.
In fact for this application the number of 401 errors exceeds the number of
200s.
1) Is this normal?
2) What can I do to prevent the 401 errors?
3) Does each 401.2, 401.1 involve a round trip to the client?
4) Will this situation have a performance impact in a high latency
environment?
5) What can I do to resolve this problem?
Code Count
===== =======
401 827,314
200 652,067
The breakdown by type of 401
Code Count
===== ======
401.2 424,149
401.1 403,165
The application is a traditional ASP app and uses remote scripting.
The app runs on an intranet and is hosted on IIS 6.0 in a NLB cluster.
Integrated Windows authentication is turned on for this site.
I asked the security folks and we use NTLM, not Kerberos.
The clients are mostly IE 6.0.2800 with some 5.5. The log entries below
show an example of what happens in the app (client was IE 6.0.2800)
(sorry about the formatting)
Client tries to get copy of menu.css, gets 304, file on client is OK
to
use.
At this point the client has already hit the web server and been
authenticated
as you can see from the log entry
2004-10-28 11:26:02 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 110
A few mouse clicks later the client request menu.css a second time.
This time we get a 401.2 followed by a 401.1, then the 304.
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 220
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:28:56 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 30
A few mouse clicks later the client request menu.css a third time.
This time we get the 304 right away
2004-10-28 11:34:04 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 10
A few mouse clicks later the client request menu.css a fourth time.
This time we go through the 401.2, 401.1, 304 steps.
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 2 1849 30
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css - -
192.168.39.49 HTTP/1.1 401 1 1940 10
2004-10-28 11:38:50 192.168.39.191 GET /root/inc/style/menu.css -
vpcs2003web1\Administrator 192.168.39.49 HTTP/1.1 304 0 212 50

[unknown]

Post by David Wang [Msft]
Hehehe... where do you think the information you quote ultimately came from?
:-)

I've tried the NTAuthenticationProviders and AuthPersistSingleRequest
settings outlined in the article and this made no difference to the 401
behavior on our server. I used the scripts outlined within the article
to set this at the web site level and confirm the settings with the
Metabase explorer.

So I'm confused as to whether this is supported or sensitive to other
configuration changes we may have made?



Darren

[David Wang [Msft]]

What evidence and troubleshoot steps did you follow to determine that those
properties apply to your situation?

Can you definitely tell me the authentication protocol used on the requests
generating 401.2 and 401.1?
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by unknown

Post by David Wang [Msft]
Hehehe... where do you think the information you quote ultimately came
from? :-)

I've tried the NTAuthenticationProviders and AuthPersistSingleRequest
settings outlined in the article and this made no difference to the 401
behavior on our server. I used the scripts outlined within the article to
set this at the web site level and confirm the settings with the Metabase
explorer.
So I'm confused as to whether this is supported or sensitive to other
configuration changes we may have made?
Darren

[unknown]

Post by David Wang [Msft]
What evidence and troubleshoot steps did you follow to determine that those
properties apply to your situation?

I'm using Fiddler over a non SSL connection to our test server to trace
the requests and responses from our application. I clear the browser
cache so I'm removing any cache policies we've applied. In each case all
static and dynamic files (an ASP.NET application) that are served by IIS
show 401 followed by the usual challenge cycle. All connections
should be using http 1.1 and the timeout for connections is the default
of 120s. After making the two changes I expected to see an initial 401
for the first request and then subsequent files from that page retrieved
without a challenge.

When you say "those properties apply to our situation" are there
situations where this wouldn't apply and are they documented? I'm going
by what I've read in the IIS res kit, technet and the previous web log
article.

Post by David Wang [Msft]
Can you definitely tell me the authentication protocol used on the requests
generating 401.2 and 401.1?

Server side this is an ASP.NET application running under a default
application pool assigned to the standard identity NETWORK SERVICE. We
use the IIS 5.x trick for ASP.NET of aspnet_setreg to change the
application's identity to run as least privilage and access our database
(think classic 3 tier it will be close enough). Since this should not be
accessible by anonymous users we've applied NTFS permissions to the
static and dynamic files (aspx, ascx) for the group "Authenticated Users".

After applying NTAuthenticationProviders and AuthPersistSingleRequest we
see the following kinds of traces, some of the http headers have
obviously been removed:

The example here is a single static js file referenced on a page, each
static file (js, css, gif, jpg etc.) on the page goes through the same
cycle. I expected the first page to be challenged and then all further
static files to be retrieved under the same connection with the existing
authenticated credentials.

Client's request:
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1

Server responds with:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Proxy-Support: Session-Based-Authentication

Client then sends up:
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1
Proxy-Connection: Keep-Alive
Authorization: NTLM<removed for sec>

Server's response is:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM<removed for sec>
Proxy-Support: Session-Based-Authentication

Final client request:
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1
Proxy-Connection: Keep-Alive
Authorization: NTLM <removed for sec>

Server serves file:
HTTP/1.1 200 OK

I hope this was the kind of thing you were looking for if not let me
know and I'll try and provide more details.


Darren

[David Wang [Msft]]

Ok, your request sequence indicates that NTLM is being used/negotiated. I
needed to know that in reference to those two properties.

Are you going through a proxy server between client/server and if so, is the
proxy friendly to NTLM. Proxy which multiplexes connections can result in
behavior like you describe.

Or can you remove the proxy from the picture and see if anything changes?


I basically use WFetch right against IIS6 for NTLM and see the expected
behavior, so I believe we are just looking for causes of connections not
being reused...

http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Diagnose_IIS_401_Access_Denied.aspx
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by unknown

Post by David Wang [Msft]
What evidence and troubleshoot steps did you follow to determine that
those properties apply to your situation?

I'm using Fiddler over a non SSL connection to our test server to trace
the requests and responses from our application. I clear the browser cache
so I'm removing any cache policies we've applied. In each case all static
and dynamic files (an ASP.NET application) that are served by IIS show 401
followed by the usual challenge cycle. All connections should be using
http 1.1 and the timeout for connections is the default of 120s. After
making the two changes I expected to see an initial 401 for the first
request and then subsequent files from that page retrieved without a
challenge.
When you say "those properties apply to our situation" are there
situations where this wouldn't apply and are they documented? I'm going by
what I've read in the IIS res kit, technet and the previous web log
article.

Post by David Wang [Msft]
Can you definitely tell me the authentication protocol used on the
requests generating 401.2 and 401.1?

Server side this is an ASP.NET application running under a default
application pool assigned to the standard identity NETWORK SERVICE. We use
the IIS 5.x trick for ASP.NET of aspnet_setreg to change the application's
identity to run as least privilage and access our database (think classic
3 tier it will be close enough). Since this should not be accessible by
anonymous users we've applied NTFS permissions to the static and dynamic
files (aspx, ascx) for the group "Authenticated Users".
After applying NTAuthenticationProviders and AuthPersistSingleRequest we
see the following kinds of traces, some of the http headers have obviously
The example here is a single static js file referenced on a page, each
static file (js, css, gif, jpg etc.) on the page goes through the same
cycle. I expected the first page to be challenged and then all further
static files to be retrieved under the same connection with the existing
authenticated credentials.
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM
Proxy-Support: Session-Based-Authentication
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1
Proxy-Connection: Keep-Alive
Authorization: NTLM<removed for sec>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM<removed for sec>
Proxy-Support: Session-Based-Authentication
GET /app/static/v4_5_0_8714/minmax.js HTTP/1.1
Proxy-Connection: Keep-Alive
Authorization: NTLM <removed for sec>
HTTP/1.1 200 OK
I hope this was the kind of thing you were looking for if not let me know
and I'll try and provide more details.
Darren

[unknown]

David,

Thanks for taking the time to respond and track this down.

Post by David Wang [Msft]
Are you going through a proxy server between client/server and if so, is the
proxy friendly to NTLM. Proxy which multiplexes connections can result in
behavior like you describe.

No, we're not using a proxy server in this case.

Post by David Wang [Msft]
I basically use WFetch right against IIS6 for NTLM and see the expected

I fired up WFetch and ran this on the web server against localhost to
take any network effect out of the equation and see the same behaviour.
I presume if I setup the host, path, authentication details and query
for a gif image with the 'reuse socket' option checked I shouldn't see
401 challenges if the settings are working correctly?


Regards
Darren

[David Wang [Msft]]

I want to make sure you understand how the NTLM handshake works.

1. Browser always makes first request anonymous since it does not know what
authentication protocol the website requests.
2. Website returns 401.2 with WWW-Authenticate and closes connection
3. Browser makes second request with Authorization: NTLM <some hash>
4. Website returns 401.1 and keeps connection alive
5. Browser makes third request with Authorization: NTLM <correct hash>
6. Website returns 200 (or whatever it is supposed to return on access
allowed).

At this point, anonymous requests over the connection made in step #3 will
be considered authenticated.

How you test this with WFetch:
1. Make NTLM request with reuse socket checked
2. Make Anonymous request with reuse socket checked

The anonymous request should succeed and you see no more 401s after the
handshake in #1 as long as the request is over the connection made in #1.
WFetch will tell you whether this is happening or not.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by unknown
David,
Thanks for taking the time to respond and track this down.

Post by David Wang [Msft]
Are you going through a proxy server between client/server and if so, is
the proxy friendly to NTLM. Proxy which multiplexes connections can
result in behavior like you describe.

No, we're not using a proxy server in this case.

Post by David Wang [Msft]
I basically use WFetch right against IIS6 for NTLM and see the expected

I fired up WFetch and ran this on the web server against localhost to take
any network effect out of the equation and see the same behaviour. I
presume if I setup the host, path, authentication details and query for a
gif image with the 'reuse socket' option checked I shouldn't see 401
challenges if the settings are working correctly?
Regards
Darren

[unknown]

Post by David Wang [Msft]
1. Make NTLM request with reuse socket checked
2. Make Anonymous request with reuse socket checked

Ok using wfetch with the anonymous request after the NTLM request I
don't see the 401. I tested this both locally on the server (to
localhost) and remotely from my dev machine. Both results identical.

I've taken Fiddler out of the equation - may be this was working like a
proxy and skewing results. I'm now just checking the IIS logs and this
seems to be working more reliably.

I presume however that sometimes IE will spin off multiple request
threads and each of these will go through the NTLM challenge cycle? If
then decides to reuse the connection each will return the resource
without the 401.2 and 401.1.

Thanks for tracking this down, the results now seem much more
predictable and I'm not seeing as many 401 challenges. As I said may be
trying to debug this with Fiddler was masking the settings changes.


Darren

[David Wang [Msft]]

I believe IE (using WinInet) will open up to two concurrent connections, and
each will independently go through the NTLM challenge cycle. Sometimes,
unexpected network events on one connection cause IE to abort both
connections, resulting in extraneous re-authentication - but IIS can't
really control that.

http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx

I prefer to use non-invasive monitors/tools to get an accurate reading of
what is going on. Rule #1 of testing/troubleshooting - do not trust the
system under test to tell you the truth. Go with an independent second
opinion. It is a little harder because it requires you to understand what is
going on and re-model just the necessary pieces to reproduce the issue, but
understanding what is going on isn't that bad, is it? :-)
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

Post by David Wang [Msft]
1. Make NTLM request with reuse socket checked
2. Make Anonymous request with reuse socket checked

Ok using wfetch with the anonymous request after the NTLM request I don't
see the 401. I tested this both locally on the server (to localhost) and
remotely from my dev machine. Both results identical.
I've taken Fiddler out of the equation - may be this was working like a
proxy and skewing results. I'm now just checking the IIS logs and this
seems to be working more reliably.
I presume however that sometimes IE will spin off multiple request threads
and each of these will go through the NTLM challenge cycle? If then
decides to reuse the connection each will return the resource without the
401.2 and 401.1.
Thanks for tracking this down, the results now seem much more predictable
and I'm not seeing as many 401 challenges. As I said may be trying to
debug this with Fiddler was masking the settings changes.
Darren