Apache HTTP mit Kerberos funktioniert nicht mit Chromium-basierten Navigatoren auf Rechnern außerhalb der Domäne

Apache HTTP mit Kerberos funktioniert nicht mit Chromium-basierten Navigatoren auf Rechnern außerhalb der Domäne

Hier ist die Apache HTTP Kerberos-Modulkonfiguration 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>
# ...

Und die Kerberos-Konfiguration 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

# ...

Der Apache-HTTP-Webserver ist auf Debian GNU/Linux 10 installiert.

my.ad.server.1.tldDie Keytab-Datei wurde mit dem Befehl auf einem Windows-Server generiert ktpass.
Mit dieser Konfiguration funktioniert sowohl auf Edge als auch auf Firefox auf Windows-Rechnern in der MY.DOMAIN.TLDDomäne alles einwandfrei.

Mein Problem betrifft Clients, die Microsoft Edge (die neue Version mit Chromium-Engine) oder Google Chrome auf Windows-Rechnern außerhalb der Domäne verwenden.

Bei der ersten Verbindung zu my.server.tldempfängt der Browser die WWW-Authenticate: Negotiateund WWW-Authenticate: Basic realm="SSO Authentication"Header.

Bei Microsoft Edge und anders als bei Firefox ist der angezeigte Authentifizierungsdialog WWW-Authenticate: Negotiatenicht der des Browsers, sondern ein Windows-Authentifizierungsdialog, und dieser funktioniert nicht, egal was wir eingeben.

Nach einem ersten fehlgeschlagenen Anmeldeversuch wird eine zweite Anfrage vom Browser gestellt, und diesmal erhält er nur den WWW-Authenticate: Basic realm="SSO Authentication"Header. Der Authentifizierungsdialog des Browsers wird angezeigt und funktioniert. Bei der weiteren Navigation im Browser my.server.tldwerden dann im Hintergrund viele Windows-Authentifizierungsdialoge generiert. Wenn sich beispielsweise auf einer Seite ein Bild befindet, wird dafür ein Authentifizierungsdialog angezeigt.

Mir ist aufgefallen, dass es auch problemlos funktioniert, wenn die Windows-Maschine mit dem internen Netzwerk verbunden ist MY.DOMAIN.TLDund wir die Domäne im Windows-Authentifizierungsdialog explizit angeben (also [email protected]als Benutzername).

Wenn ich all das oben Genannte im Kopf habe, frage ich mich nun ...

  • Ist es tatsächlich möglich, es mit dem Dialogfeld „Integrierte Windows-Authentifizierung“ auf Windows-Rechnern zum Laufen zu bringen?
  • Gibt es eine Möglichkeit, die Verwendung der Domäne für die Authentifizierung zu „erzwingen“, sodass diese nicht wie [email protected]bei Computern außerhalb der MY.DOMAIN.TLDDomäne explizit angegeben werden muss?

Ich habe bereits erfolglos versucht, es in die Kerberos-Realm-Konfiguration einzufügen default_domain = my.domain.tldoder auf dem Debian GNU/Linux 10-Server ein Kerberos-TGT abzurufen .kinit

Beim Lesen der Apache HTTP-Protokolle LogLevel trace8scheint es in jeder Situation so, als würde, solange ein Windows-Authentifizierungsdialogfeld angezeigt wird, ein NTLM-Token zurückgegeben, wodurch es nicht richtig funktioniert.

Wenn es funktioniert

Überall mit Firefox
ODER
Mit einem Computer innerhalb der Domäne, internes Netzwerk (Edge oder Chrome)
ODER
Mit einem Computer außerhalb der Domäne, einem externen Netzwerk und unter Verwendung von [email protected](Edge oder 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

Wenn es nicht funktioniert

Mit einem Computer außerhalb der Domäne, externes Netzwerk (Edge oder 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)

Das Ärgerliche daran ist, dass es bei Firefox einwandfrei funktioniert, aber nicht bei Browsern mit einer aktuellen Chromium-Engine. Liegt es daran, dass es auf eine NTLM-Authentifizierung zurückgreift, statt auf eine Basisauthentifizierung?

Antwort1

Ich könnte mich irren, aber bei mir sendet der Navigator Kerberos-Anmeldeinformationen nur an vertrauenswürdige Sites. Für Computer in der Domäne betrachtet der Navigator Ihren Webserver also als „Intranet“-Site (= vertrauenswürdig, = kann Anmeldeinformationen senden). Aber für die anderen wird die von Ihrem Webserver gestellte Anforderung von Anmeldeinformationen ignoriert. Vielleicht reicht es also aus, den FQDN Ihres Webservers zu den vertrauenswürdigen Sites der externen Computer hinzuzufügen?

verwandte Informationen