Estou tentando configurar o suporte de login do Kerberos (domínio do Windows AD que fornece o kerberos) para estações de trabalho Linux Kubuntu 12.04 na empresa em que estou.
Está quase funcionando completamente, mas não consigo fazer o Kerberos funcionar tanto para logins de máquina (via kdm) quanto para ssh ao mesmo tempo. O problema parece ser que o kdm detecta o domínio totalmente qualificado do host como hostname.domain. e o ssh detecta o domínio totalmente qualificado como sendo hostname.domain (observe a falta de .)
Essa falta ou presença de. no final do domínio usado nas solicitações Kerberos é suficiente para fazer com que a solicitação do ticket falhe com um erro 'Servidor não encontrado no banco de dados Kerberos'. Se eu atualizar/etc/hosts para ter o nome do host totalmente qualificado como hostname.domain. e ingressar no domínio usando logins samba kdm usando kerberos funcionam corretamente, mas os logins ssh falham. Se eu atualizar /etc/hosts para ter o host como hostname.domain, os logins ssh usando kerberos funcionarão, mas o login do kdm falhará.
Não sei por que os dois serviços estão detectando o nome de domínio totalmente qualificado de maneira diferente - fiz pesquisas extensas e não encontrei nenhuma referência a alguém com esse problema ou qualquer opção para forçar um dos serviços para detectar seus nomes de domínio de maneira diferente.
Detalhes técnicos
O uso do Kubuntu 12.04 é um requisito técnico fora do meu controle, portanto, atualizar para uma distribuição posterior não é uma opção neste estágio.
pam_krb5 está sendo usado para fornecer a autenticação Kerberos via pam dns sendo usado não é o DNS do Windows (não é possível trocar de servidor DNS até que o trabalho adicional em outra infraestrutura seja concluído), então os principais detalhes usados para a junção do samba kerberosied ao domínio vêm de /etc/hosts que se parece com
127.0.0.1 hostname.domain. hostname localhost
(o servidor DNS unix em uso possui entradas DNS diretas e reversas corretas para os hosts)
/etc/krb5.conf (que é principalmente a distribuição padrão com os detalhes do domínio e servidores inseridos)
[libdefaults]
default_realm = DOMAIN
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
# samba 3 didn't like the default enc type so overridden to ones it supported
default_tkt_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
[realms]
DOMAIN = {
kdc = dc01.domain
kdc = dc02.domain
admin_server = dc01.domain
}
[domain_realm]
.domain = DOMAIN
[login]
krb4_convert = true
krb4_get_tickets = false
/etc/samba/smb.conf (usado apenas para ingressar no domínio)
[global]
security = ads
realm = WETAFX.CO.NZ
workgroup = WETAFX.CO.NZ
kerberos method = secrets and keytab
client signing = yes
client use spnego = yes
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
pam wise /etc/pam.d/kdm inclui apenas os arquivos pam comuns que possuem as entradas pam_krb5.so padrão, como
auth sufficient pam_krb5.so minimum_uid=1000
que basicamente são retirados diretamente das páginas de manual do pam_krb5.conf
a configuração ssh tem
GSSAPIAuthentication yes
e o resto é o arquivo de configuração ssh padrão do Ubuntu.
Obrigado por qualquer indicação sobre o que está causando essa incompatibilidade no domínio totalmente qualificado detectado entre serviços.
Responder1
Acredito que descobri o que estava acontecendo aqui. Parece que informações extras são mantidas no arquivo keytab depois que o host foi ingressado com/sem . no final do domínio e era daí que vinha o comportamento estranho.
Depois que excluí /etc/krb5.keytab e executei novamente a junção ao domínio que criou um novo keytab que só havia sido configurado com o nome de domínio configurado sem o . no final disso. Nesse ponto, tanto o kdm quanto o ssh funcionaram corretamente com o Kerberos.