Colocando Linux no Domínio – CentOS

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

Você pode compartilhar esse artigo.

Siga o Blog Via E-mail

Digite seu endereço de e-mail para assinar este blog e receber notificações de novas publicações por e-mail.

Junte-se a 46 outros assinantes

Sobre o Autor

Rafael Oliveira Maria - Linux

Rafael Oliveira

Bacharel em Sistemas de Informação, SysAdmin, Professor, Blogueiro e Entusiasta Linux.

Certificados:

LPIC-1-Large
LPIC-2
LinuxPlus Logo Certified
itil-foundation-digital-badge

Gostou do conteúdo? Ajude-me a manter o blog.

PicPay - Linux

Aceitamos pagamentos e doações via PicPay link picpay.me/rafaeloliveimar

22 respostas

  1. 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

    1. 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.

  2. 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 ?

    1. 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.

  3. 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.

    1. 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.

      1. 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;

        1. 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.

  4. 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

    1. 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.

  5. 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.

    1. 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.

  6. 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?

    1. 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,

      1. 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.

Ficou com dúvida? Alguma Sugestão ou Elogio? Deixe seu comentário!