Hi.

I'm getting intermittent 401 errors in IIS 5.0 logs on a
W2K SP3 server. Consecutive GET methods, often within the
same minute and for what looks like the same user, return
HTTP 200 results (status ok), then there are intermittent
HTTP 401 results. Websites are using Windows Integrated
authentication (not Kerberos). When the GET method returns
401, the DOMAIN\user is replaced with "-". Then a
subsequent GET method works ok again (see below):

2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
80 GET /Common/css/main.css - 200 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

2004-01-12 07:25:05 111.1.111.1 - 222.2.222.2 80
GET /Common/scripts/LeftNavtree.js - 401 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
80 GET /Common/images/logo.gif - 200 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

I came across this when I noticed that "-" was far and
away the top authenticated user in the Sawmill site stats.
Websites are on intranet.

Thanks for any advice.

Martin

Re: Intermittent 401 results on GET method (IIS 5.0) by David

David
Tue Jan 13 23:30:39 CST 2004

I'm not certain there is any problem here

By design, authenticated websites are going to return 401 for
unauthorized -- that's what tells the browser to get authenticated. In
fact, since web browser default to anonymous authentication, for an
authenticated website, every user is guaranteed to generate at least one
401. And, since HTTP is stateless, it's not easy for a browser to "stay
authenticated" to a web server.

For example, Windows Integrated Authentication is bound to a connection, so
if the user is browsing pages on your webserver that constantly close the
connection, it's going to trigger a lot of re-authentication (thus 401).

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Martin Elliget" <melliget_jan2004@hotpop.com> wrote in message
news:040f01c3d9d7$522af990$a001280a@phx.gbl...
Hi.

I'm getting intermittent 401 errors in IIS 5.0 logs on a
W2K SP3 server. Consecutive GET methods, often within the
same minute and for what looks like the same user, return
HTTP 200 results (status ok), then there are intermittent
HTTP 401 results. Websites are using Windows Integrated
authentication (not Kerberos). When the GET method returns
401, the DOMAIN\user is replaced with "-". Then a
subsequent GET method works ok again (see below):

2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
80 GET /Common/css/main.css - 200 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

2004-01-12 07:25:05 111.1.111.1 - 222.2.222.2 80
GET /Common/scripts/LeftNavtree.js - 401 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
80 GET /Common/images/logo.gif - 200 Mozilla/4.0+
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
.NET+CLR+1.0.3705)

I came across this when I noticed that "-" was far and
away the top authenticated user in the Sawmill site stats.
Websites are on intranet.

Thanks for any advice.

Martin



Re: Intermittent 401 results on GET method (IIS 5.0) by Martin

Martin
Wed Jan 14 07:59:06 CST 2004

Thanks for your response, David.

What you say makes sense, though it doesn't quite gel with
what I'm seeing in the logs. Many times a user, within the
same minute (probably within a second or two),
successfully requests an asp page, for example, and some
associated files (scripts, gifs), then midway through the
sequence of GET statements, one or two fail (DOMAIN\user
has been replaced with "-"), and then a line or two (and
probably seconds) later, the same file is requested again
(with DOMAIN\user) and fetched successfully. I could
understand if it was mainly the first GET method for a
given user in a session but it doesn't generally seem to
be the case.

Just to give you an idea, the stats for one of our
intranet sites (for the last 12 months) show that HTTP 200
(successful) was the top server response with 1,261,953
page views and 87.14 GB bandwidth used, followed by HTTP
401 (unauthorized) with 1,174,896 page views and 6.26 GB
bandwidth. Totals for all responses were 2,744,493 page
views and 98.21 GB bandwidth, so HTTP 401 in this
particular case accounted for 43% of all page views and
over 6% of bandwidth. For several other sites, HTTP 401
tops the list of server responses (in terms of page
views). In one site, HTTP 401 tops the list in terms of
bandwidth (the percentages are 35% and 54% respectively).
These stats seem on the high side to me.

Would the security option "Enable Integrated Windows
Authentication" in IE6 reduce the number of HTTP 401
results? IE6 is available but not yet mandatory for our
clients, so the majority are probably still 5.5.

Thanks again.

Martin


>-----Original Message-----
>I'm not certain there is any problem here
>
>By design, authenticated websites are going to return 401
for
>unauthorized -- that's what tells the browser to get
authenticated. In
>fact, since web browser default to anonymous
authentication, for an
>authenticated website, every user is guaranteed to
generate at least one
>401. And, since HTTP is stateless, it's not easy for a
browser to "stay
>authenticated" to a web server.
>
>For example, Windows Integrated Authentication is bound
to a connection, so
>if the user is browsing pages on your webserver that
constantly close the
>connection, it's going to trigger a lot of re-
authentication (thus 401).
>
>--
>//David
>IIS
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>//
>"Martin Elliget" <melliget_jan2004@hotpop.com> wrote in
message
>news:040f01c3d9d7$522af990$a001280a@phx.gbl...
>Hi.
>
>I'm getting intermittent 401 errors in IIS 5.0 logs on a
>W2K SP3 server. Consecutive GET methods, often within the
>same minute and for what looks like the same user, return
>HTTP 200 results (status ok), then there are intermittent
>HTTP 401 results. Websites are using Windows Integrated
>authentication (not Kerberos). When the GET method returns
>401, the DOMAIN\user is replaced with "-". Then a
>subsequent GET method works ok again (see below):
>
>2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
>80 GET /Common/css/main.css - 200 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>2004-01-12 07:25:05 111.1.111.1 - 222.2.222.2 80
>GET /Common/scripts/LeftNavtree.js - 401 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
>80 GET /Common/images/logo.gif - 200 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>I came across this when I noticed that "-" was far and
>away the top authenticated user in the Sawmill site stats.
>Websites are on intranet.
>
>Thanks for any advice.
>
>Martin
>
>
>.
>

Re: Intermittent 401 results on GET method (IIS 5.0) by David

David
Thu Jan 15 00:56:36 CST 2004

I do not see anything particularly abnormal with your stats. What
information makes you think that 40% 401s on an authenticated website is
abnormal? HTTP is stateless, so it is not an easy task to "stay
authenticated" and not trigger 401s. Bad configuration on the client and
server can easily make 401s occupy at least 50% of all web server responses.

Browsers frequently make more than one simultaneous connection to a web
server to download content. Just because one connection is "authenticated"
does not mean the other connection(s)/request(s) are considered
authenticated (recall HTTP is stateless). Since the port # of the
connection is not recorded in the log file, you really don't know if the 10
requests you see from the client is over 1 connection or 10 connections.
Also, when it comes to Integrated Windows Authentication, user SESSION is
not as important as network CONNECTION when it comes to 401s.

i.e. If you have a web page with 5 unique pictures on it along with some
links:
1. If the browser only uses one connection, you should see 7 requests -- one
initial 401, one 200 for the web page, and 5 more 200s for the 5 unique
pictures
2. If the browser uses two connections, you can see a lot of variety (you
really need to do a network sniff to tell what's going on)
-- you can see 8 requests -- one initial 401 each on the two connections,
one 200 for the web page and 5 more 200s for the pictures, spread amongst
the two connections
-- If the browser uses two connections and HTTP Pipelining in a bad way, you
can see six 401 responses followed by six 200s over the two connections
(this is a client-side issue that is unavoidable by the server -- the client
sends first sends 6 anonymous HTTP requests one after another before
receiving the 401 responses [six of them], after which it figures out to
authenticate correctly, but the bandwidth damage is already done).

So, I've illustrated that to fetch a web page with five pictures, you can
expect at least 7-12 requests when authentication is enabled, and it's all
dependent on client-side behavior. The server cannot do anything about it.
The cost of 401s range from 15% to 50% depending on client behavior.

The QUANTITY of 401 response sent by the server depends on both client side
optimizations and server configuration. The best you can do on the server
is to make sure the server and the network between the server and client do
not defeat any client-side optimizations. For example, if your web server
only accepts Integrated Windows Authentication, it would be beneficial for
the Clients to use it by default, auto-login to the Intranet server whenever
possible, not force close any connections between the client and server by
using some proxy (which can force re-authentication by dropping the
connection), etc. Enabling KeepAlive is also essential for Integrated
Windows Authentication functionality. Not enabling multiple types of
authentication on a website can be useful to the client as well.

However, you can control the BANDWIDTH used by the 401 responses -- you can
reduce the size of the 401.x custom error pages that IIS sends. If you must
send 1 million pages, it's better to send a 40 byte page vs a 4,000 byte
page.

So, if you think that the number of 401s is high, just remember that you
CANNOT affect it by purely server and network configuration.

If you really want to analyze the cause of the 401s, get a network trace of
sample traffic and look at what's going on. The network trace will tell you
everything immediately and you don't need to guess with server
configuration -- it'll tell you what authentication is emplyed by the
browser, what connection it's over, how long the bytes took to be
transferred, where any re-authentication is occurring, etc -- and you can
use the info to tune configuration.

Authentication isn't cheap. HTTP being a stateless protocol does not help
keep authentication cheap yet secure, either.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Martin Elliget" <melliget_jan2004@hotpop.com> wrote in message
news:0c6f01c3daa6$92fb60c0$a301280a@phx.gbl...
Thanks for your response, David.

What you say makes sense, though it doesn't quite gel with
what I'm seeing in the logs. Many times a user, within the
same minute (probably within a second or two),
successfully requests an asp page, for example, and some
associated files (scripts, gifs), then midway through the
sequence of GET statements, one or two fail (DOMAIN\user
has been replaced with "-"), and then a line or two (and
probably seconds) later, the same file is requested again
(with DOMAIN\user) and fetched successfully. I could
understand if it was mainly the first GET method for a
given user in a session but it doesn't generally seem to
be the case.

Just to give you an idea, the stats for one of our
intranet sites (for the last 12 months) show that HTTP 200
(successful) was the top server response with 1,261,953
page views and 87.14 GB bandwidth used, followed by HTTP
401 (unauthorized) with 1,174,896 page views and 6.26 GB
bandwidth. Totals for all responses were 2,744,493 page
views and 98.21 GB bandwidth, so HTTP 401 in this
particular case accounted for 43% of all page views and
over 6% of bandwidth. For several other sites, HTTP 401
tops the list of server responses (in terms of page
views). In one site, HTTP 401 tops the list in terms of
bandwidth (the percentages are 35% and 54% respectively).
These stats seem on the high side to me.

Would the security option "Enable Integrated Windows
Authentication" in IE6 reduce the number of HTTP 401
results? IE6 is available but not yet mandatory for our
clients, so the majority are probably still 5.5.

Thanks again.

Martin


>-----Original Message-----
>I'm not certain there is any problem here
>
>By design, authenticated websites are going to return 401
for
>unauthorized -- that's what tells the browser to get
authenticated. In
>fact, since web browser default to anonymous
authentication, for an
>authenticated website, every user is guaranteed to
generate at least one
>401. And, since HTTP is stateless, it's not easy for a
browser to "stay
>authenticated" to a web server.
>
>For example, Windows Integrated Authentication is bound
to a connection, so
>if the user is browsing pages on your webserver that
constantly close the
>connection, it's going to trigger a lot of re-
authentication (thus 401).
>
>--
>//David
>IIS
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>//
>"Martin Elliget" <melliget_jan2004@hotpop.com> wrote in
message
>news:040f01c3d9d7$522af990$a001280a@phx.gbl...
>Hi.
>
>I'm getting intermittent 401 errors in IIS 5.0 logs on a
>W2K SP3 server. Consecutive GET methods, often within the
>same minute and for what looks like the same user, return
>HTTP 200 results (status ok), then there are intermittent
>HTTP 401 results. Websites are using Windows Integrated
>authentication (not Kerberos). When the GET method returns
>401, the DOMAIN\user is replaced with "-". Then a
>subsequent GET method works ok again (see below):
>
>2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
>80 GET /Common/css/main.css - 200 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>2004-01-12 07:25:05 111.1.111.1 - 222.2.222.2 80
>GET /Common/scripts/LeftNavtree.js - 401 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>2004-01-12 07:25:05 111.1.111.1 DOMAIN\jsmith 222.2.222.2
>80 GET /Common/images/logo.gif - 200 Mozilla/4.0+
>
(compatible;+MSIE+5.5;+Windows+NT+5.0;+BCIE55SP1;+H010818;+
>..NET+CLR+1.0.3705)
>
>I came across this when I noticed that "-" was far and
>away the top authenticated user in the Sawmill site stats.
>Websites are on intranet.
>
>Thanks for any advice.
>
>Martin
>
>
>.
>



Re: Intermittent 401 results on GET method (IIS 5.0) by Martin

Martin
Thu Jan 15 17:42:03 CST 2004

David.

Thanks for your detailed and thorough response, and the helpful
suggestions - I appreciate it.

regards,

Martin


On Wed, 14 Jan 2004 22:56:36 -0800, "David Wang [Msft]"
<someone@online.microsoft.com> wrote:

>I do not see anything particularly abnormal with your stats. What
>information makes you think that 40% 401s on an authenticated website is
>abnormal? HTTP is stateless, so it is not an easy task to "stay
>authenticated" and not trigger 401s. Bad configuration on the client and
>server can easily make 401s occupy at least 50% of all web server responses.
>
>Browsers frequently make more than one simultaneous connection to a web
>server to download content. Just because one connection is "authenticated"
>does not mean the other connection(s)/request(s) are considered
>authenticated (recall HTTP is stateless). Since the port # of the
>connection is not recorded in the log file, you really don't know if the 10
>requests you see from the client is over 1 connection or 10 connections.
>Also, when it comes to Integrated Windows Authentication, user SESSION is
>not as important as network CONNECTION when it comes to 401s.
>
>i.e. If you have a web page with 5 unique pictures on it along with some
>links:
>1. If the browser only uses one connection, you should see 7 requests -- one
>initial 401, one 200 for the web page, and 5 more 200s for the 5 unique
>pictures
>2. If the browser uses two connections, you can see a lot of variety (you
>really need to do a network sniff to tell what's going on)
>-- you can see 8 requests -- one initial 401 each on the two connections,
>one 200 for the web page and 5 more 200s for the pictures, spread amongst
>the two connections
>-- If the browser uses two connections and HTTP Pipelining in a bad way, you
>can see six 401 responses followed by six 200s over the two connections
>(this is a client-side issue that is unavoidable by the server -- the client
>sends first sends 6 anonymous HTTP requests one after another before
>receiving the 401 responses [six of them], after which it figures out to
>authenticate correctly, but the bandwidth damage is already done).
>
>So, I've illustrated that to fetch a web page with five pictures, you can
>expect at least 7-12 requests when authentication is enabled, and it's all
>dependent on client-side behavior. The server cannot do anything about it.
>The cost of 401s range from 15% to 50% depending on client behavior.
>
>The QUANTITY of 401 response sent by the server depends on both client side
>optimizations and server configuration. The best you can do on the server
>is to make sure the server and the network between the server and client do
>not defeat any client-side optimizations. For example, if your web server
>only accepts Integrated Windows Authentication, it would be beneficial for
>the Clients to use it by default, auto-login to the Intranet server whenever
>possible, not force close any connections between the client and server by
>using some proxy (which can force re-authentication by dropping the
>connection), etc. Enabling KeepAlive is also essential for Integrated
>Windows Authentication functionality. Not enabling multiple types of
>authentication on a website can be useful to the client as well.
>
>However, you can control the BANDWIDTH used by the 401 responses -- you can
>reduce the size of the 401.x custom error pages that IIS sends. If you must
>send 1 million pages, it's better to send a 40 byte page vs a 4,000 byte
>page.
>
>So, if you think that the number of 401s is high, just remember that you
>CANNOT affect it by purely server and network configuration.
>
>If you really want to analyze the cause of the 401s, get a network trace of
>sample traffic and look at what's going on. The network trace will tell you
>everything immediately and you don't need to guess with server
>configuration -- it'll tell you what authentication is emplyed by the
>browser, what connection it's over, how long the bytes took to be
>transferred, where any re-authentication is occurring, etc -- and you can
>use the info to tune configuration.
>
>Authentication isn't cheap. HTTP being a stateless protocol does not help
>keep authentication cheap yet secure, either.