Ingressar um host Linux no Active Directory com realmd e SSSD

Objetivo

Ingressar um host Linux em um domínio do Active Directory para que as contas do AD possam se autenticar e ser resolvidas localmente, usando o realmd para controlar o SSSD em vez de montar o sssd.conf manualmente.

Pré-requisitos

realmd, sssd e os pacotes de suporte a AD/Kerberos instalados (realmd, sssd-ad/sssd-common, adcli, krb5-workstation/krb5-user, conforme a distribuição). Resolução DNS correta do domínio do AD (registros SRV) e sincronização de horário com os controladores de domínio: a autenticação Kerberos falha quando o desvio de relógio ultrapassa uma tolerância pequena. Segundo a documentação do próprio projeto, o SSSD é o daemon cliente que mantém em cache dados de identidade e autenticação de serviços de diretório, incluindo o Active Directory.

Passos

1. Antes de tentar o ingresso, confirme que o domínio é descoberto via DNS: realm discover example.com. Se a saída listar o domínio, seu tipo (kerberos, active-directory) e os pacotes necessários, os registros SRV e a acessibilidade básica estão corretos; se falhar, corrija primeiro o DNS, em vez de ajustar o SSSD.
2. Ingresse no domínio: realm join -U administrator example.com. Esse comando cria a conta de computador no AD, grava o keytab e gera a seção de domínio correspondente no sssd.conf. O realmd gerencia esse arquivo, portanto evite editar manualmente as seções que ele controla.
3. Restrinja os logins logo de início, em vez de deixar o domínio totalmente aberto: use realm permit user@example.com para uma conta ou realm permit -g "Domain Admins@example.com" para um grupo; execute antes realm deny --all se o padrão deve ser ninguém até que haja permissão explícita.
4. Verifique se uma conta específica do AD é resolvida: id user@example.com. Um par UID/GID e as participações em grupos confirmam que o SSSD está resolvendo a identidade corretamente; se isso falhar com um realm discover bem-sucedido, isso aponta para o próprio serviço SSSD.
5. Consulte o estado do SSSD segundo ele mesmo: sssctl domain-list e sssctl domain-status example.com resumem se o domínio está online e quais provedores estão ativos. id_provider/access_provider no sssd.conf gerado mostram quais backends estão de fato configurados.
6. Para uma falha de login que o id não explica, aumente o nível de depuração no sssd.conf (debug_level = 9 na seção correspondente e depois systemctl restart sssd), reproduza a falha e colete os logs com sssctl logs-fetch /tmp/sssd-logs.tar (o caminho do arquivo é obrigatório). O nível 9 é muito verboso e registra detalhes sensíveis; reverta-o depois.

Resultado esperado

id user@example.com retorna um UID/GID resolvido; somente contas ou grupos explicitamente permitidos conseguem se autenticar.

Limites e base de verificação

Verificado com base em realm(8) (discover, join, permit), sssd.conf(5) (id_provider, access_provider) e sssctl(8). Para desfazer: realm leave example.com remove a configuração local do domínio e impede que o SSSD autentique nele; a conta de computador no AD permanece, a menos que se use realm leave --remove -U administrator example.com ou que um administrador de domínio a exclua.