Integrated Windows Authentication - Double Hits

> check the following
> metabase property:http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>
> 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.

Tiago, I read the info you sent me but cannot find this property in
our metabass.xml file (Server: Microsoft-IIS/6.0). Is it a property I
need to _add_?

Also, as I understand it the logic is the opposite of what you
describe: from the reference:
> When the AuthPersistSingleRequest flag is set to true on this property, and on all other authentication schemes,
> IIS 6.0 automatically reauthenticates every request, even those on the same connection.
Thus our servers behaviour indicates a TRUE situation and I would want
to set it to FALSE. This should, in my understanding, require less CPU
and thus be a performance boost.
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

This guy has the same problem, a deeper understanding but
unfortunately, no answer so far:
http://www.webservertalk.com/archive120-2006-3-1421404.html

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
I wonder if anyone can clear up the confusion around the
AuthPersistence
metabase attribute and IIS 6. Currently if a site is defined to use
integrated authentication under IIS 6 each request causes a 401
challenge/response. Under previous versions this behavior could be
optimised to only challenge on a session or possibly as long as the
socket connection was kept open. This prevented constant 401s when
returning a single page.

The following link: http://technet2.microsoft.com/Windo...23abbc1033.mspx

Suggests that the only valid value for AuthPeristence with IIS 6 is
AuthPersistSingleRequest and that each request will generate a
challenge. However under two conditions - Integrated Auth is set to
NTLM
or Integrated Auth is set to Negotiate and NTLM is used - this value
will be false and the previous behavior will be supported for backward
compatibility. Which I read as we can optimise the challenge response
protocol if NTLM is used.

Another version of the document above was provided with the IIS 6
resource kit and this claims the behavior has been removed and the
only
supported value us AuthPersitSingleRequest.

So can the 401 behavior for integrated authentication be optimised? Or
are we stuck with 3 round trips for each server request with IIS 6?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

Sorry, the value should be "false" to associate the authentication to the
TCP/IP session.

Tiago Halm

"Marc J. Cawood" <cawoodm DeleteThis @gmail.com> wrote in message
news:11fea176-dd63-4823-bbde-77d542ceb558@m34g2000hsc.googlegroups.com...
>> check the following
>> metabase
>> property:http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Librar...
>>
>> 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.
>
> Tiago, I read the info you sent me but cannot find this property in
> our metabass.xml file (Server: Microsoft-IIS/6.0). Is it a property I
> need to _add_?
>
> Also, as I understand it the logic is the opposite of what you
> describe: from the reference:
>> When the AuthPersistSingleRequest flag is set to true on this property,
>> and on all other authentication schemes,
>> IIS 6.0 automatically reauthenticates every request, even those on the
>> same connection.
> Thus our servers behaviour indicates a TRUE situation and I would want
> to set it to FALSE. This should, in my understanding, require less CPU
> and thus be a performance boost.
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

Marc,

This behavior is quite simple. Basically you have the option of establishing
an authenticated TCP/IP session or to authenticate every single HTTP
request.

Why is IIS6, out of the box, forcing the HTTP requests to authenticate
instead of attaching the authentication to the TCP/IP protocol? Because IIS6
is secure by default and HTTP proxies may prove to be dangerous in security
terms. HTTP is point-to-point differently from WS-* which is end-to-end.

Imagine the following scenario:
You (the browser) are connected to the next HOP, which may be a proxy. The
proxy will be connected to the next HOP which may be the webserver. Another
user (another browser) is also connected to the proxy (and implicitly to the
webserver).

YOU [1A] => PROXY => [1B] WEBSERVER
OTHER [2A] => PROXY => [2B] WEBSERVER

If the proxy does not behave, you may end up with this:
OTHER [2A] => PROXY => [1B] WEBSERVER
which means the OTHER user would reach the WEBSERVER as you.

As a final word, if you do not have a proxy between your users and the
webserver (typical intranet scenario), then try setting the metabase
property to false (you need to set it up, since there metabase properties
which have their value to its default unless overridden in the metabase.xml)
and check if the behavior is as expected.

Tiago Halm

"Marc J. Cawood" <cawoodm RemoveThis @gmail.com> wrote in message
news:1f0650fa-2df5-4b83-94bb-e2ba1f981c0f@q33g2000hsh.googlegroups.com...
> This guy has the same problem, a deeper understanding but
> unfortunately, no answer so far:
> http://www.webservertalk.com/archive120-2006-3-1421404.html
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - -
> I wonder if anyone can clear up the confusion around the
> AuthPersistence
> metabase attribute and IIS 6. Currently if a site is defined to use
> integrated authentication under IIS 6 each request causes a 401
> challenge/response. Under previous versions this behavior could be
> optimised to only challenge on a session or possibly as long as the
> socket connection was kept open. This prevented constant 401s when
> returning a single page.
>
> The following link: http://technet2.microsoft.com/Windo...23abbc1033.mspx
>
> Suggests that the only valid value for AuthPeristence with IIS 6 is
> AuthPersistSingleRequest and that each request will generate a
> challenge. However under two conditions - Integrated Auth is set to
> NTLM
> or Integrated Auth is set to Negotiate and NTLM is used - this value
> will be false and the previous behavior will be supported for backward
> compatibility. Which I read as we can optimise the challenge response
> protocol if NTLM is used.
>
> Another version of the document above was provided with the IIS 6
> resource kit and this claims the behavior has been removed and the
> only
> supported value us AuthPersitSingleRequest.
>
> So can the 401 behavior for integrated authentication be optimised? Or
> are we stuck with 3 round trips for each server request with IIS 6?
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - -
 >> Stay informed about: Integrated Windows Authentication - Double Hits 

Marc,

I've searched on this subject a little more and found this link [1]
(see title "AuthPersistence Usage in IIS 6.0").

It seems this behavior, in IIS6 when using Kerberos for
Authentication, is by-design, until Microsoft says otherwise. From a
security stand-point it makes sense and I agree because Kerberos
authenticates the HTTP Request, differently from NTLM which
authenticated the TCP/IP connection.

However, there is a nasty side-effect to all this. The browser (tested
with IE7) is unable to make good use of its TCP/IP connections when
auth'ing with Kerberos. My tests show that IE makes a new TCP/IP
connection for every new HTTP request whenever it authenticates via
Negotiate.
So, for a page with X images protected via Negotiate/SPNEGO/Kerberos,
I opened TcpView.exe and saw something like this:
(open browser to the page and watch TcpView.exe)
1 new TCP/IP connection for HTML + X new TCP/IP connections for all X
images/scripts
(refresh and watch TcpView.exe)
1 new TCP/IP connection for HTML + X new TCP/IP connections for all X
images/scripts
(refresh and watch TcpView.exe)
1 new TCP/IP connection for HTML + X new TCP/IP connections for all X
images/scripts

In fact, I noticed that its the browser closing the connections with
FIN, gracefully, leaving the connections in TIME_WAIT. There is no
mention to Connection:Close or even HTTP/1.0.

The 401's you observe in your environment may very well be, I believe,
a side-effect of the browser behavior, because since the browser uses
a new TCP/IP connection to every single HTTP request, it always tries
to connect anonymously and will receive a 401.

[1] http://technet2.microsoft.com/windowsserver/en/library/35d4445b-5440-4...-80f3-c

Tiago Halm


On Mar 3, 10:37 pm, "Tiago Halm" <th....TakeThisOut@nospam.hotmail.com> wrote:
> Marc,
>
> This behavior is quite simple. Basically you have the option of establishing
> an authenticated TCP/IP session or to authenticate every single HTTP
> request.
>
> Why is IIS6, out of the box, forcing the HTTP requests to authenticate
> instead of attaching the authentication to the TCP/IP protocol? Because IIS6
> is secure by default and HTTP proxies may prove to be dangerous in security
> terms. HTTP is point-to-point differently from WS-* which is end-to-end.
>
> Imagine the following scenario:
> You (the browser) are connected to the next HOP, which may be a proxy. The
> proxy will be connected to the next HOP which may be the webserver. Another
> user (another browser) is also connected to the proxy (and implicitly to the
> webserver).
>
>     YOU [1A] => PROXY => [1B] WEBSERVER
>     OTHER [2A] => PROXY => [2B] WEBSERVER
>
> If the proxy does not behave, you may end up with this:
>     OTHER [2A] => PROXY => [1B] WEBSERVER
> which means the OTHER user would reach the WEBSERVER as you.
>
> As a final word, if you do not have a proxy between your users and the
> webserver (typical intranet scenario), then try setting the metabase
> property to false (you need to set it up, since there metabase properties
> which have their value to its default unless overridden in the metabase.xml)
> and check if the behavior is as expected.
>
> Tiago Halm
>
> "Marc J. Cawood" <cawo....TakeThisOut@gmail.com> wrote in messagenews:1f0650fa-2df5-4b83-94bb-e2ba1f981c0f@q33g2000hsh.googlegroups.com...
>
>
>
> > This guy has the same problem, a deeper understanding but
> > unfortunately, no answer so far:
> >http://www.webservertalk.com/archive120-2006-3-1421404.html
>
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - - - - - - - - - - - - -
> > I wonder if anyone can clear up the confusion around the
> > AuthPersistence
> > metabase attribute and IIS 6. Currently if a site is defined to use
> > integrated authentication under IIS 6 each request causes a401
> > challenge/response. Under previous versions this behavior could be
> > optimised to only challenge on a session or possibly as long as the
> > socket connection was kept open. This prevented constant 401s when
> > returning a single page.
>
> > The following link:http://technet2.microsoft.com/Windo...23abbc1033.mspx
>
> > Suggests that the only valid value for AuthPeristence with IIS 6 is
> > AuthPersistSingleRequest and that each request will generate a
> > challenge. However under two conditions - Integrated Auth is set to
> > NTLM
> > or Integrated Auth is set to Negotiate and NTLM is used - this value
> > will be false and the previous behavior will be supported for backward
> > compatibility. Which I read as we can optimise the challenge response
> > protocol if NTLM is used.
>
> > Another version of the document above was provided with the IIS 6
> > resource kit and this claims the behavior has been removed and the
> > only
> > supported value us AuthPersitSingleRequest.
>
> > So can the401behavior for integrated authentication be optimised? Or
> > are we stuck with 3 round trips for each server request with IIS 6?
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - - - - - - - - - - - - -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Integrated Windows Authentication - Double Hits