When I configure my app for integrated windows security, users are
always challenged by a Windows "Connect to <ServerName>" pop-up, even
though they are already logged into the domain. Furthermore, if they
re-type their credentials, they are still denied access.

Obviously, I would like to authenticate AD users without an additional
login step. Is there a FAQ on this anywhere? Or, a good book?

This seems like a common approach, but I am having very fundamental
difficulty.

Any advice is greatly appreciated.

This is often caused by browser settings. IE may not have integrated auth
enabled in general and it may also be the case that IE is set to only do
automatic login to sites in the Intranet zone, which your site may not be
mapping to.

Check the IE settings for the computers that are having trouble and see if
you can see if any of these issues apply.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
[quoted text, click to view]

Under Tools | Internet Options | Security | Intranet Zone | Custom Level,
what are the settings for "Logon" (all the way at the bottom of the tree).
Is it set to auto logon or prompt for credentials or what?

Thanks for the comments on the book. It won't help you with this one
though. :)

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
[quoted text, click to view]

[quoted text, click to view]

Thanks!!

Checking a few sample computers, this appears to be OK..

* Under Tools/Internet Options/Advanced
Enable Integrated Windows Authentication is checked

* The site shows up "Local Intranet" when they browse to it

Good looking book by the way. 6 months ago, I though
IIS/ASP.NET/ActiveDirectory was going to be a 2-3 week stint.. now I'm

[quoted text, click to view]

So, if all the ducks are in a row (so to speak) and the logon is actually
being attempted by the browser before it challenges the user, then there
should be a failure audit available on the web server (assuming you have
logon audits enabled in your security policy, which you always should) that
explains more details about the failure. If it were me troubleshooting
this, I would definitely look there for info. There may also be interesting
security-related errors in the System event log.

I would also use a tool like Fiddler or IEHttpHeaders to look at the actual
browser traffic paying special attention to the headers and the
request/response pattern to try to determine what is going on. HTTP auth
works based on the Authorization request header and the WWW-Authenticate
response header. The different protocols (Basic, Negotiate, NTLM, Digest)
all use those headers to implement the proper conversation between client
and server that supports the protocol being used. You should be using
Negotiate auth. The trick with his stuff is that until you know what you
are looking at, it is hard to figure out what it is that you are seeing and
tell the various things apart, especially things like the difference between
Kerberos auth and NTLM auth when Negotiate is used.

I might also try the tool wfetch.exe from the IIS 6 resource kit to request
a resource on the site with Negotiate auth to see what it does. It
sometimes provides really useful low level errors.

Good luck troubleshooting this. It can be painful once you start to have to
peel back the covers and understand the details. :(

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
[quoted text, click to view]