I understand that, as you have stated, using the IP works but not the 'DNS' name, or FDQN as I like to call it.
The difference in the process or 'routing' of the request to authenticate is the issue as you have stated it.
Let's examine the differences: The XP VM is logged in to the domain, and therefore has a certificate at the ready, and it knows the user's fully-qualified name and password. Hence the automatic or 'pass-through' login.
How do we simulate this on the server?
When you log in from the server, using the built-in IE, you are using the administrator's (or an admin-type) for credentials.
To the IIS this looks like
[email protected]sion OR NETBIOSNAME/username OR username.domain.extension OR username@NETBIOSNAME, OR CN=administrator, OU=etc , OU=etc, etc.
This leaves a lot of iterations to find the proper login for a user.
HOWEVER: when you use the IP, the IE doesn't forward the Windows credentials. IT BLANKS OUT THOSE FIELDS.
The most likely failure is that the server is appending the domain to an already existing domain name; like this: username.domain.com.domain
.com
This user doesn't exist, and can't login. Nevermind that you just typed in username or username.domain.com
Since you state that the XP and the clustered servers all point to the exact same DNS, then the problem must lie in one of three places:
1. The IE
2. The domain settings in the NIC interface are somehow different than the XP unit. Look at the DNS settings and compare the XP VM with the server. Look at the domain settings.
3. The IIS -- this could be an issue with the credentials required and the forms as well as the virtual directory.
There should be an error in the event viewer when the login fails. It will tell you which issue you're facing, at least in the sense that it will identify wrong name or password (remember, it doesn't matter that you put it in right, it matters that it agrees with the format IIS wants it and that format is altered when you are on the local machine), or something like 'requires SSH' or something.
My guess is: The servers are adding domain tags or something when you login directly from them. If you use a FQDN, the DNS provides the IP, the SRV records etc. etc. This information is being auto-added to the credentials you type in. This exact problem happens on non-clustered Exchange if you log in to the server as local admin (when the Exchange server is not a DC). The local admin's name is followed by the machine name (admin.termserver1) and then when you try to use OWA, your name comes out like administrator.domain.exten
sion@terms
erver1
It fails. Use the IP, and it accepts the typed in creds.
