Integração do Active Directory do SLES 15 com o SSSD: um guia passo a passo

Para um host típico do SUSE Linux Enterprise Server 15 que precisa que usuários do domínio façam login, a SUSE recomenda o YaST User Logon Management com SSSD como a melhor opção na maioria dos ambientes do Active Directory. O SSSD fornece a identidade do Linux e o caminho de autenticação PAM, enquanto o Active Directory permanece como a fonte para contas e autenticação Kerberos. O Winbind é uma opção melhor quando seu projeto depende de suporte a NTLM ou confiança entre florestas. Se você preferir automação, a SUSE também recomenda o ingresso com o Winbind realmd; trata-se de uma ferramenta de descoberta e associação de domínios, portanto, confirme qual software cliente e política de acesso seu sistema configurará antes de usá-lo em larga escala.

Este passo a passo segue o Guia de Segurança e Reforço do SLES 15 SP7, verificado em 6 de outubro de 2026. Os pacotes de serviços do SUSE podem variar, e as instruções abaixo são um procedimento baseado na documentação, não uma garantia de que os comandos foram executados em seu domínio. Substitua os nomes de domínio e host de exemplo pelos valores do seu ambiente. Teste primeiro em uma máquina SLES não crítica e mantenha uma conta de administrador local disponível caso a autenticação de domínio esteja configurada incorretamente.

Escolha o método de integração mais adequado para a tarefa.

A SUSE descreve a opção YaST com suporte do SSSD como adequada para a maioria das conexões com o Active Directory e indica o Winbind para casos que exigem NTLM ou relações de confiança entre florestas. Esses são pontos de partida práticos, não um substituto para testes de necessidades específicas de aplicativos, como compartilhamento de arquivos Samba, regras sudo, pesquisa de chaves SSH ou conflitos de nomes de domínio. Para um ambiente de login Linux simples, comece com o SSSD, a menos que um requisito documentado indique outra opção.

O que preparar antes de integrar o SLES ao Active Directory

• Um nome de host estável: Escolha o nome de host totalmente qualificado pretendido e certifique-se de que ele seja resolvido de forma consistente em sua rede e no Active Directory. Coordene qualquer convenção de nomenclatura de contas de computador com a equipe de diretório.
• DNS compatível com AD funcionando: O cliente SLES deve consultar um servidor DNS que possa resolver a zona do AD e seus registros de serviço (SRV). Usar apenas um resolvedor público geralmente impede a descoberta de domínio.
• Sincronização de tempo: o Kerberos depende de os relógios do cliente e dos controladores de domínio estarem perfeitamente sincronizados. Confirme a sincronização NTP antes de solucionar problemas com senhas ou SSSD.
• Acesso à rede dos controladores de domínio: Confirme se o firewall e o roteamento permitem os protocolos e portas exigidos pelo design do Active Directory da sua organização, incluindo DNS, Kerberos, LDAP e qualquer tráfego necessário para o catálogo global ou alteração de senha. Não abra todas as portas indiscriminadamente; solicite ao administrador de rede/AD as regras aprovadas.
• Uma identidade de inscrição autorizada: Use uma conta com permissão para adicionar ou reutilizar objetos de computador na unidade organizacional correta. Evite o uso rotineiro de uma conta com privilégios elevados quando houver direitos de ingresso delegados disponíveis.
• Acesso de recuperação: Mantenha um login de administrador local testado e uma forma de acessar o console. Não defina o domínio como a única rota de acesso ao servidor antes de validar o novo caminho de login.

A SUSE menciona especificamente o DNS acessível pelo AD e a hora precisa para o Kerberos. Seu guia observa que um domínio terminado em `.example.com` .localpode entrar em conflito com o DNS multicast em alguns cenários de ingresso. Se o seu AD usa esse sufixo, verifique as implicações para sua versão do SLES e configuração de rede com o administrador do diretório antes de alterar as configurações de nomenclatura ou de resolução.

hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com

Em uma instalação mínima, o hostcomando pode exigir o pacote de utilitários DNS. Essas verificações não comprovam que todos os caminhos de firewall necessários estejam abertos; elas ajudam a detectar problemas comuns de resolução de nomes e de relógio antes do registro.

Ingresse no domínio usando o YaST e o SSSD.

1. Configure o servidor DNS. Abra o YaST e selecione Configurações de Rede e, em seguida, Nome do Host/DNS . Configure o servidor DNS do Active Directory ou um servidor DNS interno que encaminhe a zona do Active Directory corretamente. Salve e confirme se o host consegue resolver o controlador de domínio e os registros de serviço do Active Directory.
2. Abra o Gerenciamento de Logon do Usuário. Na janela principal do YaST, inicie o Gerenciamento de Logon do Usuário e selecione Alterar Configurações . Este é o módulo de autenticação baseado em SSSD descrito no guia do SLES 15 SP7; ele é diferente do módulo de Associação ao Domínio do Windows , que usa o Winbind.
3. Adicione o domínio do Active Directory. Selecione Adicionar Domínio , insira o nome do domínio DNS, como por exemplo corp.example.com, e selecione Microsoft Active Directory para os dados de identidade e autenticação. Certifique-se de que o domínio esteja habilitado. Se a descoberta automática de DNS não for adequada para sua rede, especifique os nomes de host do controlador de domínio aprovados, conforme descrito no guia.
4. Verifique o nome da máquina e o resultado da descoberta. Compare o nome do host local com o nome do computador desejado no Active Directory. Corrija qualquer incompatibilidade antes do registro. O YaST deve detectar um servidor Active Directory e informar que o cliente ainda não está registrado. Se a descoberta falhar, retorne às verificações de DNS, hora, roteamento e firewall, em vez de tentar provedores de autenticação aleatórios.
5. Inscreva-se com uma conta autorizada. Insira as credenciais do Active Directory (AD) permitidas para ingressar na máquina. O YaST pode instalar softwares ausentes durante esse processo. A caixa de diálogo pode oferecer uma opção para sobrescrever a configuração do Samba; habilite-a somente se essa alteração for destinada à sua configuração Samba/AD e preserve a configuração existente primeiro, caso os serviços Samba já estejam em uso.
6. Habilite o comportamento de login desejado. Em Gerenciar Logon de Usuário do Domínio , habilite o logon de usuário do domínio somente após decidir quais contas devem ter acesso. Configure a criação de diretórios home locais, caso os usuários precisem deles. A SUSE documenta as opções `--user` fallback_homedire `--user` override_homedire as mostra /home/%ucomo um possível formato. Em um ambiente com vários domínios, projete um caminho exclusivo e consulte o manual do SSSD antes de confiar apenas em um nome de usuário curto.
7. Salve, revise e teste com um usuário sem privilégios. Aplique as configurações, confirme se o domínio e as opções escolhidas estão corretos e, em seguida, teste com uma conta de domínio normal no console ou por meio do serviço de login que você pretende usar. Não teste apenas com a conta que ingressou na máquina.

Como verificar a entrada no SSSD?

Verifique se o SSSD está ativo, se o NSS consegue resolver uma identidade de domínio conhecida e se um login real é bem-sucedido. Após o usuário de teste fazer login, verifique se há um ticket Kerberos. O SUSE lista klistisso getent passwdentre suas verificações de conexão.

systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist

A string de identidade exata depende das configurações de nomenclatura do SSSD; alguns ambientes usam DOMAIN\userum nome no estilo UPN em vez de um nome no formato padrão. Se getentnenhum registro for retornado, verifique se você está consultando o formato de nome e o domínio configurados e, em seguida, inspecione os logs de serviço.

sudo journalctl -u sssd --since "15 minutes ago"

Uma consulta bem-sucedida por si só não comprova que o usuário pode fazer login, e um ticket Kerberos existente não comprova que todos os aplicativos utilizam a pilha PAM pretendida. Teste uma nova sessão, uma alteração de senha, se necessário, a autorização baseada em grupo e o caminho de login SSH ou de área de trabalho relevante. Confirme se o acesso está restrito às pessoas que você pretendia autorizar.

SSSD ou Winbind: qual deles oferece a melhor relação custo-benefício?

Para a maioria dos clientes SLES que precisam de identidades do Active Directory e logins interativos, o SSSD é a escolha mais simples, com suporte das diretrizes de Gerenciamento de Logon de Usuário da SUSE. Ele integra a pesquisa de identidade e a autenticação PAM, podendo armazenar informações em cache para garantir resiliência quando o diretório estiver temporariamente inacessível. O acesso em cache tem limitações: um primeiro login não pode depender de credenciais em cache, e recursos baseados em diretório ou alterações de senha ainda exigem um controlador de domínio acessível. Estabeleça e teste sua política de login offline em vez de tratar o cache como uma solução completa para interrupções do Active Directory.

Escolha o Winbind quando um requisito depender especificamente da integração de domínio do Samba, NTLM ou relações de confiança entre florestas. Não se trata simplesmente de uma alternativa ao SSSD: cada caminho utiliza daemons e componentes NSS/PAM diferentes. Documente qual serviço é responsável pelas pesquisas de domínio e logins e evite misturar edições manuais antigas de PAM/NSS com configurações gerenciadas pelo YaST.

Utilize realmdquando um fluxo de trabalho repetível no shell for importante. O Guia de Administração de Armazenamento do SLES 15 SP7 da SUSE documenta realm discover --verbosea descoberta baseada em DNS, realm join --verboseo registro e realm permitas permissões de login. Verifique qual software cliente está selecionado e qual configuração do SSSD é gerada em sua versão. Evite acesso amplo do tipo "permitir a todos" em produção, a menos que essa seja uma política explícita.

Falhas comuns e a próxima verificação

• A descoberta de domínio não retorna nada: verifique o servidor DNS do cliente e o registro SRV do Active Directory e, em seguida, confirme se o host consegue acessar os controladores de domínio listados.
• Erros de Kerberos apesar da senha correta: verifique a sincronização da hora do sistema, o nome DNS usado para o controlador de domínio e se a conta do computador está habilitada e nomeada corretamente.
• O usuário resolve o problema, mas não consegue fazer login: confirme se o login de domínio está habilitado no YaST, verifique as restrições de acesso e o status da conta no Active Directory e revise os logs do SSSD/PAM.
• O login funciona, mas o diretório inicial está faltando: confirme se a criação do diretório inicial está habilitada e se o caminho configurado é válido e exclusivo para o usuário.
• Uma tentativa de ingresso no domínio falha após tentativas anteriores: verifique se há objetos de computador obsoletos, nomes de host duplicados, configurações residuais do Winbind ou do NSS/PAM manual e senhas de máquina incompatíveis. Coordene a limpeza com o administrador do Active Directory antes de excluir um objeto de computador ou limpar os dados locais do SSSD.

Quando você deve parar e escolher uma abordagem diferente?

Antes de implementar a política, faça uma pausa se o seu ambiente depender de comportamento de confiança entre florestas, NTLM, função de servidor Samba, várias florestas com nomes de usuário curtos sobrepostos ou regras de acesso complexas que as configurações básicas do YaST não contemplam. Essas condições podem alterar o provedor preferencial ou exigir configuração adicional do SSSD. Teste-as com contas representativas e serviços reais em um ambiente de teste e mantenha o login de recuperação até que a política seja comprovada.

Resumindo: Para uma estação de trabalho ou servidor SLES 15 SP7 padrão que precise de identidades e logins do Active Directory, comece com o caminho de Gerenciamento de Logon de Usuário do YaST, com suporte do SSSD. Primeiro, configure corretamente o DNS, o horário, os nomes de host e as permissões de ingresso; em seguida, verifique a pesquisa de nomes, o Kerberos, o login PAM e o escopo de acesso. Selecione o Winbind para os requisitos específicos de Samba, NTLM ou entre florestas identificados pela SUSE e use-o realmdquando seu fluxo de trabalho de linha de comando se adequar melhor ao seu processo operacional.

Fontes: Guia de Segurança e Reforço de Segurança do SUSE SLES 15 SP7: suporte ao Active Directory ; Guia de Administração de Armazenamento do SUSE SLES 15 SP7: realmd ; SUSE SLES 15 SP7: clientes de autenticação e SSSD ; Notas de Versão do SUSE SLES 15 SP7 .