Re: Change in ASP.Net authentication between Win2000 and Win2003

From: Craig Banks (ban01_at_co.henrico.va.us)
Date: 04/04/05 

Date: Mon, 4 Apr 2005 17:17:11 -0400

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.

"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:OBP3SSzNFHA.2144@TK2MSFTNGP09.phx.gbl...
>> 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.
>
> 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?
>
>> 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.
>
> Are these users running browsers that automatically pre-authenticate to
> the
> web server with their user credentials over integrated windows
> authentication?
>
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> //
> "Craig Banks" <ban01@co.henrico.va.us> wrote in message
> news:%23LqRmFtNFHA.2880@TK2MSFTNGP10.phx.gbl...
> 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!
>
>
>
>

Relevant Pages

  • Re: Windows Authentication method on IIS6
    ... The microsoft.public.windows.server.* groups deal with Windows 2003 ... The microsoft.public.inetserver.* groups deal with IIS ... > the authentication button, ... You can configure either one or multiple realm names on a server running IIS ...
    (microsoft.public.win2000.security)
  • Re: How to access Windows IIS User Info with Perl
    ... but the IIS server is configured for Windows ... allowed for Basic Authentication, Windows Authentication (or whatever ... Do you know if they are part of a standard ...
    (comp.lang.perl.misc)
  • Windows Authentication with IIS on separate machines
    ... Yes, setting Basic Authentication in IIS works, but the ... >in SQL server but doesn't work if user account was ... >imported from a Windows account. ...
    (microsoft.public.sqlserver.security)
  • Re: Change in ASP.Net authentication between Win2000 and Win2003
    ... IIS Resource Guide). ... I next looked a little into Windows 2003. ... IMHO, the label on the option, "Enable Integrated Windows Authentication", ... the documentation leads one to ...
    (microsoft.public.windows.server.security)
  • Re: Change in ASP.Net authentication between Win2000 and Win2003
    ... > the spotty Microsoft online documentation explains why IIS 5 ... the documentation leads one to ... Windows authentication" is really not one particular authentication ...
    (microsoft.public.windows.server.security)