Autenticação Apache Kerberos: o KDC não tem suporte para o tipo de criptografia

2

Eu postei um novo tópico sobre este problema porque toda a solução que encontrei aqui não funcionou para mim.

Estou tentando configurar um apache2 para autenticar com o Kerberos em um servidor AD2012 por meio de um keytab.

Primeiro, ativei todas as criptografias que pude no AD msDS-EncryptedSupportedTypes

Este é meu cliente (debian) krb5.conf :

[logging]
default = FILE:/var/log/krb5.log

[libdefaults]
default_realm = REALM.LOCAL
kdc_timesync = 1 
ccache_type = 4 
forwardable = true
proxiable = true 
# for testing purpose only
allow_weak_crypto = true

default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
REALM.LOCAL = { 
    kdc = kdc.realm.local
    admin_server = kdc.realm.local
    default_domain = realm.local
}   

[domain_realm]
.realm.local = REALM.local
realm.local = REALM.LOCAL

Aqui está o keytab que eu uso:

klist -kte /etc/apache2/http.keytab

Keytab name: FILE:/etc/apache2/http.keytab
KVNO Timestamp           Principal
---- ------------------- -------------------------------------------------------------
  14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-crc)
  14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-md5)
  14 01/01/1970 01:00:00 HTTP/[email protected] (arcfour-hmac)
  14 01/01/1970 01:00:00 HTTP/[email protected] (aes256-cts-hmac-sha1-96)
  14 01/01/1970 01:00:00 HTTP/[email protected] (aes128-cts-hmac-sha1-96)

Se eu usar o keytab para autenticar com o KDC, tudo funcionará bem:

kinit -Vkt /etc/apache2/http.keytab HTTP/server.realm.local

Authenticated to kerberos v5

klist -e

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/[email protected]
Valid starting 
06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Eu configuro agora um .htaccess para testar a autenticação assim:

AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm REALM.LOCAL
Krb5KeyTab /etc/apache2/http.keytab
KrbServiceName HTTP/server.realm.local
Require valid-user

Adicione quando tentei autenticar Eu tenho isso nos logs:

[debug] src/mod_auth_kerb.c(1939): [client 192.168.4.16] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos

[debug] src/mod_auth_kerb.c(1691): [client 192.168.4.16] Verifying client data using KRB5 GSS-API

[debug] src/mod_auth_kerb.c(1707): [client 192.168.4.16] Client didn't delegate us their credential

[debug] src/mod_auth_kerb.c(1735): [client 192.168.4.16] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.

[debug] src/mod_auth_kerb.c(1138): [client 192.168.4.16] GSS-API major_status:00010000, minor_status:00000000

[error] [client 192.168.4.16] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

Um rastreamento de rede mostrou que o TGS_REQ body está criptografado no AES256, assim como o TGT no PA-DATA . Mas eu recebo KRB5KDC_ERR_ETYPE_NOSUPP em resposta.

Se eu autenticar manualmente para o serviço, obtenho isto:

kinit username

knvo HTTP/[email protected]

klist -e

Valid starting 
06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
06/04/2017 20:35:00 07/04/2017 06:32:09 HTTP/[email protected]
    renew until 07/04/2017 20:32:08, Etype (skey, tkt): des-cbc-crc, des-cbc-md5

Não tenho ideia de onde vem a encriptação DES.

Alguma ideia sobre o que pode estar errado? Como posso ir mais longe nas minhas investigações?

UPDATE: Agora estou suspeitando da conta de serviço do AD com o suporte do DES. Para o que eu li, pode desabilitar qualquer outro algoritmo de criptografia. Eu não tenho acesso ao AD, então não posso testar agora.

    
por Plup 06.04.2017 / 23:46

1 resposta

0

Foi, de fato, devido à ativação do suporte DES na DA. Isso realmente substitui quaisquer outros algoritmos de criptografia.

Portanto, desabilitá-lo na conta de serviço fez com que a negociação funcionasse na AES256.

    
por 10.04.2017 / 19:59