IWA and Trusted Sites (Windows)

[dreijer]

Hi there,

I'm working on a web app that for authentication prefers Integrated Windows Authentication (Kerberos), and if that fails, falls back to regular forms-based auth. In order for the browser to send a Kerberos ticket, the site has to be in the Intranet zone on Windows.

In both Internet Explorer and Firefox, if I send an Ajax request to an endpoint that returns a 401 with a 'WWW-Authenticate: Negotiate' header and that endpoint isn't in the Intranet zone, the browser won't even attempt to authenticate the user and thus won't display an NTLM prompt window. In other words, the browser just swallows the 401 response since it cannot do Negotiate.

Chrome, on the other hand, shows an NTLM popup window once it receives the 401 from the server. Thus, I have the following questions:

1. Is this really the desired behavior in Chromium? The web service explicitly said it only wanted Negotiate (not NTLM), so why does the browser attempt NTLM?
2. If the behavior isn't about to be changed, I'm wondering if there's a way for me to detect that the IWA endpoint is in the Intranet zone before I make the initial request to the IWA endpoint. For instance, I know that IE keeps the different zones isolated (e.g. separate cookie jars), which means I could send a request to the IWA endpoint, have it set a cookie and then try send that cookie to a different sub-domain. If the browser doesn't send the cookie along, then I can make a pretty good guess that the two sites are in different zones. Based on my tests, this is not the behavior in Chrome and I've been unable to dig up any information on what behavior Chrome has for trusted sites vs regular sites (I haven't looked at the code yet). Does anybody know what restrictions are removed when a site is trusted in Chromium?

Thanks,

Soren

[PhistucK]

Sorry for my ignorance - what is the graphical user interface difference between an NTLM prompt versus a Negotiate prompt?

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[dreijer]

You don't get a prompt for Negotiate; the browser just does the Kerberos dance behind the scenes as long as the target site is trusted, which is what I want. If Kerberos cannot be performed, I want to silently fall back to regular forms-based auth rather than have the browser display an ugly prompt I have no control over.

[PhistucK]

> You don't get a prompt for Negotiate

In other browsers, you mean, right?

I tried https://ipa.demo1.freeipa.org/ipa/ui/ (or directly, https://ipa.demo1.freeipa.org/ipa/session/login_kerberos) and only Chrome indeed prompted. I am not sure what the right behavior should be. I added net-dev to the thread, they might know more.

☆PhistucK

[Asanka Herath]

On Sun, May 22, 2016 at 6:52 AM, PhistucK <phis...@gmail.com> wrote:

> You don't get a prompt for Negotiate

In other browsers, you mean, right?

I tried https://ipa.demo1.freeipa.org/ipa/ui/ (or directly, https://ipa.demo1.freeipa.org/ipa/session/login_kerberos) and only Chrome indeed prompted. I am not sure what the right behavior should be. I added net-dev to the thread, they might know more.

FWIW, I tried these URLs on IE and saw the same prompting behavior as Chrome. 

 

☆PhistucK

On Sat, May 21, 2016 at 11:16 PM, dreijer <dreij...@gmail.com> wrote:

You don't get a prompt for Negotiate; the browser just does the Kerberos dance behind the scenes as long as the target site is trusted, which is what I want. If Kerberos cannot be performed, I want to silently fall back to regular forms-based auth rather than have the browser display an ugly prompt I have no control over.

On Saturday, May 21, 2016 at 12:18:48 PM UTC-7, PhistucK wrote:

Sorry for my ignorance - what is the graphical user interface difference between an NTLM prompt versus a Negotiate prompt?

☆PhistucK

On Sat, May 21, 2016 at 9:59 PM, dreijer <dreij...@gmail.com> wrote:

Hi there,

I'm working on a web app that for authentication prefers Integrated Windows Authentication (Kerberos), and if that fails, falls back to regular forms-based auth. In order for the browser to send a Kerberos ticket, the site has to be in the Intranet zone on Windows.

In both Internet Explorer and Firefox, if I send an Ajax request to an endpoint that returns a 401 with a 'WWW-Authenticate: Negotiate' header and that endpoint isn't in the Intranet zone, the browser won't even attempt to authenticate the user and thus won't display an NTLM prompt window. In other words, the browser just swallows the 401 response since it cannot do Negotiate.

Chrome, on the other hand, shows an NTLM popup window once it receives the 401 from the server. Thus, I have the following questions:

1. Is this really the desired behavior in Chromium? The web service explicitly said it only wanted Negotiate (not NTLM), so why does the browser attempt NTLM?

"Negotiate" is not itself an authentication mechanism. It's used for negotiating the actual mechanism, which could be Kerberos or NTLM or something else. Chrome doesn't [currently] restrict the list of mechanisms that are allowed to authenticate against a specific target. But it does restrict the use of ambient credentials based on whether the target is whitelisted or whether Windows allows credentials to be used without prompting for the target.

Under Chrome, an untrusted site using the "Negotiate" scheme can use any mechanism that supports explicit credentials. On Windows, this means that NTLM with explicit credentials is allowed. On other platforms, "Negotiate" only supports Kerberos with ambient credentials. Hence on these platforms you won't see a prompt for "Negotiate".

1. If the behavior isn't about to be changed, I'm wondering if there's a way for me to detect that the IWA endpoint is in the Intranet zone before I make the initial request to the IWA endpoint. For instance, I know that IE keeps the different zones isolated (e.g. separate cookie jars), which means I could send a request to the IWA endpoint, have it set a cookie and then try send that cookie to a different sub-domain. If the browser doesn't send the cookie along, then I can make a pretty good guess that the two sites are in different zones. Based on my tests, this is not the behavior in Chrome and I've been unable to dig up any information on what behavior Chrome has for trusted sites vs regular sites (I haven't looked at the code yet). Does anybody know what restrictions are removed when a site is trusted in Chromium?

Chrome only looks at IE security zones to determine whether ambient credentials can be used against a target, and only when there's no explicit whitelist of targets. There should be no other observable side-effects.

For completeness, IE security zones are also considered when handling a download. But that's not relevant here.

The test you describe above won't always work even for IE. The credentials use policy for a specific IE security zone can be changed by the user or by group policy. In the case of Chrome, the zone is irrelevant if there's an explicit whitelist.

You want to find out whether the user can authenticate against a specific protection space without prompting. Unfortunately, HTTP doesn't provide a way to discover this. You could sniff it out using other observable side-effects. For example, a cross origin image load on Chrome doesn't show a prompt and fails the request if any prompting is required. But such techniques are fragile and unsupported.

Thanks,

Soren

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CABc02_LDjM5RnX1FbrPbDu0rP2SdxGBU1DTWp%3DjxNKjmve_yjg%40mail.gmail.com.

[Christian Biesinger]

If you really want to test Negotiate, your machine should be part of a
Windows Domain, and the server to authenticate with should be part of
the same domain...

-Christian

[dreijer]

Thanks for the response! See inline please:

On Monday, May 23, 2016 at 10:18:30 AM UTC-7, Asanka wrote:

On Sun, May 22, 2016 at 6:52 AM, PhistucK <phis...@gmail.com> wrote:

> You don't get a prompt for Negotiate
In other browsers, you mean, right?

I tried https://ipa.demo1.freeipa.org/ipa/ui/ (or directly, https://ipa.demo1.freeipa.org/ipa/session/login_kerberos) and only Chrome indeed prompted. I am not sure what the right behavior should be. I added net-dev to the thread, they might know more.

FWIW, I tried these URLs on IE and saw the same prompting behavior as Chrome. 

I should probably have been more explicit in my original post about the setup. The domain of the main login endpoint, i.e. the page that shows the login page, and the domain that performs the IWA auth are different domains because I don't want to ask customers to add the main login endpoint, e.g. myfederationservice.com to their list of trusted sites by accident (e.g. if I asked customers to add iwa.myfederationservice.com to the trusted list, they might erroneously add *.myfederationservice.com instead, which would be bad).

In both IE and Edge, if the call to the IWA endpoint is an Ajax CORS request, then no NTLM prompt is displayed. That might indeed be a bug since, like you mention below, Negotiate just means SPNEGO, which is allowed to negotiate both Kerberos and NTLM. For some reason, NTLM is skipped for the Ajax CORS request, which works to my advantage.

(FWIW, whoever decided it was a good idea to let a protocol negotiate an authentication mechanism without letting the client or server restrict the list (like TLS does for the cipher suite) was incredibly short sighted.)

1. If the behavior isn't about to be changed, I'm wondering if there's a way for me to detect that the IWA endpoint is in the Intranet zone before I make the initial request to the IWA endpoint. For instance, I know that IE keeps the different zones isolated (e.g. separate cookie jars), which means I could send a request to the IWA endpoint, have it set a cookie and then try send that cookie to a different sub-domain. If the browser doesn't send the cookie along, then I can make a pretty good guess that the two sites are in different zones. Based on my tests, this is not the behavior in Chrome and I've been unable to dig up any information on what behavior Chrome has for trusted sites vs regular sites (I haven't looked at the code yet). Does anybody know what restrictions are removed when a site is trusted in Chromium?

Chrome only looks at IE security zones to determine whether ambient credentials can be used against a target, and only when there's no explicit whitelist of targets. There should be no other observable side-effects.

For completeness, IE security zones are also considered when handling a download. But that's not relevant here.

The test you describe above won't always work even for IE. The credentials use policy for a specific IE security zone can be changed by the user or by group policy. In the case of Chrome, the zone is irrelevant if there's an explicit whitelist.

You want to find out whether the user can authenticate against a specific protection space without prompting. Unfortunately, HTTP doesn't provide a way to discover this. You could sniff it out using other observable side-effects. For example, a cross origin image load on Chrome doesn't show a prompt and fails the request if any prompting is required. But such techniques are fragile and unsupported.

By image load, you mean just fetching a picture using a cross origin Ajax request?

The reason you're saying this is fragile is because the behavior could change at any point without warning? I might be willing to live dangerously if I have continuous tests running against beta versions of Chrome to verify the behavior.

Out of curiosity, are there other ways similar to the cross origin image load you can think of that would have an observable side-effect I could use as a heuristic? I've been wondering if maybe iframes would let me put restrictions on the JS code that would have observable side-effects.

Thanks so much for the help. I really appreciate it!

/ Soren

[dreijer]

Right, so my question isn't about how to test Negotiate -- I know how it works -- but how to prevent an NTLM prompt when I only want to perform Kerberos and gracefully fall back to forms-based auth.