Link to home
Create AccountLog in
Avatar of naydencho
naydencho

asked on

User gets challenged (randomly) with username/password dialog when hitting an IIS Intranet site

Hello all!
I have this issue that has been surfacing on and off for the last 6 months or so. It has been seemingly random so far, but during the different occurances I have been able to at least gather some common symptoms...

Here is the environment:
Servers:
IIS 5.0 is running on 2 node Active-Passive Windows 2000 Advanced Server cluster (both with identical HW configs - Ultra320 15K rpm SCSI drives, 2 GB RAM, quad 2.8 GHz CPUs, 10/100 NICs) The two boxes (ServerA and ServerB) have a common cluster IP and name that is used by clients to hit the web site hosted on IIS. At least 2 Cisco switches are between the servers and the clients at the time of the request. The site being accessed is configured with Windows Integrated authentication.

Clients:
The users access the site from 3 Windows Server 2003 Terminal Services servers - they are logged on to the servers and use IE 6 to hit the cluster site (as described above).

The issue:
At random times different users would try to get to the site on the clustered IIS servers but would get challenged with a username/pass box. The box shows up with this information already populated:

Connecting to clustername.domain.net...
User: clustername.domain.net\JohnSmith

Note, the user is logged on to the Terminal Server session with ID 'JohnSmith' belonging to the 'domain.net' - the same domain that the IIS servers and the Terminal Server belong to.
If they correct the information from 'clustername.domain.net\JohnSmith' to 'domain\JohnSmith' and enter their password they can get in.
If they hit each server by name, for example http://ServerA or http://ServerB they do not get the challenge.
If they logon to a different Terminal Server (as I mentioned they use 3 TSs, and get placed on each via round robin) they do not get the challenge either.
Restarting IIS does not fix the issue either.
Adding the site that challenges them to IE's Trusted Sites does not fix the issue
Sometimes deleting this user registry key seems to resolve the issue:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

unfortunately this does not ALWAYS help.


I will add more information if you ask/need to find out more about particular settings.

Thanks in advance!

Nay
ASKER CERTIFIED SOLUTION
Avatar of rob_AXSNL
rob_AXSNL
Flag of Netherlands image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Avatar of naydencho
naydencho

ASKER

The PDC emulator is in a different site, over a WAN link. In my site, where the IIS server and clients are I have 2 DCs, both with DNS, plus a another stand-alone DNS/WINS box. In WINS I have 2 dynamic mappings for the "clustername" - no "clustername.domain.net". I have not seen any other oddities that would relate to DNS resolution issues...

Nevertheless... I thought about what you said about name resolution and I tried a couple of things - ipconfig /flushdns does not help, HOWEVER adding the IP/name of the cluster to the HOST file of the Terminal Server that the user is having a problem on seems to fix it, at least for now...

If this is really the issue, can you explain to me what I am missing here? It only happens every once in a blue moon (which is fine for a DNS reolution issue), but it only affects one Terminal Server at a time AND only one of 20-30 users on that TS. Wouldn't it make sense to afect everyone on that box?

Nay
I don't really know what is causing the problem, that would require investigation.
Guess the cluster is not the domain controller.
As the cluster have more network names, think that you have to start there. Apparently, WINS is working correctly, but DNS is having problems. This could explain why it is sometimes working, but sometimes not. Caching etc...
What did you put in the hosts file
ip - clustername
or
ip - clustername.domain.net
This should give you some clue...
ip - clustername, since that is how they access it (not by the FQDN)...

Thanks for your help!

Nay