Integrated Windows Authentication - Double Hits

Surely the problem is on the client, in this case Internet Explorer? I
mean it is the one which decides on each click to send and
unauthenticated request which gets bounced. How could IE know that
there is an ISA box?
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

> Why is this a problem in the first place?  There is a performance hit, sure,
> but if it works, a bit of extra data in the log is no big deal.  Any log
> analysis software worth a buck can sort it out if need be.

We have a high latency connection to Asia (300ms) and any extra
connection is just adding to the problem. Cutting requests by 50% will
bring, I am sure, a marked boost in response tines.
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Marc J. Cawood" <cawoodm RemoveThis @gmail.com> wrote in message
news:70a24bfd-e6dc-450e-b1a4-f5b137e897a5@i29g2000prf.googlegroups.com...
> Looking at the IIS 6 log files we have noticed that for every click a
> user makes for a resource, 2 hits (and thus 2 round trips to the
> server) are made:
>
> 1) Anonymous request with response status 401
> RESPONSE Header is:
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
>
> 2) Authorised request with response status 200
> REQUEST Header is:
> POST /xyz_
> ...
> Authorization: Negotiate YII....
>
> However, it's like this for EVERY single click! Why does the browser
> not maintain some sort of "memory" that this server ALWAYS wants an
> authorised request?
>
> This is a real performance hit for the server and especially for high
> latency networks!
>
> Can anything be done?
>

In IIS manager open the properties dialog of your site and on the Web Site
tab make sure you have HTTP Keep-Alives Enabled.

Ordinarily having served a HTTP/1.1 request a server would not close the
TCP/IP connection used to make the request. This would allow the client to
re-use the connection for further requests. This generally a good idea
since it reduces the cost of setting up the connection in the first place.
It is the connection which has been authenticated and associated with a
security token. All subsequent requests on that connection will operate
under that security token and will not need to be re-authenticated.

Turning off HTTP Keep-Alives forces the server to close each connection
after each request therefore each request to a restricted resources will
require re-authentication before progressing.


--
Anthony Jones - MVP ASP/ASP.NET
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Marc J. Cawood" <cawoodm.DeleteThis@gmail.com> wrote in message
news:5b6dd482-5222-4882-9adf-493eab602dd9@e6g2000prf.googlegroups.com...
> Keep-Alives were on. However, as I understand it, you'll still get a
> log entry for each hit to the server; even if this takes place within
> the same TCP connection.

Yes that is true and in fact most HTTP/1.1 traffic should be operating
through existing connections not creating a new connections for each
request. However once the authentication cycle has completed (there are
actually three request/response pairs needed to estabilsh an authenticated
connection) you should not be seeing lots of further 401 responses.

Typically an IE browser will open 2 connections to the same server so the
first time a client starts using the server you should see a couple of 401s
in log but after that the clients should continue using the authenticated
connections it has and operate like it would if anonymous access were
enabled.

>
> When I switch off Integrated Authentication we're back to 1 hit per
> click...

In that case something else is dropping the connections between requests.
Do you have an ISA box, other proxy server or port-forwarding router between
your server and your client?

For example an ISA box will not reuse an authenticated connection for other
clients. I'm not an ISA expert so I could be wrong but I think it simply
drops the connection.

--
Anthony Jones - MVP ASP/ASP.NET
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"For example an ISA box will not reuse an authenticated connection for other
clients. I'm not an ISA expert so I could be wrong but I think it simply
drops the connection."

That has been my experince with ISA proxy servers also.

If this is a persistant problem, and the connection and location of the
users is persistant, the ISA server can be configured to bypass that traffic
(essentially ignoring it) and let the end to end connection persist with
keep alives.

Why is this a problem in the first place? There is a performance hit, sure,
but if it works, a bit of extra data in the log is no big deal. Any log
analysis software worth a buck can sort it out if need be.
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

Are these POST requests? (e.g. ASP.NET postbacks)?

POST requests will generate these extra 401 entries for POST requests when
using NTLM

Cheers
Ken

"Marc J. Cawood" <cawoodm.RemoveThis@gmail.com> wrote in message
news:70a24bfd-e6dc-450e-b1a4-f5b137e897a5@i29g2000prf.googlegroups.com...
> Looking at the IIS 6 log files we have noticed that for every click a
> user makes for a resource, 2 hits (and thus 2 round trips to the
> server) are made:
>
> 1) Anonymous request with response status 401
> RESPONSE Header is:
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
>
> 2) Authorised request with response status 200
> REQUEST Header is:
> POST /xyz_
> ...
> Authorization: Negotiate YII....
>
> However, it's like this for EVERY single click! Why does the browser
> not maintain some sort of "memory" that this server ALWAYS wants an
> authorised request?
>
> This is a real performance hit for the server and especially for high
> latency networks!
>
> Can anything be done?
>
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Marc J. Cawood" <cawoodm RemoveThis @gmail.com> wrote in message
news:57b814ef-aa38-4ad4-85f0-51acd1f0679c@s13g2000prd.googlegroups.com...
> Surely the problem is on the client, in this case Internet Explorer? I
> mean it is the one which decides on each click to send and
> unauthenticated request which gets bounced. How could IE know that
> there is an ISA box?


IE doesn't get to decide if its authorized for the request its sent, thats
the servers job. The server authenticates a connection but if an
intermediatory device such as a proxy server decides to drop that connection
once the request is complete then it has no choice but to create a new
connection when a subsequent request arrives and the origin server has no
choice but to authenticate this new connection.

Do you actually have an ISA box doing a reverse-proxy function at your
servers end or a proxy server at the client end?




--
Anthony Jones - MVP ASP/ASP.NET
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

On Feb 16, 1:07 pm, "Ken Schaefer" <kenREM... DeleteThis @THISadOpenStatic.com>
wrote:
> Are these POST requests? (e.g. ASP.NET postbacks)?
No, GETS exhibit the same double-hit.
> POST requests will generate these extra 401 entries for POST requests when
> using NTLM
This all sucks! Why on earth would a client send 1000 requests to the
same server, same path, different script and each time need to be told
to provide credentials?
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Ken Schaefer" <kenREMOVE DeleteThis @THISadOpenStatic.com> wrote in message
news:OpRKASJcIHA.6060@TK2MSFTNGP04.phx.gbl...
> Are these POST requests? (e.g. ASP.NET postbacks)?
>
> POST requests will generate these extra 401 entries for POST requests when
> using NTLM
>


Interesting? How have you tested that? It I can't see why a POST would
generate extra 401s, there is no need for POST to use additional
connections.

--
Anthony Jones - MVP ASP/ASP.NET
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Marc J. Cawood" <cawoodm.TakeThisOut@gmail.com> wrote in message
news:add24f67-b7d8-4135-9b99-411eef983470@q78g2000hsh.googlegroups.com...
On Feb 16, 1:07 pm, "Ken Schaefer" <kenREM....TakeThisOut@THISadOpenStatic.com>
wrote:
> Are these POST requests? (e.g. ASP.NET postbacks)?
No, GETS exhibit the same double-hit.
> POST requests will generate these extra 401 entries for POST requests when
> using NTLM
This all sucks! Why on earth would a client send 1000 requests to the
same server, same path, different script and each time need to be told
to provide credentials?


As yet I'm not conviced that POSTs would generate 401s every time I've not
been able to reproduce it with my testing.

As far as your '1000 requests' are concerned as long as they you re-using
existing connections they won't have to keep providing credentials. However
without using an existing connection there is no way for a server to be
guaranteed that a subsequent request from the same client is genuine.

You have yet to confirm whether there is any intermedatory that would cause
this behaviour. If you are not in a position to reconfigure then you have
a couple of options.

1) Use the HTTPS ssl protocol. This has to be an end to end connection and
will tunnel through any proxy. Down side is it creates extra load on the
server encrypting the packets send to the client.

2) Only use Integrated logon on the logon page and mark the session as
authenticated. Alllow subsequent requests to access the server anonymously
but have all scripts require the session indicate that the user has logged
on.


--
Anthony Jones - MVP ASP/ASP.NET
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Anthony Jones" <Ant DeleteThis @yadayadayada.com> wrote in message
news:%23j3lIrLcIHA.4436@TK2MSFTNGP05.phx.gbl...
> "Ken Schaefer" <kenREMOVE DeleteThis @THISadOpenStatic.com> wrote in message
> news:OpRKASJcIHA.6060@TK2MSFTNGP04.phx.gbl...
>> Are these POST requests? (e.g. ASP.NET postbacks)?
>>
>> POST requests will generate these extra 401 entries for POST requests
>> when
>> using NTLM
>>
>
>
> Interesting? How have you tested that? It I can't see why a POST would
> generate extra 401s, there is no need for POST to use additional
> connections.

A POST doesn't use extra connections.

But the way NTLM works is a 3 step process:
a) Client sends unauthenticated request
b) Server reponds with 401 and WWW-Authenticate options
c) Client responds with Type 1 NTLM request
d) Server responds with 401 and Type 2 NTLM response
e) Client responds with Type 3 NTLM request
f) Server responds with 200 OK and HTTP content
(you can see this in your IIS log files when you first authenticate)

For all subsequent requests, no credentials are actually send by the
browser. Instead, the underlying TCP/IP connection is authenticated. This
is why NTLM doesn't work through most forward proxy servers (because there
is no end-to-end TCP/IP connection)

The is one exception. When the client makes a POST request. Instead of the
client sending the POST request (plus all the data), and potentially getting
a 401 response from the server (and then having to go through the whole auth
process again sending all the form contents each time), the browser
pre-emptively sends a Type 1 NTLM request (with credentials, but without the
POST data). This generates a 401 from the server (Type 2), to which the
client then sends a Type 3 message (with POST data) to the server.

Cheers
Ken



> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

"Marc J. Cawood" <cawoodm DeleteThis @gmail.com> wrote in message
news:add24f67-b7d8-4135-9b99-411eef983470@q78g2000hsh.googlegroups.com...
On Feb 16, 1:07 pm, "Ken Schaefer" <kenREM... DeleteThis @THISadOpenStatic.com>
wrote:
> > Are these POST requests? (e.g. ASP.NET postbacks)?
>
> No, GETS exhibit the same double-hit.

Are HTTP Keep-Alives enabled on both the server and client? Are there any
proxy servers between client and server?

> > POST requests will generate these extra 401 entries for POST requests
> > when
> > using NTLM
> This all sucks!

I think it sucks less than what you think it does. I think we have some
misunderstanding (I don't fully understand what you are seeing), and you
don't understand fully how NTLM works.

> Why on earth would a client send 1000 requests to the
> same server, same path, different script and each time need to be told
> to provide credentials?

Actually, except for the first request (and POST requests), NTLM doesn't
actually have the client send any credentials (check using a network
sniffer).

Cheers
Ken
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

Marc,

Without trying to initiate another thread of responses, check the following
metabase property:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library...S/b0b4e

AuthPersistence dictates if the HTTP protocol, after going through the
initial NTLM handshake, maintains itself as authenticated and, as such, does
not challenge the user again. Careful, however, because on a
round-robin-like balanced scenario, the user agent will probably have to
re-authenticate itself. This setting (if TRUE) would alliviate the issue
you're having, but its quite unsecure, especially on (reverse)proxy
scenarios.

On another note, and assuming you have kerberos (SPNEGO) enabled browsers,
you could start using Kerberos instead of NTLM. Kerberos usually is a 1-leg
authentication versus the 3-leg of NTLM. Its, additionally, more secure.
Setting it up, however, requires small changes on IIS/AD/DNS. This should be
quite straightforward to set up, but you should evaluate if your current
infra-structure supports it.

Hope it helps

Tiago Halm

"Marc J. Cawood" <cawoodm RemoveThis @gmail.com> wrote in message
news:70a24bfd-e6dc-450e-b1a4-f5b137e897a5@i29g2000prf.googlegroups.com...
> Looking at the IIS 6 log files we have noticed that for every click a
> user makes for a resource, 2 hits (and thus 2 round trips to the
> server) are made:
>
> 1) Anonymous request with response status 401
> RESPONSE Header is:
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
>
> 2) Authorised request with response status 200
> REQUEST Header is:
> POST /xyz_
> ...
> Authorization: Negotiate YII....
>
> However, it's like this for EVERY single click! Why does the browser
> not maintain some sort of "memory" that this server ALWAYS wants an
> authorised request?
>
> This is a real performance hit for the server and especially for high
> latency networks!
>
> Can anything be done?
>
 >> Stay informed about: Integrated Windows Authentication - Double Hits