We are in the process of migrating an intranet web server from a Windows
2000 box to a Windows 2003 box. In migrating OSs and from IIS 5 to IIS 6,
we've noticed a significant difference in how Windows integrated security
works with our ASP.Net web pages.

For our web sites where directory security is set to integrated windows
authentication, users already authenticated to our network are often
challenged with a logon screen when trying to access ASP.Net web pages. To
make a very long story short, we've discovered the work-around is to uncheck
"Enable Integrated Window Authentication" under IE 6's advanced internet
options (checked on by default with XP). Contrary to what the label on this
checkbox option implies, unchecking it still passes authentication
credentials from the client to the server and everyone's happy. In the old
Windows 2000/IIS 5 world, checking or unchecking this box makes no
difference.

In researching this, I've followed a wandering path of Kerberos versus
challenge/response authentication. However, nothing in the spotty Microsoft
online documentation explains why IIS 5 running on Windows 2000 behaves
differently than IIS 6 on Windows 2003. In fact, the documentation leads one
to believe they should behave identically.

One further issue. When logged onto the Windows 2003 server, if I log onto
an ASP.Net page with IE 6 using "localhost" in the address everything's
fine. However, if I use the DNS name (e.g.
http://myservername/myaspdotnetpage.aspx) I'll get the login prompt. In this
case, checking or unchecking the "Enable Integrated Window Authentication"
option makes no difference. On our Windows 2000/IIS 5 box there is no
challenge for a logon.

What gives? Thanks in advance for your help!

I'd like to understand what you find spotty about the online documentation
for the issue -- because we do take documentation seriously. I am frustrated
by the fact that it is not easy for customers to report issues with
documentation clarity because it just artificially raises support costs and
decrease customer self-help.

The reason why there is no documentation explaining why IIS5 behaves
differently than IIS6 on this issue is because it is supposed to behave
identically.

I think the biggest thing that is "unspoken" is the fact that "integrated
Windows authentication" is really not one particular authentication
mechanism (like Basic) but rather a family of different authentication
protocols, negotiable by the client, and each protocol has differences in
terms of security attributes and behavior. These differences frequently
surface as extra login dialog boxes or failure, depending on configuration
that is for the most part beyond IIS -- hence, you will likely never find an
IIS document describing the differences because from the IIS perspective, we
just call into a Windows function with a security blob, and it eventually
says success/failure and IIS returns 200/401 accordingly. The external
perception is that it automagically works, but sometimes it can fail and
then it is not clear why.

We realize that it is hard to link all the documentation of all the
interacting parts, so we have created a tool, AuthDiag, which tries to
diagnose some of thes authentication failures and provide more runtime
information.
http://www.microsoft.com/downloads/details.aspx?FamilyId=E90FE777-4A21-4066-BD22-B931F7572E9A&displaylang=en

What it looks like is that you told IE to not use Kerberos, and then the
issues cleared up. That usually suggests that maybe Kerberos wasn't
configured/working to begin with; you just never noticed it until your
webserver started using it. Were the IIS5 and IIS6 machines standalone or a
part of a domain?

Are these users running browsers that automatically pre-authenticate to the
web server with their user credentials over integrated windows
authentication?


We are in the process of migrating an intranet web server from a Windows
2000 box to a Windows 2003 box. In migrating OSs and from IIS 5 to IIS 6,
we've noticed a significant difference in how Windows integrated security
works with our ASP.Net web pages.

For our web sites where directory security is set to integrated windows
authentication, users already authenticated to our network are often
challenged with a logon screen when trying to access ASP.Net web pages. To
make a very long story short, we've discovered the work-around is to uncheck
"Enable Integrated Window Authentication" under IE 6's advanced internet
options (checked on by default with XP). Contrary to what the label on this
checkbox option implies, unchecking it still passes authentication
credentials from the client to the server and everyone's happy. In the old
Windows 2000/IIS 5 world, checking or unchecking this box makes no
difference.

In researching this, I've followed a wandering path of Kerberos versus
challenge/response authentication. However, nothing in the spotty Microsoft
online documentation explains why IIS 5 running on Windows 2000 behaves
differently than IIS 6 on Windows 2003. In fact, the documentation leads one
to believe they should behave identically.

One further issue. When logged onto the Windows 2003 server, if I log onto
an ASP.Net page with IE 6 using "localhost" in the address everything's
fine. However, if I use the DNS name (e.g.
http://myservername/myaspdotnetpage.aspx) I'll get the login prompt. In this
case, checking or unchecking the "Enable Integrated Window Authentication"
option makes no difference. On our Windows 2000/IIS 5 box there is no
challenge for a logon.

What gives? Thanks in advance for your help!

First of all, I'd like to thank you for responding to my post in detail.

I hope "spotty" is the right word. Ideally, there'd be some holistic
troubleshooting guide for this situation, not just separate online help
topic for various features of each products (though I did find the weighty
IIS Resource Guide). I was forced to guess which product was the culprit.
IIS 6 was the likeliest since the problem was authenticating to a web site
and we'd upgraded from IIS 5 when we migrated to Windows 2003. Lacking any
direct tie-in to a particular document dealing with my problem, I ended up
boning up on the general IIS authentication model where I learned about
Kerberos versus challenge/response. But none of this background helped me
really understand the problem because our system engineers assure me we've
never used Kerberos. I next looked a little into Windows 2003.

Finally, after much time was wasted, I got desperate and toyed with IE
settings. When, by trial and error, I found changing a setting was a
work-around, I couldn't find any information on what that setting does.
IMHO, the label on the option, "Enable Integrated Windows Authentication",
is misleading if all that's really happening is turning on/off Kerberos is
occuring.

I've downloaded the AuthDiag tool. Thanks for the tip. I missed it in my
research.

Regarding your other questions, the web servers I speak of are on the domain
and part of or intranet. Users authenticate to the network when they log
onto the network then we turn on Windows authentication inside of IIS so we
can check their credentials when they try to access web pages.

Thanks again for the help.


Show quoteHide quote

It control how IE deals with "Authentication: Negotiate", which as I said
earlier, controls a whole family of authentication protocols of which NTLM
and Kerberos are included. So, it cannot just say "turn on/off Kerberos" nor
"turn on/off NTLM/Kerberos" because that list can grow.

Now, I'm not an IE expert, but I believe IE deals with "Authentication:
NTLM" natively (it did so even before the availability of this option). So,
this switch essentially turns on/off Kerberos at this point in time.  Now,
when you put IIS6 in a domain and have "Integrated Windows Authentication"
enabled, it is going to favor Kerberos before NTLM as a part of the
negotiation (unless you reconfigure it)... so when you had IE allow
"Negotiate" but didn't have Kerberos working -- things fail. By turning it
off, IE goes the NTLM compatibility route.

IIS5 actually has the same configured behavior by default, unless you've
configured it differently.

In any case, I think you are seeing some issues on the client-side masked by
server-side configuration that was not exactly apples-to-apples.

I actually do not think this is a waste of time. Security concepts are not
that obvious for many people, and some security concepts are hard to
integrate into everyday use because they are quite counter-intuitive
(especially if you want to stay secure). Computers are great at following
the rules for being secure, but people are notoriously bad at obeying those
rules and get access-denied all the time -- and computers aren't yet smart
enough to tell humans *why* they are getting denied.  Another topic that is
worth spending time on is delegation -- and that is when you will want to
use Kerberos. Because any other solution is basically either insecure
delegation that is prone to attacks (you just haven't noticed them yet --
for example, all the forms/cookie auth or basic over SSL stuff), or you must
spend additional time/money on a custom implementation and securing it when
Kerberos is already an open spec and proven.


Regarding documentation:

I agree with your sentiments.

However, realize that "product documentation" is not holistic
"troubleshooting guide".  The former talks about how the product works, the
latter is from real-life combinations of various products and their
interactions. I think the latter is nearly impossible for Microsoft (or
anyone) to cover in the correct detail and topics. Software is generally too
creative and interacting in combinations.

I honestly think that Microsoft should not be tasked to produce the
troubleshooting guide. Instead, Microsoft should provide a central website
as well as some technical resources to help grow the community of users to
produce their own experiences into a holistic troubleshooting guide. This
way, we get a living guide that documents the common things customers
actually perform (vs product documentation where we have to give all
options, regardless of whether it matters to that user/scenario), backed by
customer experience and Microsoft technical resources.

Of course, this sort of self-help concept has to be reconciled with
Microsoft Product Support, but I think they can both co-exist quite nicely.

First of all, I'd like to thank you for responding to my post in detail.

I hope "spotty" is the right word. Ideally, there'd be some holistic
troubleshooting guide for this situation, not just separate online help
topic for various features of each products (though I did find the weighty
IIS Resource Guide). I was forced to guess which product was the culprit.
IIS 6 was the likeliest since the problem was authenticating to a web site
and we'd upgraded from IIS 5 when we migrated to Windows 2003. Lacking any
direct tie-in to a particular document dealing with my problem, I ended up
boning up on the general IIS authentication model where I learned about
Kerberos versus challenge/response. But none of this background helped me
really understand the problem because our system engineers assure me we've
never used Kerberos. I next looked a little into Windows 2003.

Finally, after much time was wasted, I got desperate and toyed with IE
settings. When, by trial and error, I found changing a setting was a
work-around, I couldn't find any information on what that setting does.
IMHO, the label on the option, "Enable Integrated Windows Authentication",
is misleading if all that's really happening is turning on/off Kerberos is
occuring.

I've downloaded the AuthDiag tool. Thanks for the tip. I missed it in my
research.

Regarding your other questions, the web servers I speak of are on the domain
and part of or intranet. Users authenticate to the network when they log
onto the network then we turn on Windows authentication inside of IIS so we
can check their credentials when they try to access web pages.

Thanks again for the help.


Show quoteHide quotehttp://www.microsoft.com/downloads/details.aspx?FamilyId=E90FE777-4A21-4066-BD22-B931F7572E9A&displaylang=en
Show quoteHide quote

I would suspect that this behaviour occurs because "localhost" is (by
default) in IE's Intranet security zone, and a fully qualified DNS name
isn't (e.g. myservname.com). Adding myservername.com into IE's Intranet
security zone should enable Auto-Logon. See:
http://support.microsoft.com/?id=258063
for more information

Checking/unchecking "Enable Integrated Windows Authentication"
enables/disables Kerberos support. As David has suggested, if toggling that
switch changes behaviour, then perhaps Kerberos is not configured correctly
(or similar)

Have you tried using AuthDiag to troubleshoot this issue?

Cheers
Ken