Integrated Auth / Default Domain Issues

We are having a problem with IIS 6 and authentication. I was reading
through posts on this newsgroup and found a recent discussion between
Brent Magnant & Ken Schaefer. Brent's problem seems to be the same as
mine, but I do not see a resolution for him!

Users who are in the office authenticate with IE automatically as we
have Integrated Windows Authentication enabled.

If a user attempts to access from home, they are prompted with a login
box. They MUST enter the domain\username or it will just keep prompting
them for the username.

We currently have enabled:

- Integrated Windows authentication
- Basic authentication

We have specified the default domain, but IE just will not work without
the domain portion being entered when accessing from home.

The strange thing is, firefox works perfectly.

Can anyone provide me with some insight?


Thanks a bunch!


Wendy

Re: Integrated Auth / Default Domain Issues

Hi,

Firefox may be using Basic Authentication. Because Basic Authentication
allows the web server to receive the username and password in cleartext, IIS
can easily insert the Domain\ part into the username before attempting to
logon that user.

With Integrated Windows Authentication (either NTLM v2 or Kerberos) is it
not currently possible to insert the Domain\ part into the username. The
users need to specify Domain\Username or user@upn

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"Wendy Beach" wrote in message
news:egVLJtVsHHA.1324@TK2MSFTNGP06.phx.gbl...
> We are having a problem with IIS 6 and authentication. I was reading
> through posts on this newsgroup and found a recent discussion between
> Brent Magnant & Ken Schaefer. Brent's problem seems to be the same as
> mine, but I do not see a resolution for him!
>
> Users who are in the office authenticate with IE automatically as we have
> Integrated Windows Authentication enabled.
>
> If a user attempts to access from home, they are prompted with a login
> box. They MUST enter the domain\username or it will just keep prompting
> them for the username.
>
> We currently have enabled:
>
> - Integrated Windows authentication
> - Basic authentication
>
> We have specified the default domain, but IE just will not work without
> the domain portion being entered when accessing from home.
>
> The strange thing is, firefox works perfectly.
>
> Can anyone provide me with some insight?
>
>
> Thanks a bunch!
>
>
> Wendy

Re: Integrated Auth / Default Domain Issues

Thanks for the details Ken, why does IE not fallback to basic when we
are not accessing from inside the office? I read IWA will not work over
the Internet, so is there a way to make it access using the basic option?

Wendy


Ken Schaefer wrote:
> Hi,
>
> Firefox may be using Basic Authentication. Because Basic Authentication
> allows the web server to receive the username and password in cleartext,
> IIS can easily insert the Domain\ part into the username before
> attempting to logon that user.
>
> With Integrated Windows Authentication (either NTLM v2 or Kerberos) is
> it not currently possible to insert the Domain\ part into the username.
> The users need to specify Domain\Username or user@upn
>
> Cheers
> Ken
>

Re: Integrated Auth / Default Domain Issues

Hi,

The webserver presents an ordered list of authentication protocols that it
supports, and the browser picks the first one in the list that it supports.
That's the way it's supposed to work.

In your case, your server is probably sending back a list such as:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic

(the first is the GSSP API that allows Kerberos to be negotiated, second is
NTLM, third is Basic).

It is not entirely true to say that IWA doesn't work over the internet.

For Kerberos to work, the browser much be able to get a Kerberos service
ticket from a KDC (which runs on Domain Controllers in the Windows world).
Typically a KDC is not exposed to internet clients, which is why Kerberos
doesn't work.

NTLM (the other protocol under IWA) doesn't work through most forward
proxies (because it relies on an end-to-end connection). Most forward
proxies to not proxy HTTPS requests, so NTLM can work over HTTPS.
Alternatively, if the end client is not behind a forward proxy then NTLM
will work fine.

In your situation, you probably want:
a) configure two websites in IIS that point to the same content.
b) One site is used internally (http://appname) and uses IWA
c) One site is used externally (http://appname.yourdomain.com) and uses
Basic (over SSL)

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"Wendy Beach" wrote in message
news:eGfaGOWsHHA.5008@TK2MSFTNGP03.phx.gbl...
> Thanks for the details Ken, why does IE not fallback to basic when we are
> not accessing from inside the office? I read IWA will not work over the
> Internet, so is there a way to make it access using the basic option?
>
> Wendy
>
>
> Ken Schaefer wrote:
>> Hi,
>>
>> Firefox may be using Basic Authentication. Because Basic Authentication
>> allows the web server to receive the username and password in cleartext,
>> IIS can easily insert the Domain\ part into the username before
>> attempting to logon that user.
>>
>> With Integrated Windows Authentication (either NTLM v2 or Kerberos) is it
>> not currently possible to insert the Domain\ part into the username. The
>> users need to specify Domain\Username or user@upn
>>
>> Cheers
>> Ken
>>

Re: Integrated Auth / Default Domain Issues

You are totally correct Ken, using Fiddler we are able to see those
WWW-Authenticate headers being sent to the client.

The solution of running two websites, that point to the same source
could certainly be done. Although it is a pain in the butt to have to
maintain two sets of virtual folders etc.

We currently use a sync. tool from Microsoft to replicate the
configuration of the website across multiple machines that we are load
balancing.

Do you think it would also be possible to use this same tool to keep a
second copy of the 'same site' in sync, but without the NTLM
authentication enabled?


Thanks,

Wendy


Ken Schaefer wrote:
> Hi,
>
> The webserver presents an ordered list of authentication protocols that
> it supports, and the browser picks the first one in the list that it
> supports. That's the way it's supposed to work.
>
> In your case, your server is probably sending back a list such as:
>
> WWW-Authenticate: Negotiate
> WWW-Authenticate: NTLM
> WWW-Authenticate: Basic
>
> (the first is the GSSP API that allows Kerberos to be negotiated, second
> is NTLM, third is Basic).
>
> It is not entirely true to say that IWA doesn't work over the internet.
>
> For Kerberos to work, the browser much be able to get a Kerberos service
> ticket from a KDC (which runs on Domain Controllers in the Windows
> world). Typically a KDC is not exposed to internet clients, which is why
> Kerberos doesn't work.
>
> NTLM (the other protocol under IWA) doesn't work through most forward
> proxies (because it relies on an end-to-end connection). Most forward
> proxies to not proxy HTTPS requests, so NTLM can work over HTTPS.
> Alternatively, if the end client is not behind a forward proxy then NTLM
> will work fine.
>
> In your situation, you probably want:
> a) configure two websites in IIS that point to the same content.
> b) One site is used internally (http://appname) and uses IWA
> c) One site is used externally (http://appname.yourdomain.com) and uses
> Basic (over SSL)
>
> Cheers
> Ken
>

Re: Integrated Auth / Default Domain Issues

Hi Wendy,

When administering multiple machines, I usually script out all my changes.

Then you can easily run the script against multiple machines (or even
multiple websites on the one machine). it also means that if you ever have
to repeat the process (e.g. rebuild a box where the backups aren't
available) you just rerun all your scripts in order.

And having the scripts means you have some kind of record trail of all the
changes you've made to your boxes.

That would be my recommendation.

Cheers
Ken


"Wendy Beach" wrote in message
news:%234DAIGgsHHA.4916@TK2MSFTNGP05.phx.gbl...
> You are totally correct Ken, using Fiddler we are able to see those
> WWW-Authenticate headers being sent to the client.
>
> The solution of running two websites, that point to the same source could
> certainly be done. Although it is a pain in the butt to have to maintain
> two sets of virtual folders etc.
>
> We currently use a sync. tool from Microsoft to replicate the
> configuration of the website across multiple machines that we are load
> balancing.
>
> Do you think it would also be possible to use this same tool to keep a
> second copy of the 'same site' in sync, but without the NTLM
> authentication enabled?
>
>
> Thanks,
>
> Wendy
>
>
> Ken Schaefer wrote:
>> Hi,
>>
>> The webserver presents an ordered list of authentication protocols that
>> it supports, and the browser picks the first one in the list that it
>> supports. That's the way it's supposed to work.
>>
>> In your case, your server is probably sending back a list such as:
>>
>> WWW-Authenticate: Negotiate
>> WWW-Authenticate: NTLM
>> WWW-Authenticate: Basic
>>
>> (the first is the GSSP API that allows Kerberos to be negotiated, second
>> is NTLM, third is Basic).
>>
>> It is not entirely true to say that IWA doesn't work over the internet.
>>
>> For Kerberos to work, the browser much be able to get a Kerberos service
>> ticket from a KDC (which runs on Domain Controllers in the Windows
>> world). Typically a KDC is not exposed to internet clients, which is why
>> Kerberos doesn't work.
>>
>> NTLM (the other protocol under IWA) doesn't work through most forward
>> proxies (because it relies on an end-to-end connection). Most forward
>> proxies to not proxy HTTPS requests, so NTLM can work over HTTPS.
>> Alternatively, if the end client is not behind a forward proxy then NTLM
>> will work fine.
>>
>> In your situation, you probably want:
>> a) configure two websites in IIS that point to the same content.
>> b) One site is used internally (http://appname) and uses IWA
>> c) One site is used externally (http://appname.yourdomain.com) and uses
>> Basic (over SSL)
>>
>> Cheers
>> Ken
>>