Kerberos no Linux: Juntar Debian e Ubuntu ao AD com SSSD

Uma base de dados de contas local por servidor é o ponto cego habitual de um parque misto. Cada máquina Debian ou Ubuntu fora do domínio guarda os próprios utilizadores, as próprias passwords e as próprias excepções de sudo, e a pergunta mais básica de uma auditoria — quem tinha acesso a quê — obriga a percorrer as máquinas uma a uma. Quando o Active Directory já gere as estações Windows, juntar os servidores Linux ao domínio elimina o problema na origem: as contas passam a viver num só sítio, com o mesmo ciclo de vida das contas Windows.

O SSSD (System Security Services Daemon) é o daemon que faz essa ponte no lado Linux: consulta o Active Directory para resolver utilizadores e grupos, autentica as sessões por Kerberos contra o controlador de domínio e mantém uma cache local para os logins continuarem a funcionar mesmo quando o DC está inacessível ou o portátil anda sem rede. O realmd automatiza a adesão ao domínio: o realm discover encontra o domínio através do DNS e o realm join cria a conta de computador no AD, configura o PAM/NSS e guarda a keytab da máquina, a credencial Kerberos que o sistema usa sem qualquer intervenção manual.

Este guia percorre o caminho completo numa Debian 12 ou Ubuntu 22.04+ contra um domínio já a funcionar (Windows Server AD ou Samba AD DC): requisitos de DNS e de hora, descoberta do domínio, join, configuração do SSSD, testes de identidade e de tickets, sudo para grupos do AD e restrição de quem pode entrar no servidor.

Neste artigo

  1. Instalar os pacotes do cliente AD
  2. Requisitos antes do realm join
  3. Descobrir o domínio com realm discover
  4. Juntar a máquina com realm join
  5. Configurar o sssd.conf
  6. Testar logins, tickets e cache
  7. Sudo para grupos do AD
  8. Restringir quem entra no servidor
  9. Erros Comuns
  10. Checklist
  11. Fontes Oficiais

1. Instalar os pacotes do cliente AD

Tudo o que o guia usa vem dos repositórios oficiais da distribuição — não há repositórios externos nem binários à parte. O pacote realmd traz o comando realm e o daemon realmd, o sssd traz o serviço de identidade, e os restantes completam as peças de autenticação e de integração com o sistema:

sudo apt update
sudo apt install realmd sssd sssd-tools adcli samba-common-bin oddjob-mkhomedir krb5-user

Durante a instalação, o krb5-user pergunta o realm Kerberos por omissão:

The following NEW packages will be installed:
  adcli krb5-config krb5-user libnss-sss libpam-sss oddjob-mkhomedir realmd sssd sssd-tools
…
Default Kerberos version 5 realm: EMPRESA.PT

A resposta é o nome do domínio em MAIÚSCULAS (o realm Kerberos é sempre assim). O papel de cada pacote:

Pacote Função
realmd Descoberta de domínios e join (comandos realm discover/join/leave)
sssd O daemon de identidade e autenticação (NSS + PAM)
sssd-tools Utilitários de diagnóstico e cache (sssctl, sss_cache)
adcli O motor de join que o realmd usa contra o Active Directory
samba-common-bin Ferramentas cliente Samba úteis para testar a integração
oddjob-mkhomedir Cria a home do utilizador no primeiro login via PAM
krb5-user Clientes Kerberos (kinit, klist, kdestroy)

O serviço sssd instala-se activado mas só entra em acção depois do join escrever a configuração do domínio.

2. Requisitos antes do realm join

O SSSD descobre o controlador de domínio por DNS — os registos SRV do domínio apontam para o DC. O /etc/resolv.conf da máquina tem de apontar ao servidor DNS do AD (o próprio DC, na maioria das instalações) e a um servidor público apenas como último recurso:

search empresa.pt
nameserver 10.10.10.10
nameserver 9.9.9.9

Com o DNS correcto, os registos SRV respondem:

dig +short -t SRV _ldap._tcp.empresa.pt
10 100 389 dc1.empresa.pt.

Se o dig devolver vazio, o realm join não vai conseguir encontrar o domínio — corrigir o DNS antes de avançar. Os restantes requisitos:

  • Hostname curto — o join cria uma conta de computador no AD e o nome NetBIOS está limitado a 15 caracteres. Um srv-webproducao (16) falha ou truncam-se os nomes — encurtar antes de juntar. O hostname -f deve devolver o FQDN.
  • Hora sincronizada — o Kerberos baseia-se em marcas de tempo e o KDC rejeita pedidos de clientes com relógio divergente do DC. Apontar o NTP do servidor ao DC (ou à mesma fonte de tempo do AD) evita o erro Clock skew too great no kinit.
  • IP estático — a máquina vai ser objecto de registos DNS no domínio, não pode estar a trocar de endereço.
timedatectl | grep -iE 'synchron|NTP'
System clock synchronized: yes
              NTP service: active

3. Descobrir o domínio com realm discover

O realm discover consulta o DNS por contas dos registos SRV do domínio e devolve o que encontrou:

realm discover empresa.pt
empresa.pt
  type: kerberos
  realm-name: EMPRESA.PT
  domain-name: empresa.pt
  configured: no
  server-software: active-directory
  client-software: sssd

Sem argumentos, o comando tenta descobrir o domínio da configuração DNS local. O campo configured: no confirma que a máquina ainda não pertence ao domínio. realm-name é o realm Kerberos (maiúsculas) e domain-name o domínio DNS. Se a resposta for vazia ou realm: No such realm found, o problema está quase sempre no DNS — rever a secção anterior antes de insistir.

4. Juntar a máquina com realm join

O join precisa de uma conta do AD com permissão para criar contas de computador — o Administrator ou uma conta de serviço dedicada ao provisionamento:

realm join -U Administrator empresa.pt
Password for Administrator:

Um join bem sucedido não escreve nada no ecrã — o silêncio é o sinal de sucesso. O comando fez, por esta ordem: criou a conta de computador no AD, negociou a password da máquina, guardou as chaves Kerberos da conta em /etc/krb5.keytab e escreveu a configuração base do SSSD. A confirmação fica no realm list:

realm list
empresa.pt
  type: kerberos
  realm-name: EMPRESA.PT
  domain-name: empresa.pt
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  …

A keytab é o ficheiro com as chaves Kerberos da conta de computador — é ela que permite à máquina autenticar-se sozinha, e é sobre ela que corre todo o tráfego do SSSD para o AD, num canal cifrado por GSSAPI. O conteúdo:

klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -------------------------------------------------------------------------
   2 host/[email protected]
   2 host/[email protected]
   2RestrictedKrbHost/[email protected]

Várias entradas para a mesma conta (variações de maiúsculas e de nomes de serviço SPN) são o comportamento normal. A keytab muda sempre que a password da conta de computador rodar no AD — o SSSD renegocia e actualiza-a sozinho, não é preciso tocar nela.

5. Configurar o sssd.conf

O join deixa um /etc/sssd/sssd.conf funcional com a secção do domínio. O ponto de partida para ajustar:

[sssd]
domains = empresa.pt
config_file_version = 2
services = nss, pam

[domain/empresa.pt]
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%u
use_fully_qualified_names = False

O que cada opção decide:

  • id_provider = ad — o motor de identidade lê utilizadores e grupos directamente do AD. As opções auth_provider e access_provider exigem que o id_provider seja também ad.
  • access_provider = ad — o controlo de quem pode entrar no host passa a ser decidido pelo AD, incluindo via GPO. Para listas estáticas locais, ver a secção 8.
  • default_shell — a shell a usar quando o AD não devolve nenhum atributo de shell para o utilizador.
  • fallback_homedir = /home/%u — a template de home quando o domínio não especifica uma, com %u substituído pelo nome de login.
  • use_fully_qualified_names = False — os logins passam a aceitar a forma curta (dduarte) em vez de só [email protected]. Com nomes duplicados entre subdomínios, manter True.

O ficheiro tem de pertencer a root e ser legível apenas por root — o SSSD recusa arrancar com permissões mais abertas. Depois de qualquer edição:

chmod 600 /etc/sssd/sssd.conf
systemctl restart sssd

Nota sobre identificadores: por omissão o SSSD gera os UID e GID a partir do atributo objectSID das contas do AD, pelo que o mesmo utilizador tem o mesmo UID em todas as máquinas juntas ao domínio sem nada a configurar. Para usar em vez disso atributos POSIX (uidNumber, gidNumber) mantidos no AD, define-se ldap_id_mapping = False — um caminho de migração, não um pré-requisito.

6. Testar logins, tickets e cache

A primeira prova: o NSS já resolve contas do domínio.

id dduarte
uid=2001129(dduarte) gid=2000513(utilizadores do domínio) grupos=2000513(utilizadores do domínio),2031105(ti-admins)

Com use_fully_qualified_names = False, a forma curta chega. Em domínios com subdomínios, o id [email protected] qualificado funciona sempre, com ou sem essa opção. O GID 513 é o grupo well-known “Domain Users” do AD, traduzido pelo mapeamento de IDs.

A segunda prova: autenticação Kerberos de ponta a ponta contra o KDC.

kinit [email protected]
Password for [email protected]:

klist
Ticket cache: KCM:1000:…
Default principal: [email protected]

Valid starting       Expires              Service principal
09/20/26 11:02:14    09/21/26 11:02:09    krbtgt/[email protected]

O ticket krbtgt é o ticket inicial concedido pelo DC — se existe, a autenticação Kerberos funciona. A terceira prova é o login real por SSH: no primeiro login, o oddjob-mkhomedir cria a home em /home/dduarte.

Duas operações de manutenção que poupam horas de diagnóstico:

sudo sss_cache -E        # invalida a cache toda depois de mudar grupos no AD
sudo sssctl domain-status empresa.pt   # estado da ligação ao DC

Sem o sss_cache -E, uma alteração de membership de grupos no AD pode demorar a aparecer enquanto a cache do SSSD não expirar. Os logs ficam em /var/log/sssd/, um ficheiro por serviço, e o debug_level na secção correspondente do sssd.conf aumenta o detalhe.

7. Sudo para grupos do AD

O id da secção anterior mostrou o grupo do AD ti-admins no identificador da conta. Tornar esse grupo administrador do servidor passa pelo ficheiro sudoers — uma regra por ficheiro em /etc/sudoers.d/, com o nome do grupo qualificado com o domínio:

echo '%[email protected] ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/ad-ti-admins
sudo chmod 440 /etc/sudoers.d/ad-ti-admins
visudo -cf /etc/sudoers.d/ad-ti-admins
/etc/sudoers.d/ad-ti-admins: parsed OK

O prefixo % indica um grupo, o @empresa.pt garante que a regra aponta ao grupo do domínio e não a um grupo local com o mesmo nome. O visudo -cf valida a sintaxe sem abrir editor — corre-se antes de sair da sessão root actual, porque uma regra de sudoers partida pode fechar o acesso administrativo ao servidor. Se o sudo não reconhecer a forma qualificada numa instalação específica, testar a forma curta (%ti-admins) — o comportamento depende da resolução de nomes NSS local. Grupos do AD com espaços no nome exigem escapes (grupo\ com\ espaços) — mais uma razão para criar grupos de administração com nomes simples.

8. Restringir quem entra no servidor

Depois do join, por omissão, qualquer utilizador do domínio consegue autenticar-se no servidor por SSH ou consola — nem todos os servidores devem aceitar todos os utilizadores. A forma mais directa de restringir é o provider simple do SSSD, com uma lista de grupos autorizados:

[domain/empresa.pt]
access_provider = simple
simple_allow_groups = [email protected]
systemctl restart sssd

Com a lista simple_allow_groups preenchida, qualquer utilizador fora dos grupos indicados fica bloqueado no login — a regra aplica-se a grupos do domínio SSSD, incluindo grupos aninhados, que são resolvidos na íntegra antes do acesso ser avaliado. A alternativa quando o access_provider = ad se mantém (por exemplo para herdar o controlo de GPOs do AD) é o ad_access_filter, um filtro LDAP que define quem passa — mais expressivo, mais dispendioso em cada pedido de acesso. Escolher um dos dois modelos por servidor e documentar: misturar as duas abordagens torna o “quem pode entrar onde” indecifrável dentro de um ano.

Erros Comuns

Problema Causa Solução
realm: No such realm found O DNS da máquina não responde com os registos SRV do domínio Apontar o /etc/resolv.conf ao DNS do AD e confirmar com dig +short -t SRV _ldap._tcp.empresa.pt
kinit falha com Clock skew too great Hora da máquina divergente do relógio do DC Sincronizar por NTP com o DC ou com a mesma fonte de tempo do AD
O realm join falha ou a conta fica truncada Hostname com mais de 15 caracteres (limite NetBIOS) Encurtar o hostname com hostnamectl antes de juntar
id/getent não devolve utilizadores do domínio Permissões do sssd.conf erradas ou serviço parado chmod 600 /etc/sssd/sssd.conf e systemctl restart sssd
Mudança de grupos no AD não aparece no Linux Cache do SSSD ainda válida sudo sss_cache -E e repetir o id
A home não é criada no primeiro login oddjob-mkhomedir em falta Instalar o pacote e verificar o PAM (pam-auth-update)

Checklist

  • [ ] /etc/resolv.conf aponta ao DNS do AD e o dig SRV responde
  • [ ] Hostname com 15 caracteres ou menos e IP estático
  • [ ] Hora sincronizada por NTP com o DC
  • [ ] Pacotes instalados (realmd, sssd, sssd-tools, adcli, samba-common-bin, oddjob-mkhomedir, krb5-user) e realm discover com configured: no
  • [ ] realm join concluído e realm list mostra configured: kerberos-member
  • [ ] klist -k /etc/krb5.keytab mostra as chaves da conta de computador
  • [ ] sssd.conf com as opções do domínio e permissões 600
  • [ ] id [email protected] devolve UID e GID
  • [ ] kinit + klist confirmam um ticket do KDC
  • [ ] Regra de sudo do grupo AD validada com visudo -cf
  • [ ] Restrição de login aplicada (simple_allow_groups)

Artigos Relacionados

Fontes Oficiais