Integrated Windows authentication fails sporadically IE7 clients

[jonmundsack]

I have an intranet site on my LAN which has "anonymous access" turned
OFF, and "integrated Windows authentication" turned on. This allows
me to access the "AUTH_USER" server variable, which I use to look up
application rights in SQL Server. With IE6 clients, this has worked
flawlessly for several years.

Our users are currently running IE6, but my parent agency has
announced an upgrade to IE7 beginning next month, so I have installed
IE7 on a couple machines for testing. What I have observed is that
the AUTH_USER variable is sporadically not available to ASP, when
connecting from the IE7 client. This has the effect of prompting the
user for Windows authentication when they attempt to open any page on
my site. I desperately want to avoid this.

Does anyone know a) why IE7 results in the AUTH_USER variable
sporadically not being available to ASP, and b) if there is anything I
can configure on either client or server that will shore up this flaw?

[Anthony Jones]

<jo*********@yahoo.comwrote in message
news:7b**********************************@a70g2000 hsh.googlegroups.com...

I have an intranet site on my LAN which has "anonymous access" turned
OFF, and "integrated Windows authentication" turned on. This allows
me to access the "AUTH_USER" server variable, which I use to look up
application rights in SQL Server. With IE6 clients, this has worked
flawlessly for several years.

Our users are currently running IE6, but my parent agency has
announced an upgrade to IE7 beginning next month, so I have installed
IE7 on a couple machines for testing. What I have observed is that
the AUTH_USER variable is sporadically not available to ASP, when
connecting from the IE7 client. This has the effect of prompting the
user for Windows authentication when they attempt to open any page on
my site. I desperately want to avoid this.

Does anyone know a) why IE7 results in the AUTH_USER variable
sporadically not being available to ASP,

No. With windows intergated authentication being the only means to
authenticated the connection must have an AUTH_USER associated with it
before ASP script can begin execution. I can't see how the client of any
description can affect that.

>and b) if there is anything I
can configure on either client or server that will shore up this flaw?

The most likely explanation is that the browser does not recognise the site
as being in the intranet zone. Only the intranet zone will by default use
the current users credentials to authenticate a connection. If the site is
accessed as if it were in the Internet zone the user will see a windows
network logon dialog.

--
Anthony Jones - MVP ASP/ASP.NET

[jonmundsack]

On Jul 8, 5:22 pm, "Anthony Jones" <[e-mail]:

Does anyone know a) why IE7 results in the AUTH_USER variable
sporadically not being available to ASP,

I can't see how the client of any
description can affect that.

Well the IE client is definitely the only difference for this
particular situation. IE6 = AUTH_USER present, IE7 = AUTH_USER not
(always) present.

BUT....!

b) if there is anything I
can configure on either client or server that will shore up this flaw?

The most likely explanation is that the browser does not recognise the site
as being in the intranet zone. Only the intranet zone will by default use
the current users credentials to authenticate a connection. If the site is
accessed as if it were in the Internet zone the user will see a windows
network logon dialog.

Now you're on to something. I started looking through Internet
options as they pertain to security in the Intranet zone and came
across a setting in the "Custom Level" section for the Intranet zone
called, "User Authentication" "Logon". This setting has four
selections:

( ) Anonymous logon
(*) Automatic logon only in Intranet zone
( ) Automatic logon with current user name and password
( ) Prompt for user name and password

This setting on our IE6 machines is "Automatic logon only in Intranet
zone"; it is the same setting on our IE7 machines. HOWEVER -- if I
switch the setting to "Automatic logon with current user name and
password" on my IE7 machines, suddenly the problem goes away: I am no
longer prompted for authentication. This means that -- between IE6
and IE7 -- Microsoft evidently made SOME changes to how that
particular option is being handled.

Side note: I have also -- now that you've called my attention to the
zones issue -- did a little more testing and found that the problem
occurs under the following scenario on the IE7 machines (when the
setting is "Automatic logon only in Intranet zone"):

1. user is currently on an IntERnet site
2. user clicks a web shortcut on their desktop or a URL in an email,
that points to our IntRAnet site

Apparently, under these conditions, IE7 hasn't yet "left" the IntERnet
zone before it begins to authenticate on the IntRAnet site? (Just a
wild guess), and therefore doesn't "see" the IntRAnet site as being in
the IntRAnet zone, so it prompts for authentication. If the user does
not have IE open at all, and just clicks the shortcut or link, the
site opens without prompting for authentication.

So, I have a work-around (change the setting to "Automatic logon with
current user name and password"), but either IE6 was wrong and they
fixed it in IE7, or IE6 was right and they broke it in IE7 -- either
way, Microsoft changed something which critically changed the behavior
of this automatic logon in the Intranet zone setting.

Frustrating.

[=?Utf-8?B?Sm9uIE11bmRzYWNr?=]

"jo*********@yahoo.com" wrote:

So, I have a work-around (change the setting to "Automatic logon with
current user name and password")

Scratch that. Now I'm testing again (to show my colleague what I'm talking
about) and now it's prompting me no matter what my setting is. I can no
longer state with any certainty what causes this prompt to occur or not occur.

So, the question remains: why does this happen with IE7, when it did not
happen with IE6? I understand that AUTH_USER is a server variable and it's
controlled by a user's Windows logon, but somehow, it is being affected by
something that changed between IE6 and IE7.

Any other ideas?

[Anthony Jones]

"Jon Mundsack" <Jon Mu******@discussions.microsoft.comwrote in message
news:80**********************************@microsof t.com...

"jo*********@yahoo.com" wrote:

So, I have a work-around (change the setting to "Automatic logon with
current user name and password")

Scratch that. Now I'm testing again (to show my colleague what I'm

talking

about) and now it's prompting me no matter what my setting is. I can no
longer state with any certainty what causes this prompt to occur or not

occur.

>
So, the question remains: why does this happen with IE7, when it did not
happen with IE6? I understand that AUTH_USER is a server variable and

it's

controlled by a user's Windows logon, but somehow, it is being affected by
something that changed between IE6 and IE7.

Any other ideas?

Is the server name in the URLs being used fully qualified with the domain or
is just the host name?

Are you relying on IE to infer that the host is on the intranet?

Personally I would use a fully qualified servername and add that server
address to the intranet site list in IE. I use this approach a lot whilst
using integrated security.

--
Anthony Jones - MVP ASP/ASP.NET

[=?Utf-8?B?Sm9uIE11bmRzYWNr?=]

"Anthony Jones" wrote:

Is the server name in the URLs being used fully qualified with the domain or
is just the host name?

Are you relying on IE to infer that the host is on the intranet?

Personally I would use a fully qualified servername and add that server
address to the intranet site list in IE. I use this approach a lot whilst
using integrated security.

I am not familiar with how to add the domain to a URL. If my URL is:

http://appmonroe2o6ab/ssg/

How would I format this to include the domain?

Unfortunately I can't "add that server address to the intranet site list in
IE" because I work for a County government and my network is owned by the
State, and the State has apparently disabled the intranet site property page
through policies (everything is grayed out). But maybe adding the domain to
the URL will resolve this. Please let me know. And thanks for all your help!

[=?Utf-8?B?Sm9uIE11bmRzYWNr?=]

"Anthony Jones" wrote:

Personally I would use a fully qualified servername and add that server
address to the intranet site list in IE. I use this approach a lot whilst
using integrated security.

Hmm, now this is interesting.

Our intranet server is appmonroe2o6ab. There is a fully-qualified version
of this called appmonroe2o6ab.co.monroe.nyenet. When I click a link with
just the server name, it works. When I click a link for the fully-qualified
domain, it prompts for authentication.

What does that reveal? Does that mean that my proxy server is not properly
recognizing appmonroe2o6ab.co.monroe.nyenet as being on our local intranet?

[Anthony Jones]

"Jon Mundsack" <Jo*********@discussions.microsoft.comwrote in message
news:38**********************************@microsof t.com...

"Anthony Jones" wrote:

Personally I would use a fully qualified servername and add that server
address to the intranet site list in IE. I use this approach a lot

whilst

using integrated security.

Hmm, now this is interesting.

Our intranet server is appmonroe2o6ab. There is a fully-qualified version
of this called appmonroe2o6ab.co.monroe.nyenet. When I click a link with
just the server name, it works. When I click a link for the

fully-qualified

domain, it prompts for authentication.

What does that reveal? Does that mean that my proxy server is not

properly

recognizing appmonroe2o6ab.co.monroe.nyenet as being on our local

intranet?

>

The zone choice is made by IE based on the URL without reference to the
finally resolved IP address. Typically IE assumes a lone server name must
be in the intranet since where as a fully qualified name isn't.

However such settings can be overriden.

Do you have a proxy server between the client IE and the server? If so that
opens a much larger can of worms.
--
Anthony Jones - MVP ASP/ASP.NET

[Anthony Jones]

"Jon Mundsack" <Jon Mu******@discussions.microsoft.comwrote in message
news:F0**********************************@microsof t.com...

"Anthony Jones" wrote:

Is the server name in the URLs being used fully qualified with the

domain or

is just the host name?

Are you relying on IE to infer that the host is on the intranet?

Personally I would use a fully qualified servername and add that server
address to the intranet site list in IE. I use this approach a lot

whilst

using integrated security.

I am not familiar with how to add the domain to a URL. If my URL is:

http://appmonroe2o6ab/ssg/

How would I format this to include the domain?

Unfortunately I can't "add that server address to the intranet site list

in

IE" because I work for a County government and my network is owned by the
State, and the State has apparently disabled the intranet site property

page

through policies (everything is grayed out). But maybe adding the domain

to

the URL will resolve this. Please let me know. And thanks for all your

help!

>

You won't be able to add sites to the zone if they have locked it down.

--
Anthony Jones - MVP ASP/ASP.NET