Cliente não encontrado no banco de dados kerberos enquanto obtém inicial

Question

Estou instalando o Squid3 no Ubuntu 14.10 e quero integrá-lo ao ADDS no windows server 2012 usando o kerberos 5. Minha infraestrutura é a seguinte:

Gateway padrão:

192.168.1.1

DNS & Controlador de Domínio (Windows Server 2012):

dc.meudominio.com.br

 address   192.168.1.250
 netmask 255.255.255.0
 gateway 192.168.1.1

Proxy (Ubuntu Desktop 14.10) vmproxy

address 192.168.1.251
netmask 255.255.255.0
gateway 192.168.1.1
dns-search mydomain.com
dns-nameservers 192.168.1.2

Os passos são os seguintes

Etapa 1: verifique a pesquisa de DNS: funciona bem na pesquisa direta e inversa.

Etapa 2: configurar o fuso horário correto no seu servidor proxy:

  $ sudo service ntp stop
  $ sudo ntpdate -b dc.mydomain.com
  $ sudo service ntp start

Etapa 3: instale as bibliotecas cliente Kerberos e defina o nome da região do Kerberos como MYDOMAIN.COM

$ sudo apt-get install krb5-user

Passo 4: Edite o arquivo de configuração do Kerberos /etc/krb5.conf.

[libdefaults]
default_realm = MYDOMAIN.COM    
default_tgs_enctypes = rc4-hmac des3-hmac-sha1    
default_tkt_enctypes = rc4-hmac des3-hmac-sha1

Verifique se a configuração do Kerberos está correta. por

$ kinit [email protected]
$ klist

Etapa: 5 criando um usuário especializado no Active Directory e mapeando esse usuário para o nome principal do Kerberos

c:/> ktpass -princ HTTP/[email protected] -mapuser [email protected] -crypto rc4-hmac-nt -pass P@ssw0rd -ptype KRB5_NT_PRINCIPAL -out krb5.keytab

Passo: 6 Copie o arquivo keytab para /etc/krb5.keytab no vmproxy

Meu /etc/krb5.conf é o seguinte: -

[libdefaults]
default_realm= MYDOMAIN.COM
default_tgs_enctypes=rc4.hmac des3-hmac.sha1
default_tkt_enctypes=rc4.hmac des3-hmac.sha1

[realms]
MYDOMAIN.COM={

kdc=dc.mydomain.com
admin_server=dc.mydomain.com
default_domain=mydomain.com

}

[domain_realm]
.mydomain.com=  MYDOMAIN.COM
mydomain.com=MYDOMAIN.COM

agora ao testar o TGT em dc.mydomain.com como:

$ kinit -V -k -t /etc/krb5.keytab HTTP/[email protected]

diz:

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/[email protected]
Using Keytab: /etc/krb5.keytab
kinit:Client 'HTTP/[email protected]' not found in kerberos database while getting initial credentials

Enquanto estiver usando

$ kinit -k

diz

kinit:Cannot determine realm for host (principal host/vmproxy@)

    

Answer 1

Este comando:

c:/> ktpass -princ HTTP/[email protected] -mapuser [email protected] -crypto rc4-hmac-nt -pass P@ssw0rd -ptype KRB5_NT_PRINCIPAL -out krb5.keytab

Acredito que define HTTP / [email protected] como uma entidade de serviço associada ao usuário [email protected] no AD. O Active Directory normalmente não permite que você se autentique como um principal de serviço (especificamente, não permite que ele adquira um TGT por meio de um AS_REQ); em teoria, os responsáveis pelo serviço devem ser para aceitar as credenciais do usuário, não para autenticar no domínio do kerberos.

Isso é diferente dos KDCs Unix, que normalmente não distinguem entre "principais de serviço" e "entidades de usuário" por padrão, permitindo a autenticação via kinit . No Active Directory, em vez disso, o KDC finge que o principal não existe quando você tenta kinit como ele, o que tende a ser bastante confuso.

Se você puder autenticar com êxito como qualquer outro usuário, tentarei testar se a entidade principal de serviço estiver funcionando executando:

$ kinit some_other_user
$ kvno HTTP/[email protected]

Que acaba de adquirir um ticket de serviço para HTTP/[email protected]. Ou você pode se autenticar como [email protected] em vez do diretor de serviço que você configurou.

Se você precisar de kinit como HTTP/[email protected] diretamente, acho que é possível, mas é necessário alterar o atributo userPrincipalName na conta do AD relevante. Não me lembro no momento como conseguir isso, mas se bem me lembro, você só pode ter um tal UPN; você não pode ter vários nomes principais diferentes, você pode kinit para a mesma conta.