☰

Apache HTTP con Kerberos no funciona con navegadores con tecnología Chromium en máquinas fuera del dominio

tag-icon • tag-icon authentication apache2 kerberos
Apache HTTP con Kerberos no funciona con navegadores con tecnología Chromium en máquinas fuera del dominio

Aquí está la configuración del módulo Apache HTTP Kerberos en /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>
# ...

Y la configuración de Kerberos en /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

# ...

El servidor web Apache HTTP está instalado en un Debian GNU/Linux 10.

El archivo keytab se generó en my.ad.server.1.tld, que es un servidor Windows, con el ktpasscomando.
Con esta configuración, todo funciona bien tanto en Edge como en Firefox en máquinas con Windows del MY.DOMAIN.TLDdominio.

Mi problema proviene de clientes que usan Microsoft Edge (el nuevo con motor Chromium) o Google Chrome en máquinas con Windows fuera del dominio.

En la primera conexión a my.server.tld, el navegador recibe los encabezados WWW-Authenticate: Negotiatey .WWW-Authenticate: Basic realm="SSO Authentication"

Con Microsoft Edge, y a diferencia de Firefox, el cuadro de diálogo de autenticación que aparece WWW-Authenticate: Negotiateno es el del navegador, sino un cuadro de diálogo de autenticación de Windows, y no funciona, escribamos lo que escribamos.

Después de un primer intento fallido de inicio de sesión, el navegador emite una segunda solicitud y esta vez solo recibe el WWW-Authenticate: Basic realm="SSO Authentication"encabezado. Aparece el cuadro de diálogo de autenticación del navegador y funciona. Una navegación adicional en my.server.tldel interior generará una gran cantidad de cuadros de diálogo de autenticación de Windows en segundo plano. Por ejemplo, si hay una imagen en una página, se mostrará un cuadro de diálogo de autenticación.

Noté que si la máquina con Windows está conectada a la red interna MY.DOMAIN.TLDy especificamos explícitamente el dominio en el cuadro de diálogo de autenticación de Windows, también funciona bien (es decir, [email protected]como nombre de usuario).

Con todo lo anterior en mente, ahora me pregunto...

  • ¿Es realmente posible hacer que funcione con el cuadro de diálogo Autenticación integrada de Windows en máquinas con Windows?
  • ¿Hay alguna manera de "forzar" el uso del dominio para la autenticación, para anular la necesidad de especificarlo explícitamente, como en el caso [email protected]de las máquinas fuera del MY.DOMAIN.TLDdominio?

Ya intenté agregar default_domain = my.domain.tlddentro de la configuración del reino Kerberos u obtener un TGT de Kerberos en kinitel servidor Debian GNU/Linux 10 sin éxito.

Al leer los registros de Apache HTTP en LogLevel trace8cada situación, parece que siempre que aparece un cuadro de diálogo de autenticación de Windows, se devuelve un token NTLM, lo que hace que no funcione correctamente.

cuando funciona

En cualquier lugar con Firefox
O
Con una computadora dentro del dominio, red interna (Edge o Chrome)
O
Con una computadora fuera del dominio, red externa y usando [email protected](Edge o 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

cuando no funciona

Con una computadora fuera del dominio, red externa (Edge o 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)

Lo molesto de todo esto es que funciona perfectamente en Firefox, pero no en navegadores con un motor Chromium reciente. ¿Es porque recurre a una autenticación NTLM en lugar de una básica?

Respuesta1

Puede que me equivoque, pero en mi caso, el navegador sólo envía credenciales Kerberos a sitios de confianza. Entonces, para las computadoras en el dominio, su navegador considera su servidor web como un sitio de "intranet" (= confiable, = puede enviar una credencial). Pero para los demás, se descarta la solicitud de credencial realizada por su servidor web. Entonces, ¿tal vez agregar el FQDN de su servidor web en los sitios confiables de las computadoras externas funcione?

información relacionada