“O KDC não tem suporte para o tipo de criptografia” ao configurar a confiança entre territórios entre o MIT Kerberos e o Active Directory

5

Atualmente, estou configurando um ambiente no qual tenho um conjunto de máquinas Solaris e Linux, usando um domínio dedicado do Krberos 5 (MIT, no Solaris 11, krb5-config --version returns: Solaris Kerberos (based on MIT Kerberos 5 release 1.6.3) ). Também temos um servidor do Active Directory (Windows 2003) para um domínio separado.

Meu objetivo é ter todos os usuários no servidor do AD e os principais hosts / nnn, nfs / nnn e cifs / nnn no território baseado em MIT. Estou tentando configurar a confiança entre domínios entre esses dois domínios.

Suponha o seguinte:

  • Domínio Unix: EXAMPLE.COM
  • Domínio do AD: AD.EXAMPLE.COM

Configurei a confiança entre domínios do AD de acordo com o Documentação da Microsoft , com confiança bidirecional.

O que acontece é que a autenticação entre domínios apenas funciona em uma direção. Do AD ao Unix funciona:

# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
[email protected]: kvno = 1

Mas, o contrário não acontece, e me dá uma mensagem de erro: O KDC não tem suporte para o tipo de criptografia enquanto obtém credenciais para [email protected]

# kinit [email protected]
Password for [email protected]: 
root@clienttest2:~# kvno [email protected]
kvno: KDC has no support for encryption type while getting credentials for [email protected]

Note que tentei todo tipo de coisas diferentes. Alguns desses são:

  • Configurou as chaves de região cruzada no lado do Unix para usar rc4-hmac apenas, com o efeito de que a chamada para kvno nem mesmo conseguirá encontrar o KDC no lado da Microsoft.
  • Adicionadas entradas default_tkt_enctypes e default_tgs_enctypes para forçar o uso de rc4-hmac . Isso foi necessário apenas para fazer a autenticação de login no AD funcionar.

Qual poderia ser a causa disso e como posso descobrir o que está realmente acontecendo? Em particular, seria muito útil saber exatamente qual tipo de criptografia ele está tentando usar, para o qual o KDC não tem suporte. Também seria útil saber qual KDC enviou o erro.

Para completar, aqui está o conteúdo do arquivo krb5.conf :

[libdefaults]
    default_realm = EXAMPLE.COM
    allow_weak_crypto = true
        verify_ap_req_nofail = false
        default_tkt_enctypes = rc4-hmac
        default_tgs_enctypes = rc4-hmac

[realms]
    EXAMPLE.COM = {
        kdc = unix-server.example.com
        admin_server = unix-server.example.com
    }
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        admin_server = ad-server.ad.example.com
    }

[domain_realm]
    .example.com = EXAMPLE.COM
    .ad.example.com = AD.EXAMPLE.COM

[capaths]
    EXAMPLE.COM = {
        AD.EXAMPLE.COM = .
    }
    AD.EXAMPLE.COM = {
        EXAMPLE.COM = .
    }

[logging]
    default = FILE:/var/krb5/kdc.log
    kdc = FILE:/var/krb5/kdc.log
    kdc_rotate = {
        period = 1d
        versions = 10
    }

[appdefaults]
    kinit = {
        renewable = true
        forwardable = true
    }
    
por Elias Mårtenson 24.10.2012 / 08:51

2 respostas

3

Eu resolvi o problema. Estou postando uma resposta aqui no caso de alguém enfrentar o mesmo problema.

A solução foi muito simples. Eu precisava ter certeza de que os principais de autenticação entre domínios foram criados com um único tipo de codificação, do tipo rc4-hmac :

addprinc -e rc4-hmac krbtgt/[email protected]
addprinc -e rc4-hmac krbtgt/[email protected]

Tanto quanto eu posso dizer, o que acontece é que o MIT KDC usa o tipo de codificação mais seguro ao enviar o ticket para o servidor AD. O servidor do AD não pode manipular essa codificação e, portanto, respondeu com o erro de que o tipo de criptografia não é suportado. Por ter apenas um único tipo de codificação para os principais, o servidor MIT usará esse tipo ao conversar com o servidor do AD.

    
por 31.10.2012 / 14:16
0

Eu resolvi isso verificando o erro no diário. O erro declarado:
- Os registros começam em Ter 2018-05-22 13:03:55 UTC, finalizar em Mon 2018-06-18 10:41:01 UTC. -
Jun 18 10:40:55 nlxxp1 realmd [1609]: Resolvendo: _ldap._tcp.local.domain
18 de junho às 10:40:55 nlxxp1 realmd [1609]: * Realizando a pesquisa LDAP DSE em: 10.x.x.1
18 de junho 10:40:55 nlxxp1 realmd [1609]: * Realizando a pesquisa LDAP DSE em: 10.x.x.30
18 de junho às 10:40:55 nlxxp1 realmd [1609]: * Realizando a pesquisa LDAP DSE em: 10.x.x.60
Jun 18 10:40:55 nlxxp1 realmd [1609]: * Descoberto com sucesso: local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]: * Assumindo que pacotes estão instalados
Jun 18 10:41:00 nlxxp1 realmd [1609]: * LANG = C / usr / sbin / adcli join --verbose --domínio local.dominio --domínio-real LOCAL.DOMAIN --domain-controller 10.xx1 --login-type user --login-user localuser --stdin-password
Jun 18 10:41:00 nlxxp1 realmd [1609]: * Usando nome de domínio: local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]: * Nome da conta de computador calculado de fqdn: NLXXP1
Jun 18 10:41:00 nlxxp1 realmd [1609]: * Usando domínio reino: local.domain
Jun 18 10:41:00 nlxxp1 realmd [1609]: * Enviando pings de netlogon para o controlador de domínio: cldap: //10.x.x.1
Jun 18 10:41:01 nlxxp1 realmd [1609]: * Informações sobre NetLogon recebidas de: dc.local.domain
Jun 18 10:41:01 nlxxp1 realmd [1609]: * Escreveu o snippet krb5.conf para /var/cache/realmd/adcli-krb5-QudocS/krb5.d/adcli-krb5-conf-8Gyp0B
18 de junho 10:41:01 nlxxp1 realmd [1609]:! Não foi possível autenticar como: [email protected]: o KDC não tem suporte para o tipo de criptografia 18 de junho 10:41:01 nlxxp1 realmd [1609]: adcli: não pôde se conectar ao domínio local.domain: não foi possível autenticar como: [email protected]: o KDC não tem suporte para o tipo de criptografia. 18 de junho 10:41:01 nlxxp1 realmd [1609]:! Falha ao ingressar no domínio

Meu domínio é um domínio misto com um DC de 2003.
Depois que eu entrei no DNS e mudei o registro _ldap._tcp.local.domain do CD 2003 (eu dei a ele um peso pesado de 400) ele pegou um novo (2012R2 DC) que foi capaz de juntar o servidor ao domínio. br>
Eu acho que o tipo de criptografia usado não era suportado pelo DC 2003.

    
por 18.06.2018 / 13:43