Integrated Authentication Whitelist with Intranet Passthrough

[Daniel E. Markle]

Looking at the page at:
https://sites.google.com/a/chromium.org/dev/developers/design-documents/http-authentication

There is no way specified to enable AuthServerWhitelist and keep the servers in the Local Machine or Local Intranet security zone passthrough functioning. For example given a host https://myintranet which is in the local DNS search zone:

AuthServerWhitelist = *.example.com

Once this is set, the local 'short name' zone passthrough stops functioning. I.E. it now works for https://myintranet.example.com only and no longer for https://myintranet which is not desirable behavior in most cases. One can work around this with:

AuthServerWhitelist = *.exmaple.com,*

Obviously though this is not a good idea, it just enables everything.

Is there a way to enable this behavior where both work as per IE / Edge make possible?


--
Daniel E. Markle
http://ashtech.net/~dmarkle/

[Ryan Sleevi]

When  you say "local DNS search zone", do you mean the entire search zone, or just for unqualified, single-label hostnames? i.e. are you trying to have it work for both "myintranet" and "myintranet.corp" (for myintranet.example.com and myintranet.corp.example.com)? Or just for "myintranet", the unqualified label?

Is there a reason that specifying, in the AuthServerWhitelist, "*.example.com, myintranet" doesn't/wouldn't work? Understanding that use case a bit more may further help.

As an interim solution / if we don't implement this feature, does using Group Policy to modify the Local Machine/Local Intranet security zone, and explicitly not specifying an AuthServerWhitelist, satisfy the need? This would align with, presumably, the existing IE / Edge behaviour here, although perhaps I misunderstood the question? 

[Daniel E. Markle]

On Thu, Oct 10, 2019 at 01:44:34PM -0400, Ryan Sleevi wrote:
> myintranet.example.com and myintranet.corp.example.com)? Or just for
> "myintranet", the unqualified label?

Just for the unqualified label, *.example.com already works for subdomains. And in our example the unqualified label for any host in the DNS domain, not just the single host given as a trivial example.

> Is there a reason that specifying, in the AuthServerWhitelist, "*.
> example.com, myintranet" doesn't/wouldn't work? Understanding that use case

The underlying issue is there are thousands of service endpoints involved here, and constantly changing. Not just the one example.

> Group Policy to modify the Local Machine/Local Intranet security zone, and
> explicitly not specifying an AuthServerWhitelist, satisfy the need? This

This solution doesn't work for our non-Windows client systems. Ideally we'd have a solution that solved this problem everywhere with similar functionality across the user base. DNS short name should be treated the same by all platforms. A cross platform solution like a token that can be specified in the whitelist that means 'dns short names' or checking the resolver for search domains and allowing those would be ideal.

Even for Windows I suspect making a change like this for Chrome where the current settings for the GPO today work correctly for the IE/Edge browsers is going to be a tough sell due to risk of other impacts in a large environment. I will however bounce it off the appropriate administrative team.

[Ryan Sleevi]

Right, there are a host of other security/compatibility risks through the use of unqualified domains, so while I think it's a totally valid and understandable feature request, it'd be unfortunate if it encouraged their continued use or spread.

That said, I can also understand where, without this feature, getting folks to migrate from "foo" to "foo.corp.example" is hard, because you can't keep the same continuity of having "foo" work while you transition. However, IIRC, "foo" working at all is Windows-only, and the other platforms require explicit whitelisting, which is the intent.

So your non-Windows machines already need to list the thousands of domains, which is arguably a feature, not a bug ;) 

[Daniel E. Markle]

On Thu, Oct 10, 2019 at 03:50:48PM -0400, Ryan Sleevi wrote:
> IIRC, "foo" working at all is Windows-only, and the other platforms require
> explicit whitelisting, which is the intent.

I don't really disagree with this direction, it is certainly our desire to get to fqdn exclusively.

Unfortunately as you accurately represent, transitioning to enforcing fqdn is difficult without some sort of implementation to allow a transition, as we cannot use fqdn at all without the flexibility to implement a transition. Today we have to force Windows Chrome users to use short names only to not break the current environment, we cannot allow fqdn as configuring it breaks short names.

Indeed, it turns out the current implementation is an ironic attempt to get to a better place which actually acts to lock in the current problem for eternity.

[Ryan Sleevi]

What do you do for your non-Windows Chrome users? 

I realize the request is that "DNS short name should be treated the same by all platforms." and a possible answer being "They're not supported unless you enumerate them is how we support them on all platforms" being... well, a thing that meets that criteria, even if less-than-ideal, but I guess understanding how you're handling your non-Windows users today is useful to figuring out solutions that might work for your environment :)

[Daniel E. Markle]

On Thu, Oct 10, 2019 at 05:30:12PM -0400, Ryan Sleevi wrote:
> What do you do for your non-Windows Chrome users?

Honestly this organization doesn't have many Chrome users outside of Windows beyond developers (who already know the workarounds). Firefox and Safari are very common among the general non-Windows userbase, both of which handle the short or fqdn use case (Safari by default, Firefox via the network.negotiate-auth.allow-non-fqdn option). Obviously with an issue like this, these will continue to be popular alternatives.

Since this issue as far as the users are concerned means a lack of support for fqdn kerberized links on Windows Chrome, and a wholesale big bang transition of all links to fqdn is not viable, the fix will most likely be to migrate these new applications from fqdn to short hostnames to match the rest of the environment.

Or just set '*' as the whitelist on Chrome. Interestingly, that's supported but not a more restrictive non-fqdn option. ;-)