Join Log in
Score:1
avatar Server

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

gb flag
kagmole

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?

486
1 + 0
Score:1
Worst avatar Server
jp flag
Worst

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?

0 + 4
gb flag
kagmole
Thank you for your time. It's true that `WWW-Authenticate: Negotiate` won't be sent if the website is not trusted, however adding `my.server.tld` in `network.negotiate-auth.trusted-uris` in Firefox (for example) does not help. But I think I found the issue... Kerberos requires clients to have access to the DC server, which is not the case for me. When it happens, Firefox falls back to Basic and it works, but Edge falls back to NTLM, and we didn't configure NTLM.
0
Reply
cn flag
Greg Askew
@kagmole: `Kerberos requires clients to have access to the DC server, which is not the case for me.` Kerberos tokens must be created by a DC, so there's no Kerberos anything to send from the client, and it isn't falling back to NTLM that's just the token. If the logged on user account were in a domain, it may attempt to send a Kerberos token, but if it isn't the same domain or a trusted domain it would fail.
0
Reply
gb flag
kagmole
@GregAskew thank you for you insights. So if I understand correctly, the `KrbMethodK5Passwd` is still a "Kerberos authentication", but done with an `Authorization Basic` token?
0
Reply
gb flag
kagmole
@Worst you were right. Now I added `https://*.server.tld` in the trusted intranets in the Internet options, and it works for Google Chrome and Microsoft Edge.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.