☰

Apache HTTP com Kerberos não funciona com navegadores baseados em Chromium em máquinas fora do domínio

tag-icon • tag-icon authentication apache2 kerberos
Apache HTTP com Kerberos não funciona com navegadores baseados em Chromium em máquinas fora do domínio

Aqui está a configuração do módulo Apache HTTP Kerberos em /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>
# ...

E a configuração do Kerberos em /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

# ...

O servidor web Apache HTTP está instalado em um Debian GNU/Linux 10.

O arquivo keytab foi gerado no my.ad.server.1.tld, que é um Windows Server, com o ktpasscomando.
Com esta configuração, tudo funciona bem no Edge e no Firefox em máquinas Windows do MY.DOMAIN.TLDdomínio.

Meu problema vem de clientes que usam Microsoft Edge (o novo com mecanismo Chromium) ou Google Chrome em máquinas Windows fora do domínio.

Na primeira conexão com o my.server.tld, o navegador recebe os cabeçalhos WWW-Authenticate: Negotiatee WWW-Authenticate: Basic realm="SSO Authentication".

Com o Microsoft Edge, e ao contrário do Firefox, a caixa de diálogo de autenticação que aparece WWW-Authenticate: Negotiatenão é a do navegador, mas uma caixa de diálogo de autenticação do Windows, e não funciona, independentemente do que digitamos.

Após uma primeira tentativa de login fracassada, uma segunda solicitação é emitida pelo navegador, e desta vez ele recebe apenas o WWW-Authenticate: Basic realm="SSO Authentication"cabeçalho. A caixa de diálogo de autenticação do navegador aparece e funciona. A navegação posterior my.server.tldgerará muitas caixas de diálogo de autenticação do Windows em segundo plano. Por exemplo, se houver uma imagem em uma página, será exibida uma caixa de diálogo de autenticação para ela.

Percebi que se a máquina Windows estiver conectada à rede interna MY.DOMAIN.TLDe especificarmos explicitamente o domínio na caixa de diálogo de autenticação do Windows, ela também funcionará bem (ou seja, [email protected]como o nome de usuário).

Com tudo isso em mente, agora me pergunto...

  • É realmente possível fazê-lo funcionar com a caixa de diálogo Autenticação Integrada do Windows em máquinas Windows?
  • Existe uma maneira de "forçar" o domínio a ser usado para autenticação, para anular a necessidade de especificá-lo explicitamente como [email protected]para máquinas fora do MY.DOMAIN.TLDdomínio?

Já tentei adicionar default_domain = my.domain.tlddentro da configuração do Kerberos realm ou obter um Kerberos TGT no kinitservidor Debian GNU/Linux 10 sem sucesso.

Lendo os logs do Apache HTTP a LogLevel trace8cada situação, parece que, enquanto uma caixa de diálogo de autenticação do Windows aparece, um token NTLM é retornado, o que faz com que ele não funcione corretamente.

Quando funciona

Em qualquer lugar com Firefox
OU
Com computador dentro do domínio, rede interna (Edge ou Chrome)
OU
Com um computador fora do domínio, rede externa e usando [email protected](Edge ou 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

Quando não funciona

Com um computador fora do domínio, rede externa (Edge ou 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)

A parte irritante de tudo isso é que ele funciona perfeitamente no Firefox, mas não em navegadores com mecanismo Chromium recente. É porque ele recorre a uma autenticação NTLM em vez de básica?

Responder1

Posso estar errado, mas para mim, o navegador só envia credenciais Kerberos para sites confiáveis. Assim, para computadores do domínio, o navegador considera seu servidor web como um site de "intranet" (= confiável, = pode enviar uma credencial). Mas para os demais, a solicitação de credencial feita pelo seu servidor web é descartada. Então, talvez adicionando o FQDN do seu servidor web nos sites confiáveis ​​dos computadores externos, isso resolverá o problema?

informação relacionada