Integrated Windows Authentication

Question

We're experiencing some really strange problems with Integrated Windows Authentication with IIS and I'm not sure if I can see a pattern or not.

We have a DNS-Cname record called Fred. We have an IIS website with Fred set as the host header. When I connect to this site I get prompted with a credential challenge. I would expect my credentials to have been passed through. If I enter my credentials I am granted access.

I then create a local host entry called Betty and point the host file to the same IP address as Fred and change the host header to Betty. There is no associated CName record anywhere. When I access Betty I am authenticated automatically and everything is fine.

If I attempt to bypass the CName record and create an entry in the local host file called Fred and change back the host header to Fred. I still receive an authentication challenge.

As I see it have two questions. How is this CName record affecting the resolution here or is it a red herring. Secondly what is happening with this challenge? We have similar symptoms elsewhere and our concern is that our authentication token is getting blatted somewhere. Could someone walkthrough the order in with Authentication occurs i.e. what packets are sent to what machines. Is there a way I can trace this? (I'm thinking WireShark or something similar). How can I prove my authentication token is getting passed and is valid?

Answer 1

The reason for the authentication box is simple: Internet Explorer sends your credentials only if it thinks the host is in the "Local Intranet" zone (default configuration assumed). If a host outside what IE deems to be "local" asks for NTLM credentials, an authentication box will appear, and you have to authenticate manually.

If you want your credentials to be sent automatically, make sure IE thinks it in "Local Intranet". Check the zone info far right on the status bar to see the currently active zone.

IE takes into account multiple things in order to decide whether a host is to be considered as "Local Intranet":

1. is it an IP address in the local sub-net -> YES
2. is it a simple host name (i.e. "no dots") -> YES
3. in the IE options: is it in the "Sites..." list for "Local Intranet" -> YES
4. in the IE options: is it in the proxy exclusion list -> YES
5. is it an UNC path -> YES
6. otherwise: NO
7. Sometimes, an old password exists in the personal passwords list for that host name (accessible through Control Panel -> User Accounts). If it is wrong, similar issues can occur.

My suspicion is that your host "fred" does not fulfill conditions #2 through #4, but your test case "Betty" somehow does.

What way the name was resolved (CName record, A record, hosts file, other) makes no difference, because the method of name resolution is opaque to the calling application. IE just asks for name "XYZ" and gets an IP address back.

Recent configuration changes can require you to clear the local DNS cache, though. An occasional ipconfig /flushdns would help here, alternatively you can stop the DNS Client service for a while.

The described internal logic is applied to the host name and security settings change based on the outcome.

Answer 2

CName would be a red herring. Has no effect on Windows Auth or not. The easiest way to trace it is with fiddler. You should see your request followed by a 401 response (it contains the authentication the server supports), then your request again is sent with the authentication details (or you are prompted and then it's sent)