Conectar o RHEL ou qualquer outra máquina Linux diretamente ao Active Directory da Microsoft.

Gerenciar o acesso a sistemas na sua rede pode ser desafiador. Já vi administradores criarem todos os usuários em todas as máquinas, outros que compartilham contas usando chaves de SSH ou até mesmo senhas, e outros ainda que usam vinculação do LDAP (às vezes com a infraestrutura existente do Active Directory e, às vezes, com um domínio separado), o que exige que eles escrevam consultas do LDAP para filtrar o acesso.

Todos esses métodos dificultam o gerenciamento do acesso às máquinas e exigem que os administradores sejam informados quando alguém entra ou sai de uma equipe. Contas compartilhadas podem inutilizar os registros, já que todos terão o mesmo nome de usuário. E não devo ser o único a ter uma experiência ruim com o RH informando às equipes técnicas quando há uma mudança em uma equipe. No entanto, há uma solução para tudo isso que funciona bem e se integra a configurações empresariais comuns.

A maioria das empresas que conheci tem algum tipo de sistema ERP que cria, desativa ou exclui automaticamente contas de usuário no Microsoft Active Directory (AD), para que você possa aproveitar o trabalho que outras pessoas já estão fazendo. Por exemplo, o SSSD pode se conectar diretamente ao AD.

Se você já configurou um servidor de autenticação para o Linux que tinha confiança no AD, você fez com que o SSSD se comunicasse com seus servidores AD. Se você observar como uma relação de confiança funciona, o servidor de autenticação que você configurou retornará uma referência aos servidores AD, fazendo com que o SSSD consulte seus servidores AD diretamente. A configuração a seguir ignora a necessidade do servidor de autenticação extra e configura o SSSD para ir diretamente ao AD primeiro.

A próxima pergunta normalmente é como controlar o acesso. É aí que entra o controle de acesso baseado em função (RBAC). O RBAC permite que você pare de atribuir acesso aos usuários e comece a atribuir acesso às funções. Após definir os grupos, você pode atribuir um novo membro a uma equipe, o que já faz parte da função com o acesso apropriado a um grupo de servidores. Ele remove as solicitações "Fui contratado e preciso do mesmo acesso que X", que fazem referência a uma pessoa que saiu há meses e teve todo o acesso removido.

Em vez disso, depois que você adicionar o novo usuário ao grupo da equipe, ele terá o acesso necessário. Ele também remove a descoberta de que alguém que saiu da empresa há mais de um ano ainda tem acesso a todos os servidores porque ninguém informou aos administradores que ela saiu. Quando o sistema ERP atualiza automaticamente a conta do AD, a pessoa perde todo o acesso.

Gerenciar o AD em sistemas operacionais diferentes do Windows já foi um desafio. No entanto, a Microsoft lançou o Windows Admin Center, que permite acessar o Active Directory Users and Computers diretamente de qualquer navegador em execução em qualquer sistema operacional. Ele também concede acesso a várias outras ferramentas de gerenciamento do Windows. Instale-o em um servidor do Windows e não se preocupe com os limites de sessão ou problemas com o RemoteApp. Inicie um navegador e acesse a interface web.

Configure seus grupos do AD para ter controle de acesso baseado em função

O esquema de nomenclatura da sua empresa pode ser diferente dos exemplos neste artigo. Os nomes dos grupos não são importantes. A parte essencial é o uso pretendido de cada grupo.

Como o SSSD não está sincronizando grupos do AD, está apenas obtendo uma lista de grupos dos quais o usuário é membro durante o processo de login, a ausência de grupos não impede que essa configuração funcione. No entanto, se você tiver várias equipes com permissões delegadas no AD, é recomendável criar todos os grupos para evitar que eles sejam criados na unidade organizacional (UO) incorreta, dando controle do acesso à equipe errada.

Acesso a máquinas específicas

Crie dois grupos no Active Directory para cada máquina. Ambos os grupos devem incluir uma abreviação do nome da máquina. 

Um grupo é para acesso via SSH específico da máquina (chamado de Machine_SSH_Access no restante deste artigo).

O outro grupo fornece acesso sudo específico da máquina (chamado de Machine_SUDO_Access no restante deste artigo).

Exemplos de formatos de grupo:

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname>é a abreviação do nome da máquina
• <DOMAIN>é a abreviação do nome do seu domínio e é opcional

Acesso a todas as máquinas

Crie dois grupos no Active Directory para acesso global à máquina.

Um dos grupos será para acesso via SSH (chamado de Global_SSH_Access no restante deste artigo) para todas as máquinas.

O outro é para acesso sudo (chamado de Global_SUDO_Access no restante deste artigo) para todas as máquinas.

Exemplos de formatos de grupo:

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN>é a abreviação do nome do seu domínio e é opcional.

Aninhamento

É permitido o aninhamento dentro dos grupos do AD. Se você quiser criar um grupo com acesso a várias máquinas, não é preciso alterar a configuração nas máquinas do RHEL. Em vez disso, é possível tornar o novo grupo um membro do grupo de acesso para as máquinas específicas. Essa abordagem permite controlar o acesso diretamente do AD.

Exemplo de aninhamento:

• Acesso via ssh ao Linux Webserver1 da CONTOSO
  • Acesso via ssh aos Linux Webservers da CONTOSO
    • Desenvolvedores web da CONTOSO
      • Usuário1
      • Usuário2

Esse aninhamento permite que você atribua funções (Desenvolvedores web da CONTOSO) a grupos de máquinas (Acesso via ssh a Linux Webservers da CONTOSO), em vez de usuários a sistemas específicos.

Inclusão da sua máquina Linux no domínio

Se o RC4 estiver ativado no seu ambiente, siga o Microsoft's Security Advisory e desative-o agora.

Para incluir uma máquina Linux a um domínio:

1. Instale os pacotes exigidos:

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. Adicione a cadeia de CA do seu domínio criando /etc/sssd/pki/sssd_auth_ca_db.pem e gravando-a. Isso não precisa incluir o certificado para os controladores de domínio (DC). É possível começar com o certificado que assinou seus certificados.
3. Adicione a cadeia de CA às âncoras de confiança do sistema:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. Configure o SSSD editando /etc/sssd/sssd.conf ou /etc/sssd/conf.d<DOMAIN>.conf e faça a correspondência com as linhas a seguir.

Editar /etc/sssd/conf.d/<DOMAIN>.conf é o método mais moderno e preferencial, mas editar /etc/sssd/sssd.conf também funciona.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN>é o FQDN do seu domínio com TODAS AS LETRAS MAIÚSCULAS. Podem ocorrer problemas de autenticação se você não usar todas as letras maiúsculas.
• ldap_idmap_range_size é opcional. É necessário se você tiver um grande ambiente do AD. Alterar esse valor faz com que o hash do UID seja alterado. Portanto, não o altere depois que a máquina for incluída no domínio e certifique-se de usar o mesmo valor em todas as máquinas.
• Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access e Machine_SUDO_Access são os grupos do AD que você criou acima para RBAC

5. Defina as permissões para o arquivo que você acabou de gravar: /etc/sssd/sssd.conf ou /etc/sssd/conf.d/<DOMAIN>.conf:

$ sudo chmod 400 /etc/sssd/sssd.conf

ou

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. Configure o KRB5 editando /etc/krb5.conf e faça a correspondência com estas linhas:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>
[realms]
[domain_realm]

Você não precisa especificar nada em [realms] ou [domain_realm]. O SSSD descobre automaticamente essas informações no DNS.

7. Configure o acesso SUDO criando um arquivo em /etc/sudoers.d:

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

Especifique o acesso sudo padrão para membros dos grupos sudo do AD. O nome do arquivo pode ser o que você quiser, não precisa ser DOMAIN.

Você deve preencher todos os espaços com uma barra invertida (\). Por exemplo: "acesso sud ao Linux" deve ser escrito como "acesso\ sudo \ao \Linux".

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access e Machine_SUDO_Access são os grupos do AD que você criou para RBAC. O sinal de porcentagem (%) antes do nome do grupo indica que é um grupo.

Qualquer outro acesso sudo que você queira conceder aos grupos do AD pode ser definido da mesma maneira em arquivos separados ou no mesmo arquivo.

8. Verifique se o nome do host da máquina está definido como o FQDN. O nome do host da máquina não pode ser abreviado:

$ sudo hostnamectl set-hostname $(hostname -f)

9. Inclua a máquina com um dos comandos a seguir (adcli é compatível com SMBv1 e SMBv2). Para definir as informações do sistema operacional no AD ao ingressar, use o seguinte comando:

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Como alternativa, você pode ingressar sem configurar as informações do sistema operacional:

$ sudo adcli join -U <join_user>

<join_user> é a conta do AD que será usada para incluir a máquina no domínio. A senha que o adcli solicita não é armazenada. Permissões delegadas descrevem as permissões necessárias para a inclusão.

10. Habilite e inicie o SSSD e ddjobd:

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. Habilite o acesso com o AD:

$ sudo authselect select sssd with-mkhomedir --force

Desde que sua conta seja parte de um dos grupos que você criou, agora você pode acessar a máquina. Não é necessário especificar o domínio. É usado o domínio especificado como default_realm em /etc/krb5.conf. O GNOME pode pedir uma reinicialização, mas o sshd normalmente aceita as alterações sem reiniciar.

Mantenha as informações do sistema operacional atualizadas

Por padrão, o objeto de computador não tem permissão para atualizar suas próprias informações do sistema operacional. Acesse Active Directory Users and Computers (ADUAC) e conceda a SELF a capacidade de gravar cada um dos campos do sistema operacional nos objetos de computador (você pode fazer isso no nível da UO). Após adicionado, atualize o objeto do AD com as informações mais recentes do sistema operacional:

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Isso pode ser adicionado como uma tarefa do cron ou como um serviço do systemd. Alguns exemplos:

[Unit]
Description=Updates AD with current OS information
After=sssd.service
[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"
[Install]
WantedBy=multi-user.target

Habilite a autenticação com cartão inteligente

Esta seção pressupõe que você tenha a autenticação com cartão inteligente funcionando nas máquinas Windows. Caso contrário, configure essa autenticação em uma máquina Windows antes de prosseguir.

1. Grave a cadeia de certificados do seu domínio em /etc/sssd/pki/sssd_auth_ca_db.pem. Isso não precisa incluir o certificado para os controladores de domínio (DC). Ele pode começar com o certificado que assinou seus certificados.
2. Adicione o certificado à lista de CAs confiáveis da máquina:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. Edite /etc/sssd/sssd.conf ou /etc/sssd/conf.d/<DOMAIN>.conf, dependendo de qual arquivo você usou quando o domínio entrou no seu sistema, e adicione a seguinte linha na seção [domain/<DOMAIN>]. Essa entrada informa ao SSSD onde procurar o certificado do usuário. O Windows usa o atributo userCertificate, então se usarmos o mesmo atributo, o mesmo cartão inteligente funcionará no Linux e no Windows.

ldap_user_certificate = userCertificate;binary

Adicione estas linhas ao final do mesmo arquivo de configuração:

[pam]
pam_cert_auth = true

4. Edite /etc/krb5.conf e adicione as linhas a seguir em [realms], substituindo <DOMAIN>pelo FQDN do seu domínio com TODAS AS LETRAS MAIÚSCULAS. Isso possibilita resolver uma discrepância que pode ocorrer porque o Windows não diferencia maiúsculas de minúsculas, enquanto o Linux, sim.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. Use um dos seguintes comandos para habilitar a autenticação com cartão inteligente no PAM:

• authselect enable-feature with-smartcard: permite a autenticação com cartão inteligente como uma opção.
• authselect enable-feature with-smartcard-required: requer a autenticação com cartão inteligente. Por padrão, o sshd não chama o PAM ao autenticar com chaves de SSH.
• authselect enable-feature with-smartcard-lock-on-removal: requer autenticação com cartão inteligente e bloqueia a máquina quando o cartão inteligente é removido.

Habilite o acesso por SSH usando o certificado de cartão inteligente

No RHEL 8 e versões mais recentes, você pode habilitar o acesso por SSH usando um cartão inteligente.

1. Verifique se o certificado de cartão inteligente foi lido corretamente no AD:

sss_ssh_authorizedkeys ${USER}

Se uma chave pública não retornar, verifique se a autenticação com cartão inteligente foi configurada corretamente.

2. Edite /etc/ssh/sshd_config para adicionar as linhas a seguir:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. Reinicie o sshd:

$ sudo systemctl restart sshd

Para acessar a partir de um cliente usando SSH, use a opção PKCS11Provider=/usr/lib64/opensc-pkcs11.so. Contanto que o cartão inteligente corresponda a uma chave pública para o usuário, você deverá fornecer o PIN ou a senha do cartão inteligente:

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

Informações adicionais

Agora você tem uma máquina incluída no domínio com controle de acesso baseado em função com a qual pode acessar ou executar comandos com privilégios. O gerenciamento fica mais fácil porque é possível aproveitar o trabalho que outras pessoas já estão fazendo. Confira alguns pontos a considerar:

• Desabilitar um usuário no AD bloqueia imediatamente o acesso à máquina. Assim como no Windows, qualquer pessoa que já esteja conectada permanece conectada.
• Assim como no Windows, a modificação nos grupos do usuário é atualizada durante o acesso. Isso é feito antes de verificar se eles têm permissão para acessar.
• O SSSD reconhece sites. Se você configurar sites no AD Sites and Services, o SSSD se conectará ao controlador de domínio adequado.
• O SSSD alterna a senha da máquina automaticamente.
• O SSSD cria e gerencia os registros DNS para uma máquina automaticamente, desde que as atualizações dinâmicas (seguras ou não) estejam habilitadas.

Eu normalmente não aconselho o uso de ferramentas do Windows para gerenciar sistemas Linux e ferramentas do Linux para gerenciar o Windows, porque geralmente há perda de funcionalidades importantes, falta de segurança ou maneiras muito mais fáceis de realizar a mesma tarefa com uma ferramenta nativa. No entanto, com o AD é diferente. Os desenvolvedores do SSSD trabalharam muito para torná-lo compatível com o AD e, no final, isso torna seu trabalho ainda mais fácil.