Este Artigo tem como objetivo realizar o ingresso de uma máquina Linux em um domínio. Diferente do Windows, o Linux requer uma atenção especial quanto trata-se de integração em um ambiente corporativo. Isso porque ele exige alguns fatores que devem ser levados em consideração na hora de integrá-lo. Aqui tentaremos abordar todos os aspectos necessários para realizarmos este procedimento de forma profissional, trazendo ao final do artigo uma integração correta.
Para que este procedimento seja possível, iremos utilizar três serviços essenciais, os quais são:
Kerberos: É um protocolo de rede usado para autenticação de usuários e/ou serviços de rede, como o Active Directory. utilizando um sistema criptografado, permitindo comunicações seguras e identificadas em redes, fazendo uso de tickets (chaves criptografadas).
Winbind: O Winbind é um daemon usado pelo PAM, NSSWITCH, Samba e podendo ser usado por outros serviços de rede e/ou sistema, fazendo a interface entre o PDC e o computador cliente rodando o serviço Winbindd, permitindo que máquinas com o sistema GNU/Linux comuniquem-se com DC Active Directory.
Samba: É um serviço cuja principal função é disponibilizar recursos compartilhados em uma rede, tais como arquivos e impressoras, além de também ser utilizado como controlador de domínio.
CONSIDERAÇÕES
Vamos levar em consideração que você já possui um ambiente com um servidor de domínio Windows Server com o Active Directory, DNS e DHCP instalados e funcionando.
Veja a disposição dos servidores na rede para explicação do artigo:
Domínio → oliveira.com
Servidor controlador de domínio → 192.168.2.1 serverdc.oliveira.com
Servidor DHCP → 192.168.2.1
Servidor DNS primário → 192.168.2.1
Desktop cliente → cltvirtual (Distribuição: CentOS 7)
Nota: Para editar os arquivos de configuração você pode escolher qual editor padrão deseja usar. Neste artigo iremos utilizar o editor “vi” como padrão.
Este artigo tem por objetivo trabalhar com distribuições derivadas da Red-Hat. Para este exemplo estaremos utilizando o “CentOS 7”, caso deseje colocar uma máquina no domínio derivada do Debian acesse nosso artigo “Colocando Linux no Domínio – Debian 9“.
1) EDIÇÃO DO ARQUIVO /etc/hosts.
Em nossa máquina “cltvirtual” que pretendemos colocar no domínio, entre no arquivo “/etc/hosts” e adicione o complemento do domínio junto ao host da máquina cliente.
Opcional: Também adicione o endereço de ip do servidor controlador de domínio, este procedimento ajuda na resolução de nomes, pois já estamos setando diretamente quem será o controlador.
127.0.0.1 cltvirtual.oliveira.com cltvirtual localhost 192.168.2.1 serverdc.oliveira.com
Após realizarmos a alteração, execute o seguinte comando com parâmetro: “hostname -f“. O resultado do comando irá mostrar o nome da máquina completo, junto com o domínio informado.
2) INSTALAÇÃO DE PACOTES NECESSÁRIOS.
yum install -y samba samba-client samba-winbind-clients realmd oddjob oddjob-mkmedir sssd adcli krb5-workstation krb5-libs krb5-auth-dialog ntp
3) SINCRONIZANDO DATA/HORA COM O CONTROLADOR DE DOMÍNIO.
Para que possamos ser autenticados pelo controlador de domínio é de primordial importância que estejamos sincronizados com a data e a hora do mesmo. No Linux é possível realizar este procedimento de forma automática, configurando um serviço de “NTP“.
Acesse o arquivo de configuração “/etc/ntp.conf” e nas linhas do arquivo onde o conteúdo começa com a palavra “server“, comente estas linhas com uma cerquilha “#“, e adicione o conteúdo conforme ilustrado abaixo, salve e saia do arquivo.
#server 0.centos.pool.ntp.org iburst #server 1.centos.pool.ntp.org iburst #server 2.centos.pool.ntp.org iburst #server 3.centos.pool.ntp.org iburst #Controlador de Dominio server 192.168.2.1 restrict 192.168.2.1
Realize a reinicialização do serviço “NTP“, conforme ilustrado abaixo:
systemctl restart ntpd
4) EDIÇÃO DO ARQUIVO “/etc/resolv.conf”.
No ambiente apresentado estamos considerando que a máquina cliente “cltvirtual” esta recebendo IP através de um serviço DHCP iniciado no servidor controlador de domínio “serverdc“. Caso não esteja utilizando o serviço DHCP, é possível setar os servidores de nomes “DNS” no arquivo “/etc/resolv.conf” conforme ilustrado abaixo.
# Generated by NetworkManager search oliveira.com nameserver 192.168.2.1
5) CONFIGURAÇÃO KERBEROS.
Para que o usuário consiga autenticar-se no controlador de domínio iremos utilizar um protocolo de autenticação de redes chamado kerberos. O controlador de domínio com o serviço de Active Directory instalado já possui por default um KDC (Controlador de domínio Kerberos) apto para autenticar este tipo de protocolo. Iremos então editar o arquivo “/etc/krb5.conf” e realizar as configurações conforme ilustrado abaixo. Salve e saia do arquivo.
#Configuration snipets may be placed in this directory as well
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = OLIVEIRA.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
OLIVEIRA.COM = {
kdc = serverdc.oliveira.com
admin_server = serverdc.oliveira.com
}
[domain_realm]
.oliveira.com = OLIVEIRA.COM
oliveira.com = OLIVEIRA.COM
Depois de configurado o kerberos, precisamos testar a comunicação com o controlador de domínio. Para isto, utilizaremos o comando “kinit” seguido pelo parâmetro “Nome de usuário que esteja cadastrado no domínio“, conforma ilustrado abaixo.
kinit rafael
Será solicitado a senha de usuário, digite a senha e pressione “ENTER“.
Após realizar o comando e o mesmo não retornar nenhuma mensagem de erro, é possível verificar o “ticket kerberos” gerado através do comando “klist” conforme ilustrado abaixo.
klist
Mostrando como resultado:
Ticket cache: KEYRING:persistent:0:0 Default principal: rafael@OLIVEIRA.COM Valid starting Expires Service principal 14-02-2018 14:36:44 15-02-2018 00:36:44 krbtgt/OLIVEIRA.COM@OLIVEIRA.COM renew until 21-02-2018 13:36:41
6) CONFIGURANDO O SAMBA.
Também antes de ingressarmos a máquina cliente “cltvirtual” no domínio é necessário realizar algumas configurações preliminares no Samba. Neste artigo já estamos utilizando o Samba 4, alguns parâmetros estão sendo disponibilizados, mesmo que não sejam necessários para o artigo em questão. Estes padrões são úteis caso deseje compartilhar informações de sua máquina cliente, ou transforma-la em um servidor de arquivos. Faça uma copia de segurança do arquivo “/etc/samba/smb.conf” de sua máquina e crie um novo arquivo conforme conteúdo ilustrado abaixo.
[global] workgroup = OLIVEIRA server string = Maquina Cliente netbios name = CLTVIRTUAL realm = OLIVEIRA.COM #veto files = /*.exe/*.bat/*.inf/*.pif/ #==================== Log do Samba =======================. log file = /var/log/samba/samba.log os level = 2 preferred master = no max log size = 50 debug level = 1 #==================== Autenticação =======================. security = ads encrypt passwords = yes allow trusted domains = yes #================ Configuração WINBIND ===================. winbind uid = 10000-2000000 winbind gid = 10000-2000000 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind refresh tickets = yes template shell = /bin/bash template homedir = /home/%D/%U client use spnego = yes domain master = no
Precisamos também habilitar o serviço do samba para ser inicializado junto ao sistema, realize o procedimento conforme ilustrado abaixo.
systemctl enable smb.service systemctl enable nmb.service
Após configurado, reinicie o serviço do Samba e do Winbind.
systemctl restart smb.service systemctl restart nmb.service systemctl restart winbind.service
7) CORRIGINDO ERRO WINBIND.
Diferentemente do CentOS 6, no CentOS 7, vamos precisar realizar um procedimento diferenciado, você deve ter reparado que ao reiniciar os serviços o Winbind não iniciou. Para corrigir o problema precisamos realizar uma pequena alteração em nosso /etc/samba/smb.conf.
Acesse novamente o arquivo “smb.conf” e altere a seguinte linha conforme ilustrado abaixo.
security = ads
Para
security = user
Salve, saia do arquivo e reinicie os serviços Samba e Winbind.
systemctl restart smb.service systemctl restart nmb.service systemctl restart winbind.service
Repare que agora os dois serviços foram iniciados com sucesso. Feito isso, volte nas configurações do arquivo smb.conf e retorne a configuração conforme ilustrado abaixo.
security = user
Para
security = ads
Salve e sai do arquivo, porém desta vez, reinicie somente o Samba conforme ilustrado abaixo.
systemctl restart smb.service systemctl restart nmb.service
Feito isso já podemos passar para o próximo passo e ingressar nossa máquina cliente no domínio.
8) INGRESSANDO A MÁQUINA CLIENTE NO DOMÍNIO.
Agora que nossas configurações estão corretas, podemos ingressar a máquina no domínio. Para isso, vamos utilizar o comando “realm“. Este comando possui duas principais áreas de atuação: Gerenciar registro de sistema em um domínio e definir quais usuários do domínio podem acessar os recursos do sistema local.
Para que o processo de integração funcione corretamente, precisamos levar em consideração alguns pacotes que já foram instalado no passo um deste artigo, mas que merecem uma explicação.
oddjob: É um serviço D-BUS que executa tarefas específicas para clientes que se conectam a ele e emite solicitações usando o barramento de mensagens em todo o sistema.
oddjob-mkhomedir: Pacote utilizado para criar o diretório do usuário assim que ele realiza o primeiro login.
sssd: Acronimo de “System Security Services Daemo” ou “Daemon de Serviços de Segurança do Sistema”, fornece um conjunto de daemons para gerenciar o acesso a diretórios remotos e mecanismos de autenticação. Ele fornece interfaces de “Name Service Switch” (NSS) e “Pluggable Authentication Modules” (PAM).
adcli: É uma ferramenta de linha de comando que pode executar ações em um domínio do Active Directory.
Por padrão o “realm” utiliza o “sssd” para gerenciar a autenticação junto ao AD, porém utilizaremos como padrão o já conhecido “winbind“, podendo assim usufruir de seus comandos de verificação.
Antes de executarmos o comando para integração no domínio através do realm, acesse o arquivo “/etc/realmd.conf” e adicione as informações conforme ilustrada abaixo. (Se o arquivo não existir, crie-o).
[active-directory] os-name = CentOS-7 os-version = 3.10.0-693.el7.x86_64
Estes dados serão informados ao controlador de domínio no momento de integração com o AD, preenchendo as informações na conta de computador criada no “Active Directory” como ilustrada abaixo.
Vamos então ingressar nosso máquina ao domínio. Para isso, execute o comando conforme comando ilustrado abaixo.
realm join --client-software=winbind -U administrador oliveira.com
Nota: A conta passada para este comando precisa ter poderes de ingressar máquinas no domínio. Em nosso exemplo, foi utilizado a conta “administrador” do domínio.
Após a execução do comando, se tudo correr bem, significa que a máquina foi integrada ao domínio com sucesso. Para que seja possível confirmar, execute o comando conforme ilustrado abaixo.
realm list
É possível receber as seguintes informações:
[root@cltvirtual home]# realm list oliveira.com type: kerberos realm-name: OLIVEIRA.COM domain-name: oliveira.com configured: kerberos-member server-software: active-directory client-software: winbind required-package: oddjob-mkhomedir required-package: oddjob required-package: samba-winbind-clients required-package: samba-winbind required-package: samba-common-tools login-formats: OLIVEIRA\%U login-policy: allow-any-login
Agora vamos testar se o controlador de domínio está respondendo utilizando os seguintes comandos:
net ads testjoin
Se tudo correr bem o sistema responderá:
Join is OK
Também vamos testar utilizando o seguinte comando:
wbinfo -t
Se tudo correr bem o sistema responderá:
checking the trust secret for domain OLIVEIRA via RPC calls succeeded
Feito isto, precisamos testar e verificar se já conseguimos buscar os grupos e usuários do controlador de domínio conforme o seguinte comando a seguir:
(Lista de usuários do domínio)
wbinfo -u
(Lista de grupos do domínio)
wbinfo -g
Nota: Caso não seja possível trazer alguma das duas listas informadas, reinicie o “winbind” novamente. Se mesmo assim não conseguir executar os comandos com sucesso, volte o artigo e analise os passos anteriores refazendo a configuração, provavelmente algo passou despercebido.
Também é possível utilizar outros dois comandos para trazer informações dos usuários e grupos, porém locais.
(Lista usuários Local)
getent passwd
(Lista grupos Local)
getent group
Caso queira retirar a máquina do domínio utilize o seguinte comando:
realm leave
Nota: Após a integração da máquina cliente ao domínio, os serviços Samba e Winbind poderão ser reiniciados sem nenhum problema.
9) CORRIGINDO INFORMAÇÕES SAMBA.
Agora após ter colocado nossa máquina no domínio, repare que o arquivo “/etc/samba/smb.conf” sofreu algumas alterações, isso ocorre devido a utilização do “realm“. Acesse novamente o arquivo de configuração é substitua as informações pelas já mencionadas no 6, e em seguida reinicie o Samba e o Winbind, conforme ilustrado abaixo.
systemctl restart smb.service systemctl restart nmb.service systemctl restart winbind.service
10) EDIÇÃO DO ARQUIVO “/etc/nsswitch.conf”.
Como agora estamos trabalhando com usuários e grupos do domínio, precisamos informar ao sistema que desejamos trabalhar com o “winbind” para procurar nossas informações de login. Para isso, é necessário editar duas linhas no arquivo “/etc/nsswitch.conf“, conforme ilustrado abaixo.
7 passwd: compat winbind 8 group: compat winbind
Após editar o arquivo, reinicie novamente o serviço “Winbind” e “Samba” conforme ilustrado abaixo.
systemctl restart smb.service systemctl restart nmb.service systemctl restart winbind.service
Seu sistema já esta no domínio e apto para uso.
CONCLUSÃO
Neste artigo foi demostrado como colocar uma máquina baseada na distribuição “CentOS 7” no domínio de forma correta.
Se você gostou deste post e através dele pude lhe ajudar, o que acha de aproximarmos nosso contato? Siga meu blog e me adicione no Linkedin, aproveite para classificar algumas das minhas competências/recomendações, este simples gesto faz toda a diferença.
Att,
Rafael Oliveira
SysAdmin
22 respostas
Boa Tarde Rafael, tudo ?
Segui o seu tutorial porém a máquina não está ingressando no domínio
Quando uso o comando realm join ele informa que a realm já está associada ao dominio, porém quando faço os testes se está tudo ok começa aparecer os problemas conforme segue:
No teste do realm list aparece duas vezes a mesma lista, e nos campos client-software e required-package aparece : sssd e adcli, e não samba-winbind-clients e samba winbind, detalhe troquei no arquivo nsswitch.conf de sssd para winbind
No teste do net ads testjoin aparece erro de kerberos_kinit_password maquina@dominio failed Preauthentication failed
No teste wbinfo -t da erro de credencial error code was nt_status_domain_controller _not_found
Nos demais testes sem resposta.
Você poderia me ajudar ?
Obrigado
Fala Carlos blz? Cara que pena que não conseguiu, esse artigo é um pouco antigo, de 2018, tenho trabalhado em meus ambientes com Debian, CentOS bem pouco, teria que montar um ambiente para realizar o teste e verificar se tudo esta correndo bem conforme o artigo, mas infelizmente não consigo por agora. Vou deixar anotado aqui para atualizar o artigo. abr.
Boa tarde, fiz conforme o seu tutorial, a máquina ingressa no domínio, tudo certo, mas quando tento usar um usuário do Ad ele da acesso negado, o que poderia ser ?
Fala Clayton, blz?
Da uma olhada no /etc/nsswitch.conf, o winbind tem que esta apontado lá. Restarta o mesmo e tente fazer um consulta com ele. Revise o artigo talvez passou por algo despercebido. Abr.
Rafael, excelente conteúdo.
Fiz todo o procedimento e ocorreu tudo certo, mas tive um problema
com o comando wbinfo -u e -g ele enxerga os usuários e grupos no meu ad(server 2019)
Mas quando eu tento setar o dono ou grupo de uma pasta no file server ele diz que o usuário não existe.
ex: chown breno familia/ <- me retorna que o usuário não existe(mas existe no meu ad)
Como eu posso fazer isso ?
Obrigado.
Fala Breno bom dia! Obrigado, que bom que conseguiu.
Seguinte, quando as informações não estão sendo puxadas o problema pode ser “N” fatores.
1) Verifique se está configurado o winbind no arquivo /etc/nsswitch.conf
2) Reinicie o winbind e depois o samba.
Se está puxando a informação mas não consegue utilizar nas pastas, na teoria o problema está relacionando a isso.
Se não funcionar, revise o conteúdo talvez algo passou despercebido.
Abr.
Obrigado por responder Rafael, eu estou com um laboratorio de teste e brincando com centos 8.
Vou remonta-lo novamente com mais calma hoje e te dou um retorno.
Adicionei você no likedin
att;
Show, fiz esse artigo baseado no CentOS 7, não coloquei nenhum 8 no domínio ainda, mas creio que a lógica continua sendo a mesma, a maioria do meus ambientes são Debian.
Show vou aceitar lá, e qualquer coisa só falar aí, se demorar responder e devido a correria mesmo, vida de TI é tensa. kk Abr.
Rafael, boa noite. Primeiramente obrigado, excelente conteudo.
Fiz todo o procedimento e deu tudo certinho, mas estou com uma dificuldade, quando eu listo os usuarios com wbinfo -u ele me mostra os usuarios do meu AD(Server 2019) mas eu nao consigo definir um usuario do AD como dono da pasta, exemplo chown breno familia/, ele me retorna que o usuario é invalido, acho que ele so ta aceitando os usuarios do linux. eu tenho um debian que consegue atender essa minha solicitação.
Existe uma forma de faze-lo no centos?
Obrigado
Respondi na sua outra pergunta. Uma dica, nunca utilize usuário direto como dono de pasta, utilizar sempre grupo do AD, assim vc gerência seu servidor de arquivos direto do AD e nunca mais precisará dar permissão em pasta específica. Crie um 2 grupos no AD que represente a pasta, um grupo ficará as pessoas com acesso total, e o outro grupo as pessoas que terão acesso parcial. Coloque como grupo dono o grupo de acesso total, e no smb.conf vc realiza as devidas configurações, de quais grupos poderão acessar. Abr.
Parabéns Rafael, muito bem montado e explicado, me ajudou bastante mesmo! Já te adicionei no linkendin.
Show Wendell, que bom que foi útil. Abr.
Olá Rafael. O que fazer para resolver quando o servico smb não reinicia e dá essa mensagem de erro:
Job for smb.service failed because the control process exited with error code. See “systemctl status smb.service” and “journalctl -xe” for details.
Oi Rafael. Acabei encontrando a solução pro problema descrito. Basta acrescentar um parâmetro no smb.conf:
winbind nested groups = no
E com isso, o servico smb.service subiu normalmente.
Olá. Eu fiz a implementação e tá tudo funcionando beleza. O problema é que do nada o servidor perde comunicação com o AD e os serviços smb, nmb e winbind têm que ser restartados periodicamente. O que fazer para sanar esse problema?
Boa tarde Neto! Repare se quando isso acontece você esta sem o ticket do kerberos, através do comando klist. Se for isso será necessário criar um script para criar um ticket de forma automática, aqui no blog não me recordo de ter feito algum artigo com esse tema, mas encontra facilmente no google. Att,
Olá Rafael. Não encontrei nada a respeito de criar um script automático par ao ticket. Se tiver alguma dica a respeito, gostaria muito que me passasse. Muito obrigado.
Estou ti devendo Neto! Vou providenciar assim que possível, obrigado pela sugestão. Forte abraço.
Muito obrigado, por este post ajuda bastante eu que sou iniciante na area.
Vlw José!
Boa tarde, quando você faz o teste do net ads testjoin ele pede uma senha e qual é esta senha ?
A senha da conta com poderes de administração de domínio.