Problem with Host Headers and Integrated Security.

I believe I have discovered what some would call a "feature" with IIS and
integrated security, others would call it a bug.

My IIS sites use integrated security as a means of identifying users and
controlling access to Intranet sites. Since IIS 4, it has been my practice to
create two sites on the same server to be used for development / test and
production. Access to which site by Host Header settings. e.g.

test.intranet. (e.g. test.intranet.microsoft.com) used for
development and testing
intranet. the production site
is the Active domain against which all users are authenticated.

On servers I have built recently, this approach has stopped working.

When you try to access the test.intranet. site, you get a login
prompt which is repeated - even if you enter a correct password. The same
code and settings work with the production site.

I believe there is now a bug in the integrated security code caused by the
move to Kerberos and is due to the Host header causing IIS to "confuse" its
realm. When the domain name is test.intranet., it is trying to
authenticate against intranet. even if you provide a fully qualified
user name when you try to login from the browser. Hence IIS cannot
authenticate.

I hope this post helps other people as I have spent several days trying to
get my servers working again.

Best regards
Paul

Re: Problem with Host Headers and Integrated Security.

Thanks for the post -- I appreciate people announcing information to
help others. However, I believe there are some fundamental flaws with
your analysis that make your conclusions dangerously incorrect.

I am assuming you are working with IIS6 and Windows Server 2003.

Integrated authentication has *nothing* to do with the IIS Host
header. Why? Because IIS does not use the host header in any way to
contact the AD to authenticate the user. With Integrated
authentication, IIS does not even see the username, password, nor
domain name anywhere? As far as IIS is concerned, it is just passing
an opaque blob to/from the AD, so what you type is what gets
authenticated by the AD -- IIS does not call the AD to authenticate
the opaque blob relative to the value of its host header. Unlike Basic
auth, where you can configure the "domain" of the user because IIS is
just calling LogonUser with non-opaque username/password.

I believe something else has happened within your environment to cause
Integrated Authentication to fail and it is unique to your situation.
I understand that you are basically saying "I have been doing this for
10 years from IIS4 and it has worked, so if it doesn't work now, it
must be a bug with IIS". However, you do realize that the default
behavior in IIS6 of Integrated Authentication has flipped from NTLM to
Kerberos during that time period? So, your procedures may have
remained the same, but those procedures are certainly not configuring
the same thing anymore, so how can you expect identical behavior? You
can argue whether changing default values is a "bug" or not, but the
fact of the matter remains.

If you would please identify the IIS version you are using, and if
IIS6 then what is your Application Pool Identity, we can get your
mistake straightened out.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//







On Jan 15, 7:43=A0am, Pauli wrote:
> I believe I have discovered what some would call a =A0"feature" with IIS a=
nd
> integrated security, others would call it a bug.
>
> My IIS sites use integrated security as a means of identifying users and
> controlling access to Intranet sites. Since IIS 4, it has been my practice=
to
> create two sites on the same server to be used for development / test and
> production. Access to which site by Host Header settings. e.g.
>
> =A0test.intranet. (e.g. test.intranet.microsoft.com) used for
> development and testing
> =A0intranet. the production site
> =A0 is the Active domain against which all users are authenticated=
..
>
> On servers I have built recently, this approach has stopped working.
>
> When you try to access the test.intranet. site, you get a login
> prompt which is repeated - even if you enter a correct password. The same
> code and settings work with the production site.
>
> I believe there is now a bug in the integrated security code caused by the=

> move to Kerberos and is due to the Host header causing IIS to "confuse" it=
s
> realm. When the domain name is test.intranet., it is trying to=

> authenticate against intranet. even if you provide a fully qualifi=
ed
> user name when you try to login from the browser. Hence IIS cannot
> authenticate.
>
> I hope this post helps other people as I have spent several days trying to=

> get my servers working again.
>
> Best regards
> Paul

Re: Problem with Host Headers and Integrated Security.

David,

Thanks for the reply. I understand what you are saying about the move to
Kerberos from NTLM and about host headers. As you say, I would be very
suprised if host headers were involved in security.

However, I have now seen this problem on two machines, one a rebuild and the
other a new installation. In the second instance a case was raised with
Microsoft (Case# SRQ071116600346 ) who resolved it by "In order to ensure
that you are able to use the host header we also have the site running under
NTLM."

My report in this thread was with the rebuilt system where I spent some time
trying to find a solution other than to use NTLM. Changing the host header
definiitely changed the way the site responded to the browser, suggesting the
assumption they are independent is not correct.

In answer to your question:
1) The server is Windows 2003 R2 SP2, all security patches applied, running
IIS6
2) This is a development machine, and the Web site is running with its own
appliation pool. The UID is configured to a domain user who is a member of
the Administrators group.

Thanks again for your help
Best regards
Paul