If a firewall prevents CLDAP or DNS or Kerberos traffic, the www-authenticate
mechanism Negotiate will fail. Internet Explorer will present a "Internet
Explorer cannot display the webpage" error after the kerberos method fails.

Desired behavior: Internet Explorer should continue down the auth chain,
and try NTLM after deciding kerberos is not available for whatever reason.
Tested Firefox on Windows XP and Macintosh OSX (both bound to AD), which
behaves as expected after configuring these two config options:

network.negotiate-auth.trusted-uris
network.automatic-ntlm-auth.trusted-uris

with your domain (company.com)-- not trolling just pointing out that it is
NOT an OS problem but specifically the IE browser that is failing.

Brian Yuil has had this problem for quite a while. See
http://www.eggheadcafe.com/software/...t-explore.aspx for example.

This is a surprisingly huge issue since anyone that takes a company laptop
home (AD environment) will likely have an expired kerberos ticket after 10
hours... So they simply will not be able to use Internet Explorer unless
they VPN in (inconvenient) or we open the firewall for CLDAP and Kerberos
traffic (bad idea).

The alternative of disabling Negotiate on IIS and using pure NTLM (which
seems popular) is also distasteful because it would prevent other operating
systems from enjoying the benefits of true Single SignOn-- namely Macintosh
clients.

Tested with IE7 and IE8 (newest version as of this writing) on a Windows XP
client.

To reproduce you can use a firewall or manipulate your
routing table to provide an invalid route to your domain controllers, then
then using kerbtray flush your ticket cache, then refresh the webpage that
uses negotiate,ntlm. Wireshark is handy too. Make sure you are logged in as
a domain user on a machine that is bound to AD.

Thank you for any response!

Thanks!

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities...plorer.general

Quick question The XP and the OSX are connected and feeding with which server.

--
Peter

Please Reply to Newsgroup for the benefit of others
Requests for assistance by email can not and will not be acknowledged.

"briend" <briend@discussions.microsoft.com> wrote in message
news:96D58ACD-7961-4742-9AFE-7EFFEA4D7B11@microsoft.com...
> If a firewall prevents CLDAP or DNS or Kerberos traffic, the www-authenticate
> mechanism Negotiate will fail. Internet Explorer will present a "Internet
> Explorer cannot display the webpage" error after the kerberos method fails.
>
> Desired behavior: Internet Explorer should continue down the auth chain,
> and try NTLM after deciding kerberos is not available for whatever reason.
> Tested Firefox on Windows XP and Macintosh OSX (both bound to AD), which
> behaves as expected after configuring these two config options:
>
> network.negotiate-auth.trusted-uris
> network.automatic-ntlm-auth.trusted-uris
>
> with your domain (company.com)-- not trolling just pointing out that it is
> NOT an OS problem but specifically the IE browser that is failing.
>
> Brian Yuil has had this problem for quite a while. See
> http://www.eggheadcafe.com/software/...t-explore.aspx
> for example.
>
> This is a surprisingly huge issue since anyone that takes a company laptop
> home (AD environment) will likely have an expired kerberos ticket after 10
> hours... So they simply will not be able to use Internet Explorer unless
> they VPN in (inconvenient) or we open the firewall for CLDAP and Kerberos
> traffic (bad idea).
>
> The alternative of disabling Negotiate on IIS and using pure NTLM (which
> seems popular) is also distasteful because it would prevent other operating
> systems from enjoying the benefits of true Single SignOn-- namely Macintosh
> clients.
>
> Tested with IE7 and IE8 (newest version as of this writing) on a Windows XP
> client.
>
> To reproduce you can use a firewall or manipulate your
> routing table to provide an invalid route to your domain controllers, then
> then using kerbtray flush your ticket cache, then refresh the webpage that
> uses negotiate,ntlm. Wireshark is handy too. Make sure you are logged in as
> a domain user on a machine that is bound to AD.
>
> Thank you for any response!
>
> Thanks!
>
> ----------------
> This post is a suggestion for Microsoft, and Microsoft responds to the
> suggestions with the most votes. To vote for this suggestion, click the "I
> Agree" button in the message pane. If you do not see the button, follow this
> link to open the suggestion in the Microsoft Web-based Newsreader and then
> click "I Agree" in the message pane.
>
> http://www.microsoft.com/communities...plorer.general

I'm not sure I understand, but both machines are bound to the AD server which
also serves DNS. The web server is a separate server also bound to AD. All
the kerberos settings and SPNs are configured correctly and everything works
fine unless you introduce a firewall that blocks kerberos or DNS or CLDAP and
you have expired tickets. In this case only Firefox will work correctly, and
IE will be broken with really no work-around other than VPN or log in as a
local machine user instead of you domain account.

Brien

"Peter Foldes" wrote:

> Quick question The XP and the OSX are connected and feeding with which server.
>
> --
> Peter
>

We experienced same problem, when both sides (web server, client)
support kerberos and NTLM and Integrated Windows Authentication on
client is enabled, after Kerberos fail it will not fall back to NTLM.
When I use some type of proxy (eg. Fiddler) it works fine, in other
browser too (Firefox)

It seems that it is by (faulty) design.

With Windows 7 + IE 8 it works correctly as expected

On 13 �nc, 21:46, briend <bri...@discussions.microsoft.com> wrote:
> I'm not sure I understand, but both machines are bound to the AD server which
> also serves DNS. Â*The web server is a separate server also bound to AD. Â*All
> the kerberos settings and SPNs are configured correctly and everything works
> fine unless you introduce a firewall that blocks kerberos or DNS or CLDAPand
> you have expired tickets. Â*In this case only Firefox will work correctly, and
> IE will be broken with really no work-around other than VPN or log in as a
> local machine user instead of you domain account.
>
> Brien
>
>
>
> "Peter Foldes" wrote:
> > Quick question The XP and the OSX are connected and feeding Â*with which server.
>
> > --
> > Peter– Skrýt citovaný text –
>
> – Zobrazit citovaný text –

Did anyone find a solution to this issue in Windows XP other than unchecking
the "Enable Integrated Authentication"

It seems like a registry key somewhere that could be modified to enable it
to fail over, but having trouble finding anything - any "fix" for this?

"Arkady" wrote:

> We experienced same problem, when both sides (web server, client)
> support kerberos and NTLM and Integrated Windows Authentication on
> client is enabled, after Kerberos fail it will not fall back to NTLM.
> When I use some type of proxy (eg. Fiddler) it works fine, in other
> browser too (Firefox)
>
> It seems that it is by (faulty) design.
>
> With Windows 7 + IE 8 it works correctly as expected
>
> On 13 �nc, 21:46, briend <bri...@discussions.microsoft.com> wrote:
> > I'm not sure I understand, but both machines are bound to the AD server which
> > also serves DNS. The web server is a separate server also bound to AD. All
> > the kerberos settings and SPNs are configured correctly and everything works
> > fine unless you introduce a firewall that blocks kerberos or DNS or CLDAP and
> > you have expired tickets. In this case only Firefox will work correctly, and
> > IE will be broken with really no work-around other than VPN or log in as a
> > local machine user instead of you domain account.
> >
> > Brien
> >
> >
> >
> > "Peter Foldes" wrote:
> > > Quick question The XP and the OSX are connected and feeding with which server.
> >
> > > --
> > > Peter– Skrýt citovaný text –
> >
> > – Zobrazit citovaný text –
>
>