Comentamos, em postagens anteriores, sobre autenticação integrada com o MS Active Directory, tanto para estações como servidores Linux. Acredito que é uma demanda muito comum, podendo ser tratada de diferentes maneiras. Mas, o objetivo deste artigo se atém em demonstrar uma alternativa, relativamente simples, de “integração parcial” para serviços de rede como Web Proxy ou VPN, por exemplo.
Você deve ter percebido que escrevi “integração parcial“. Foi proposital. Como o objetivo é prover autenticação centralizada para determinados serviços de rede (como squid ou pptpd, por exemplo), não existe uma necessidade real para configurar o suporte “completo”. Ou seja, sem criar vinculo de “conta POSIX” – entenda como “conta POSIX” os mapeamentos internos no sistema operacional (mapeamentos uid para usuários e gid grupos).
Sendo assim, não trabalharemos com o PBIS!
O PBIS é mais indicado para integrações desktop ou mapeamentos completos (quando desejamos ou precisamos habilitar a “abertura de sessão de usuário” a partir de uma conta do Windows). É evidente que esta configuração pode ser feita pelo Samba através do Winbind e módulos do sistema, mas será um pouco mais trabalhosa.
Muitas vezes, no caso dos principais serviços de rede, o suporte para autenticação do AD pode ser simplificado, focando apenas no Winbind. Raramente será necessária configuração do PAM (Pluggable Authentication Module) ou NSSwitch (Name Service Switch). Vale lembrar que a configuração de um “Servidor de Arquivos Samba“, por exemplo, não pode ser parcial porque os arquivos compartilhados são armazenados e geridos segundo os critérios de acesso do Linux (ou seja, seguindo o padrão POSIX). Este entendimento é importante para compreender qual é a melhor configuração para cada situação.
A integração pode ser feita sob nível de segurança ADS (MS Active Directory Domain Services, via Kerberos) ou Domain (domínio NT-Style, via RPC). É evidente que o ADS é o nível mais flexível, menos oneroso para os DCs e mais seguro, porém mais trabalhoso também. Particularmente, costumo configurar ADS para servidores Proxy e Domain para concentradores de VPN. Opto pelo ADS quando a demanda de acesso e criticidade é significativamente maior (comum em serviços de Web Proxy). Por outro lado, no caso de um concentrador de VPN, os eventos de autenticação são menos expressivos, conta com uma camada de criptografia específica e, na minha opinião, não justifica qualquer dificuldade adicional.
Etapas de configuração:
1. Instalação do pacote Winbind
A instalação do winbind pode ser feita pelo gerenciador de pacotes de sua distribuição, como apt ou yum (por exemplo). Até hoje, não encontrei uma razão forte o suficiente para compilar manualmente. Os exemplos serão baseados na distribuição Ubuntu.
apt-get install winbind chgrp winbindd_priv /var/lib/samba/winbindd_privileged gpasswd -a proxy winbindd_priv
No Ubuntu, o Squid costuma ser configurado sob a conta de usuário “proxy“. Porém, para que o suporte de autenticação funcione corretamente com o winbind, o squid precisa ter acesso ao arquivo de controle “SAMBA_LIBS/winbindd_privileged/pipe” (normalmente em /var/lib/samba). Como a permissão padrão do diretório restringe o acesso ao grupo winbindd_priv, é necessário incluir o usuário proxy neste grupo (vide comando gpasswd).
Não é preciso ficar mudando script de inicialização(risos). Aliás, esta pode ser uma pegadinha simples que gera bastante dor de cabeça! 😉
2. Configuração básica do Samba (/etc/samba/smb.conf)
A configuração do domínio de rede é feita no arquivo smb.conf, mesmo que o serviço smbd não fique ativo no boot. Confiram os ajustes essenciais para o Winbind.
workgroup = SEU_DOMINIO
realm = SEU_REALM
wins server = ip_servidor_wins
dns proxy = no
security = domain
auth methods = winbind sam
winbind offline logon = true
winbind max domain connections = 250
encrypt passwords = true
pam password change = no
load printers = no
disable spoolss = yes
winbind enum groups = no
winbind enum users = no
winbind separator = \\
winbind use default domain = yes
winbind reconnect delay = 10
winbind cache time = 1800
winbind max clients = 250
Para ingressar sob nível de segurança ADS, troque a opção security de “domain” para “ads“. Do contrário, ignore a opção realm. E, para evitar processamento desnecessário ou indesejado, desabilite o suporte ao gerenciamento de impressoras.
Conforme exposto anteriormente, são raros os casos em que existe justificativa para ativar o mapeamento de contas (enumeração) Windows para POSIX – permitindo enxergar como outra conta Unix qualquer. Logo, se desejarmos habilitar apenas a autenticação para determinados serviços, sem permitir a abertura de sessões no sistema, será vantajoso desabilitar as opções winbind enum. Dependendo do tamanho da base de usuários, esta medida confere um ganho de performance significativo.
O procedimento está praticamente finalizado se o nível de segurança for “domain“. É muito simples. Bastará validar a resolução de nomes dos DCs e executar o comando net join para ingressar o servidor ao domínio.
3. Verificando a resolução de nomes para os DCs ou KDCs
Mesmo que o kerberos não seja configurado, certifique-se de que a resolução de nomes esteja funcionando corretamente, pois, dentre várias razões, será fundamental para a descoberta dos DCs ou KDCs da rede.
root@servidor:~# dig SRV +noall +additional _ldap._tcp.dc._msdcs.[SEU_DOMINIO] dc001.[seu_dominio]. 3600 IN A 10.x.y.1 dc002.[seu_dominio]. 3600 IN A 10.x.y.2 dc003.[seu_dominio]. 3600 IN A 10.x.y.3root@servidor:~# ping dc001.[seu_dominio] -c 2 PING dc001.[seu_dominio] (10.x.y.1) 56(84) bytes of data. 64 bytes from dc001.[seu_dominio] (10.x.y.1): icmp_seq=1 ttl=126 time=0.305 ms 64 bytes from dc001.[seu_dominio] (10.x.y.1): icmp_seq=2 ttl=126 time=0.259 ms
Testes de ping são suficientes. Por precaução, alguns administradores costumam mapear os DCs manualmente no arquivo “/etc/hosts“. Mas, é um ajuste opcional para dispensar as consultas de DNS na identificação dos DCs.
“Para o funcionamento adequado do kerberos, os mapeamentos de DNS e reverso são fundamentais“.
4. Configuração do kerberos
Pule esta etapa caso tenha optado pelo nível de segurança “domain” e não tenha interesse em trabalhar com autenticação baseada no kerberos (valendo-se do método negotiate).
Atualmente, tenho adotado esta configuração apenas em servidores Web Proxy. Porém, caso a autenticação kerberos não seja disponibilizada, será mais interessante ingressar o servidor sob o nível domain, ignorando a instalação e configuração do kerberos.
“Vale lembrar que esta etapa não depende do Samba, mas o inverso não será verdadeiro se o Samba for configurado como membro do AD (security ads)“.
apt-get install krb5-user libkrb5-3 libsasl2-modules-gssapi-mit
Feito isto, crie ou altere o arquivo /etc/krb5.conf com o seguinte conteúdo:
[libdefaults]
default_realm = SEU_REALM
# The following krb5.conf variables are only for MIT Kerberos.
# krb4_config = /etc/krb.conf
# krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
dns_lookup_kdc = false
dns_lookup_realm = false
ticket_lifetime = 24h
# Arquivo keytab para validação SPN do Squid
# default_keytab_name = /etc/squid/PROXY.keytab
default_tkt_enctypes = rc4-hmac
# default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
SEU_REALM = {
kdc = dc001.seu_dominio
kdc = dc002.seu_dominio
kdc = dc003.seu_dominio
admin_server = dc001.seu_dominio
default_domain = seu_dominio
}
[domain_realm]
.seu_dominio = SEU_REALM
seu_dominio = SEU_REALM
Modifique os valores seu_dominio e SEU_REALM de acordo com o seu ambiente. Em determinados casos (com múltiplos domínios, por exemplo), pode ser desejável alterar dns_lookup_kdc e dns_lookup_realm para true, habilitando assim a descoberta automática por consulta de DNS.
Para validar a autenticação (testando a conexão com o AD), utilize os comandos:
root@servidor:~# kinit usuarios@REALMroot@servidor:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: usuario@REALM Valid starting Expires Service principal 19/04/2017 15:11:07 20/04/2017 01:11:07 krbtgt/REALM@REALM renew until 20/04/2017 15:11:05
Se tudo estiver correto, nenhuma mensagem será retornada para o primeiro comando. Em seguida, basta verificar a validade da sessão com o comando klist.
Fique atento com o relógio do sistema, pois, em geral, existe uma tolerância de 5 minutos em relação aos DCs. Acima disto, o processo de autenticação falhará. Para evitar surpresas, é recomendável trabalhar com um sistema de sincronismo. Nas versões mais atuais do Ubuntu, é possível configurar o servidor NTP em /etc/systemd/timesyncd.conf. Outra alternativa é sincronizar o horário com o comando ntpdate [ip_servidor_ntp].
Já o suporte para autenticação no Squid depende de ajustes adicionais, como a criação de um SPN (Service Principal Name). Existem particularidades. Logo, não aprofundarei nos detalhes envolvidos com este tipo de configuração. Mais adiante criarei um artigo direcionado ao Squid.
5. Ingressando ao domínio
Se as etapas anteriores foram concluídas com sucesso, resta apenas ingressar ao domínio. Para ingressar como “membro do AD (ads)” utiliza-se o comando net ads join e como “membro NT-Style (domain)“ net rpc join.
Esta etapa é bastante simples. Utilize uma conta com privilégio administrativo ou permissão para ingressar.
– Como membro do AD
net ads join -U Administrator– Como membro NT-Style
net rpc join -U Administrator
Para validar o processo e a relação de confiança podemos utilizar a opção testjoin:
root@servidor:~# net ads testjoin Join is OKroot@servidor:~# net rpc testjoin Join is OK
Para finalizar, basta reiniciar o winbind e validar o suporte:
root@servidor:~# service winbind restartroot@servidor:~# wbinfo -t checking the trust secret for domain DOMAIN via RPC calls succeeded
Este processo é fundamental porque a autenticação provida pelos demais serviços é feita habilitando o suporte ao winbind. É possível consultar a base de usuários e grupos através do comando “wbinfo -u” (usuários) e “wbinfo -g” (grupos).
Outra medida importante, para evitar problemas com política de expiração de contas inativas do AD, é o agendamento, no crontab, de um processo de atualização periódica:
05 4 * * * net rpc changetrustpw -d 1 | logger -t changetrustpwou (no modo ADS)
05 4 * * * net ads changetrustpw -d 1 | logger -t changetrustpw
As etapas descritas são suficientes para ativar a autenticação prevista no artigo em que demonstramos a configuração de um concentrador de VPN PPTP.
Para integração completa (se julgar necessário), recomendo a seguinte leitura:
http://wiki.ubuntu-br.org/AutenticandoAD
[…] Comece integrando o servidor ao domínio: http://linuxfirewall.com.br/linuxwp/autenticacao-integrada-com-o-ms-active-directory-ad/ […]