tags:

views:

444

answers:

4

I'm setting up a (ASP.NET) website to be used internally at my company. In IIS, I've turned on Integrated Windows authentication and turned off anonymous access. Once I've done this, the website pops up the "enter your username/password" box whenever you visit the site, but won't log you in even if the username/password are correct. This happens even if you're logged in to your computer with a domain account as opposed to a local account.

However, if I enter the IP of the site in my hosts file, the site works perfectly (logs the user in without the additional challenge).

I guess I have two questions.

1) Why does the hosts entry have this affect?

2) How can I get the site to succeed without a) forcing everyone to edit their hosts file or b) the site challenging them and failing to log them in?

EDIT: I checked, and we do have our DNS server set up to point those URLs to the correct servers. That's why pinging the URL displays the right IP. However, it appears that in addition to having that DNS entry, we also have to have the hosts file entry for the site to work.

A: 

This sure sounds like a dns problem. Does the dns server know about the hostname you are using? Sounds like the dns server does not know the forward lookup (hostname to ip) for the host you are trying to connect to.

CSharpAtl
Ping points to the right IP even without the hosts entry. I'm not sure if that answers your question.
Adam V
So if you use the IP address in the browser it works or not?
CSharpAtl
It doesn't, because my site isn't the default website on this server. That's why the host header entry is required.
Adam V
A: 

We recently set up an intranet site with windows authentication here. The network guys setup a group policy and pushed changed to IE and Firefox.

For IE, it added the site to "Intranet Sites" and for Firefox it modified the configuration file so that our intranet..com would be trusted.

Min
We have "http://*.DOMAINNAME.com" added to the "Local Intranet" zone. Right now the site isn't working 100% in FF, but my boss doesn't care about that yet. So I'll cross that bridge when I come to it. :)
Adam V
+1  A: 

You probably are having an issue with Kerberos authentication.

Since you're using a url of Site.DomainName.com, I'm assuming DomainName.com is your AD's name also.

On the server that's running IIS, copy SetSPN.EXE from the resource kit tools and run the following:

setspn -A http/site.domainname.com IISServerName

Where SITE is your URL and IISServerName is the name of the server.

Christopher_G_Lewis
A: 

So... we got it to work. Here's what happened.

While looking around at the DNS Manager on test.DOMAINNAME.com, my coworker noticed that a different site on the same server was set up as a "Host (A)" entry, whereas the site we were working on was set up as an "Alias (CNAME)" entry. Several other sites on that computer were also set up as Alias entries, and he mentioned that the one site with the Host entry was "rock-solid", and he'd had sporadic issues with at least one other site that was set up as an Alias.

We talked to the AD/DNS admin, and as a test, he switched our entries from Alias to Host, and once we cleared our local DNS caches, it worked perfectly (without requiring entries in our .hosts file).

So the question still sorta stands. This was a Win2k3 box serving as one of three internal DNS servers, and making this modification fixed our problem. If anyone can add any additional information, we'd be very grateful, but in the meantime, we're debating going back and fixing all our other sites.

Adam V