Apache HTTP with Kerberos not working with Chromium-powered navigators on machines outside of domain

Here is the Apache HTTP Kerberos module configuration in /etc/apache2/sites-available/my.server.tld.conf:

# ...
<Location />
  Authname "SSO Authentication"
  AuthType Kerberos
  KrbAuthRealms MY.DOMAIN.TLD
  KrbServiceName HTTP/[email protected]
  Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  Require valid-user
</Location>
# ...

And the Kerberos configuration in /etc/krb5.conf:

[libdefaults]
  default_realm = MY.DOMAIN.TLD

# ...

[realms]
  MY.DOMAIN.TLD = {
    kdc = my.ad.server.1.tld
    kdc = my.ad.server.2.tld
    admin_server = my.ad.server.1.tld
  }

# ...

[domain_realm]
  friendly.domain.tld = MY.DOMAIN.TLD
  .friendly.domain.tld = MY.DOMAIN.TLD

# ...

The Apache HTTP web server is installed on a Debian GNU/Linux 10.

The keytab file was generated on my.ad.server.1.tld, which is a Windows Server, with the ktpass command.
With this configuration, everything works fine on both Edge and Firefox on Windows machines in the MY.DOMAIN.TLD domain.

My issue comes from clients that use Microsoft Edge (the new one with Chromium engine) or Google Chrome on Windows machines outside the domain.

On the first connection to my.server.tld, the browser receive the WWW-Authenticate: Negotiate and WWW-Authenticate: Basic realm="SSO Authentication" headers.

With Microsoft Edge, and unlike Firefox, the authentication dialog that pops up with WWW-Authenticate: Negotiate is not the one from the browser, but a Windows authentication dialog, and it does not work, whatever we types.

After a first failed login attempt, a second request is issued by the browser, and this time he only receives the WWW-Authenticate: Basic realm="SSO Authentication" header. The brower authentication dialog pops up, and it works. Further navigation inside my.server.tld will then generate a lot of Windows authentication dialog in the background. For example, if there is an image on a page, it will show an authentication dialog for it.

I noticed that if the Windows machine is connected in the internal network of MY.DOMAIN.TLD and we explicitely specify the domain in the Windows authentication dialog, it works fine as well (i.e. [email protected] as the username).

With all the above in my mind, I now wonder...

• Is it actually possible to make it work with the Integrated Windows Authentication dialog on Windows machines?
• Is there a way to "force" the domain to be used for the authentication, to nullify the need to specify it explicitely like [email protected] for machines outside the MY.DOMAIN.TLD domain?

I already tried to add default_domain = my.domain.tld inside the Kerberos realm configuration or to obtain a Kerberos TGT with kinit on the Debian GNU/Linux 10 server without success.

Reading the logs of Apache HTTP with LogLevel trace8 with every situtation, it looks like as long as a Windows authentication dialog pops up, an NTLM token is returned, which makes it not work correctly.

When it works

Anywhere with Firefox
OR
With a computer inside the domain, internal network (Edge or Chrome)
OR
With a computer outside the domain, external network and using [email protected] (Edge or Chrome) :

mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1754): GSS-API token of length 180 bytes will be sent back
mod_authz_core.c(820): AH01626: authorization result of Require valid-user : granted
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: granted

When it doesn't work

With a computer outside of domain, external network (Edge or Chrome):

mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1763): Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

The annoying part of all this is that it works perfectly on Firefox, but not browsers with a recent Chromium engine. Is it because it falls back to an NTLM authentication instead of a Basic one?

Solution 1:

I might be wrong, but for me, the navigator only sends Kerberos credential to trusted sites. So, for computers in the domain, their navigator consider your webserver as an "intranet" site (= trusted, = can send a credential). But for the others, the request for credential made by your webserver is discared. So, perhaps by adding the FQDN of your webserver in the trusted sites of the external computers, it will do the trick?