Conteúdo:

Introdução

Os servidores Linux da Lambda3 sempre tiveram contas locais. Cada pessoa que fosse administrar tinha sua própria conta na máquina. Quando a pessoa saia da empresa, outra pessoa entrava em cada servidor e excluía a conta de quem saiu. Não dava tanto trabalho, afinal, temos poucos servidores, mas, comparando com o suporte que temos para servidores Windows, era muito ruim. Neste post, vou mostrar como adicionar um servidor Linux ao Active Directory e permitir logar nele usando credenciais de domínio.

Nós temos um diretório central de usuários baseado no Active Directory (AD). Lá estão cadastrados todos os usuários da Lambda3, assim como grupos. Por exemplo, o AD possui um grupo padrão chamado “Domain Admins”, e neste grupo estão os administradores do domínio, que é como o AD chama a unidade lógica raiz de toda a organização (simplificando bastante). Nos servidores Windows, os domain admins podem logar nos servidores, os outros usuários não podem. Várias políticas também se aplicam aos usuários, como expiração de senha, complexidade de senha etc. Facilita muito a gestão de usuários, e, segundo a algumas estimativas que li recentemente, mais de 90% do mercado corporativo usa o AD, tornando-o talvez o produto da Microsoft com maior penetração neste mercado. Ele também é parte importante da estratégia de nuvem da Microsoft, que oferece sincronização com os serviços do Microsoft 365, e claro, do Azure Active Directory. Na Lambda3, ele é a base de toda nossa suite de colaboração, os usuários e grupos definidos no AD e no Azure AD definem as contas das pessoas e quem pode fazer o quê. Ele é muito importante na nossa estrutura, assim como na de várias empresas.

Mas não funcionava para gerenciar as máquinas Linux. Estes servidores não estavam registrados no AD (que possui um diretório para dispositivos, também), e o login de admins de domínio não funcionava neles.

Recentemente, instalando um Ubuntu, descobri a opção dada durante o processo de instalação de registrar o computador no AD. Tentei usar a opção e ela não funcionou, mas fui pesquisar no que ela se baseava, e sua base é um projeto chamado SSSD (System Security Services Daemon). Com algum esforço descobri que o SSSD funciona, e funciona bem, e consegui colocar ele pra rodar nos nossos servidores, registrando-os no nosso AD, e permitindo login e até integração das chaves SSH com o AD para login remoto.

O problema é que achei a documentação muito ruim. Parece que um sponsor importante do projeto é a Red Hat, e uma boa parte da sua documentação está atrás de um paywall. A documentação no próprio site do SSSD não cobre todas as opções, e você fica refém de ficar procurando soluções online em sites diversos, fazendo tentativas pra ver se algo funciona, o que pode ser perigoso. Não faça isso em produção, fica a dica. Este post visa cobrir um pouco deste gap, mostrar como fazer uma instalação simples, sem grande complexidade, mas que funciona bem. É possível que tenhamos deixado passar alguma oportunidade, se você sabe algo que não dissemos aqui, por favor, comente para que possamos evoluir.

Eu desenvolvi todo o trabalho em uma máquina virtual local com Ubuntu, validei que funcionava, e então apliquei nos nossos servidores. Hoje temos servidores Ubuntu, Debian e CentOS. A instalação varia um pouco para cada um, mas são razoavelmente parecidas. Então vamos lá.

Antes de começar, vou deixar aqui duas referências que usei para entender o básico (ambos em inglês, infelizmente):

• Início rápido do SSSD
• Docs do Ubuntu para SSSD

Instalando no Ubuntu

Preparando

Você vai precisar de:

• Um usuário administrador no Linux que quer registrar no domínio.
• Um usuário capaz de registrar máquinas no domínio. Por padrão, todo usuário consegue fazer isso.
• Os dados do domínio: FQDN.
• Capacidade de alterar atributos de um usuário no domínio (para registro da chave SSH – opcional)

Adicionando o servidor ao domínio

Instale os pacotes necessários. No Ubuntu são estes:

sudo apt install sssd-ad sssd-tools realmd adcli krb5-user

No CentOS são estes:

sudo yum install sssd-ad sssd-tools realmd adcli krb5-workstation samba-common-tools

Durante o processo o instalador vai perguntar o domínio, coloque o FQDN, em letras maiúsculas. Por exemplo se o domínio for dominio.com.br informe DOMINIO.COM.BR.

Teste o acesso ao domínio com o seguinte comando:

sudo realm -v discover <FQDN do domínio, maiúsculo>

Se tiver sucesso, adicione a máquina do domínio. Você vai precisar informar um usuário capaz de registrar a máquina do domínio e o domínio em si. O nome do usuário não precisa conter o nome do domínio, basta o nome do usuário. Assim, não use DOMINIO\usuario nem [email protected], somente usuario.

sudo realm join -U <usuário> -v <fqdn_domínio>

A partir deste comando qualquer pessoa do domínio conseguirá logar na máquina e a máquina estará registrada no domínio. Mas vamos restringir isso em seguida.

Por padrão, o usuário, ao logar, não terá um home directory criado. Para resolver isso, rode o comando abaixo.

sudo pam-auth-update --enable mkhomedir

Observações:

• Lembro que no CentOS não precisei rodar o comando para habilitar a criação do home directory pro usuário, isso aconteceu automaticamente.
• É importante notar que nem todo Linux possui esse comando, notei que as versões antigas do Debian (e provavelmente do Ubuntu) não o possuem. Nesse caso, atualize, e temporariamente crie o home dir manualmente com sudo mkhomedir_helper <usuário>.

Com isso, você já pode testar o acesso ao domínio:

USER=<usuario>@<FQDN do domínio, minúsculo>
getent passwd $USER
groups $USER

Habilitando root e limitando o acesso ao servidor

Por padrão os domain admins não terão capacidade de sudo. Você poderia colocá-los manualmente no arquivos de sudoers, mas dá para colocar com seu grupo. Rode sudo visudo e no arquivo de sudoers coloque, no final (trocando pelo FQDN correto, minúsculo):

# Allow domain admins
"%domain admins@<FQDN do domínio>" ALL=(ALL:ALL) ALL

Para impedir que usuários não admins se loguem no servidor, precisamos alterar uma configuração do SSSD. Altere o arquivo de configuração do sssd que fica em /etc/sssd/sssd.conf.

Coloque estas configurações a seguir sob a seção [domain/<FQDN do domínio>].

# comente esta linha:
# access_provider = ad
access_provider = simple
simple_allow_groups = Domain Admins@<FQDN do domínio, maiúsculo>

Isso é uma conveniência, e não é necessário. No mesmo arquivo, sob a seção [sssd], adicione:

default_domain_suffix = <FQDN do domínio, minúsculo>

Reinicie o SSSD para aplicar as configurações:

sudo systemctl restart sssd

Para testar um login, rode, por exemplo:

USER=<usuario>@<FQDN do domínio, minúsculo>
sudo login $USER
klist #vai exibir os tokens do Kerberos do usuário

Tente logar com um usuário não admin, você deverá receber um erro.

Teste de outra máquina o acesso via ssh, você terá que informar a senha de domínio:

USER=<usuario>@<FQDN do domínio, minúsculo>
ssh $USER@nomedoservidor

Na próxima sessão veremos como conectar via SSH usanco uma chave pública cadastrada no AD.

Habilitando registro da chave SSH no domínio

É possível armazenar as chaves públicas do SSH de um usuário no Active Directory. A maioria dos artigos que li indicam para fazê-lo no atributo altSecurityIdentities. Lá, você coloca exatamente a chave pública que ficaria guardada em um arquivo id_rsa.pub.

Para criar a chave pública para o usuário no AD, utilize o Active Directory Users and Computers. Habilite o modo avançado em View > Advanced Features. Encontre o usuário e abra os detalhes. Na aba Attribute Editor, procure o atributo altSecurityIdentities, abra-o, e inclua a chave. Você pode incluir mais de uma chave se precisar. Clique em OK.

Ou, via PowerShell:

# primeiro garanta que o usuário está certo, e que a consulta retorna só o usuário que você quer alterar
Get-ADUser -SearchBase 'DC=<dominio>,DC=com,DC=br' -Filter "UserPrincipalName -eq '<usuário>@<FQDN usuário>'"
# em seguida, execute a alteração:
Get-ADUser -SearchBase 'DC=<dominio>,DC=com,DC=br' -Filter "UserPrincipalName -eq '<usuário>@<FQDN usuário>'" | % { Set-ADUser $_ -Add @{'altSecurityIdentities'='<chave pública do SSH>'} }

Lembre-se de executar um PowerShell de administrador. Você vai precisar ter instalado o módulo ActiveDirectory e ter permissões para executar o comando.

Para configurar o SSSD e o SSH, altere o arquivo de configuração do sssd que fica em /etc/sssd/sssd.conf. Coloque estas configurações a seguir sob a seção [domain/<FQDN do domínio>]:

ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities
cache_credentials = True

No mesmo arquivo, sob a seção [sssd], adicione ssh aos serviços. Notei que nem toda distro isso foi necessário, mas em algumas isso não funcionava sem essa configuração:

services = nss, pam, ssh

Reinicie o SSSD para aplicar as configurações:

sudo systemctl restart sssd

Verifique se a conexão com o AD está funcionando. Com um usuário com a chave pública no atributo altSecurityIdentities do AD, rode:

USER=<usuario>@<FQDN do domínio, minúsculo>
sss_ssh_authorizedkeys $USER

Esse comando deve exibir a chave pública do usuário que você cadastrou no atributo altSecurityIdentities do AD. Vários problemas podem acontecer nesse passo. Nesse caso, revise as configurações.

Somente se o passo anterior funcionou, adicione no arquivo /etc/ssh/sshd_config:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root

Reinicie o serviço de SSH para aplicar as configurações:

sudo systemctl restart sshd

O nome do serviço também pode ser ssh, dependendo da distro e versão.

Sem quebrar sua conexão ssh atual, teste de outra máquina o acesso via ssh:

USER=<usuario>@<FQDN do domínio, minúsculo>
ssh $USER@nomedoservidor

Resolvendo problemas

Erros ao rodar sudo realm join

Em caso de erro PackageKit not available, há duas opções, sendo a primeira a preferível:

1. Instale o packagekit: apt install packagekit
2. Adicione --install=/ ao final do comando.

Em caso de erro de DNS, verifique se consegue se conectar nos controladores de domínio. Se não, resolva o problema de conectividade. Se sim, crie (ou altere se existir) o arquivo /etc/krb5.conf com o conteúdo, e rode o comando novamente:

[libdefaults]
  rdns = false

Em caso de erro An invalid name was supplied (o erro completo é):

 ! Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success)
adcli: couldn't connect to <fqdn> domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success)
 ! Insufficient permissions to join the domain

Você não vai conseguir usar o DNS reverso para resolver nomes. Para isso, crie (ou altere se existir) o arquivo /etc/krb5.conf com o conteúdo, e rode o comando novamente:

[libdefaults]
  rdns = false

Veja mais informações sobre essa flag.

Erros diversos

Habilite os logs. Altere o arquivo de configuração do sssd que fica em /etc/sssd/sssd.conf. Na seção correspondente, adicione:

debug_level=6

O nível vai até 9, pelo que entendi.

Nem todas as seções estão explícitas, por exemplo, para logs de SSH, você vai precisar criar a seção [ssh], e colocar a instrução acima sob ela.

Os logs ficam no diretório /var/log/sssd/. Por exemplo, os logs de SSH ficam no arquivo /var/log/sssd/sssd_ssh.log. Lá você terá os logs específicos do SSSD, logs de um domínio (com arquivo sob o nome sssd_<fqdn>.log), e dos serviços, como ssh, pam e nss.

Próximos passos

Li que seria possível, via GSSAPI e Kerberos, autenticar via SSH de um servidor para outro. Muitos relatos de que é possível, testei algumas configurações mas não consegui fazer funcionar. É algo que quero tentar no futuro.

Ainda no assunto de chaves SSH, é possível cadastrar no domínio as chaves públicas dos servidores, evitando cadastros e checagem manuais para o arquivo ~/.ssh/known_hosts. Parece ser razoavelmente simples de fazer.

O SSSD também oferece uma integração com políticas de domínio. Isso foi desabilitado quando alteramos o provedor de acesso no arquivo de configuração (nesta linha: access_provider = simple). Algumas destas configurações são interessantes e é algo que quero explorar mais.

E aí, já conhecia o SSSD? Usa na empresa? Comente abaixo!