Autenticando GNU/Linux Debian 8 em domínio AD ou Samba 4

AUTENTICAÇÃO CENTRALIZADA DE SERVIDORES GNU/LINUX DEBIAN EM DOMÍNIO AD OU SAMBA4

INTRODUÇÃO:

O uso de usuário único com senha estática para acesso aos servidores GNU/Linux é uma prática muito comum no mercado, o problema é que nem sempre tais servidores são administrados por um único administrador, quando mais de um usuário acessa o mesmo servidor utilizando uma mesma conta de acesso é impossível realizar auditoria e rastreabilidade das ações do mesmo. E não me venha falar que mapear a conexão, para saber de qual IP veio, é uma rastreabilidade conclusiva!

Outro problema muito grande é que, na TI, as equipes possuem rotatividade muito grande e sempre que alguém sair do quadro de funcionários da equipe há a necessidade de trocar a senha do usuário padrão de acesso em todos os servidores. Geralmente em ambientes com parque de TI com pequenas quantidades de servidores GNU/Linux a administração de usuários, grupos e permissões de acesso aos mesmos são relativamente fáceis, podendo ser administrados localmente sem esforço demasiado.

Em ambientes maiores e complexos fica impossível realizar tais ações sem onerar a equipe, com isso indica-se o uso da autenticação centralizada de servidores GNU/Linux em domínio local.

Imagine sua equipe de administradores de servidores, que já possui conta de Login e senhas pessoais para logar nos clientes de redes, acessando os servidores com sua própria conta de acesso à rede! Agora sim, seria possível a rastreabilidade. Aqueles que ainda não estiverem convencidos das vantagens de tais ações vão dizer: “Ah, mesmo que o usuário: ‘user01’ realize seu login no servidor, terá que se promover a ‘root’ para poder realizar as atividades mais complexas!”. Sim meus caros amigos, mas, e somente se, você não souber ou não configurar o Sudoers. Então, vamos colocar a mão na massa!

REQUISITOS:

Nosso laboratório consiste em:

Servidor Debian8 PDC samba4(funciona como um AD): dc01.bsibt.net.br (192.168.200.10/24);

Servidor client Debian8: srvdeb03.bsbit.net.br (192.168.200.31/24);

Em primeiro lugar é necessário realizar as configurações básicas de conectividade em rede no cliente, sendo elas, a definição do hostname e configuração do arquivo hosts.

O hostname pode ser definido no momento da instalação do sistema operacional ou, caso já instalado, pode editar o arquivo /etc/hostname com um editor qualquer e inserir o nome do servidor:

localhost# vim /etc/hostname

srvdeb03

Há formas de alteração do arquivo hostname e o sistema operacional entender a mudança sem a necessidade da realização de um boot no servidor, porém, como não escopo deste artigo, realize o reboot no servidor e realize novamente o login para dar continuidade no trabalho.

O DNS é responsável por traduzir nomes fqdn em endereços IP nas redes, o sistema operacional consulta primeiramente o arquivo local /etc/hosts e caso não encontre uma entrada compatível com a solicitação é que consulta os DNS’s configurados no arquivos /etc/resolv.conf. Configure o arquivo /etc/hosts da seguinte maneira:

srvdeb03# vim /etc/hosts

127.0.0.1 localhost

127.0.0.1 srvdeb03.bsbit.net.br srvdeb03

192.168.200.10 dc01.bsbit.net.br dc01

Como trata-se de um servidor em uma rede de servidores, provavelmente o mesmo já esteja com o seu IP estático, caso ainda não esteja, realize as configurações necessárias na interface de rede através do arquivo /etc/network/interfaces.

Srvdeb03# vim /etc/network/interfaces

img3 rede

Reinicialize as interfaces com o seguinte comando:

srvdeb03# invoke-rc.d networking restart

Como todos nós sabemos qualquer nível de autenticação local ou remoto é extremamente dependente da sincronização dos horários dos servidores, por este motivo, garanta que os mesmos encontrem-se sincronizados. Em no laboratório o DC01 é um servidor NTP. Então instale o ntpdate e realize a sincronização:

srvdeb03# apt-get install ntpdate

srvdeb03# ntpdate -s 192.168.200.10

Obs.: Use o endereço IP do servidor NTP de sua rede, que não necessariamente será o seu Domain Controller(DC).

Agora sim estamos com o nosso ambiente preparado para a realização das configurações propostas nesse artigo.

O Kerberos é o nome de um Protocolo de rede, que permite comunicações individuais seguras baseadas em tickets e identificadas em uma rede insegura. Sua instalação consiste em dois pacotes:

srvdeb03# apt-get install krb5-user libpam-krb5

Após a instalação dos pacotes citados configure o arquivo /etc/krb5.conf

srvdeb03# vim /etc/krb5.conf

O seu conteúdo deve estar parecido com a seguinte saída:

#======================= Settings for kerberos =======================

[logging]

Default = FILE:/var/log/krb5.log

[libdefaults]

default_realm = bsbit.net.br

clock-skew = 300

ticket_lifetime = 24000

dns_lookup_realm = true

dns_lookup_kdc = true

[realms]

bsbit.net.br = {

kdc = dc01.bsbit.net.br:88

admin_server = dc01.bsbit.net.br:464

default_domain = bsbit.net.br

}

[domain_realms]

.bsbit.net.br = dc01.bsbit.net.br

bsbit.net.br = dc01.bsbit.net.br

[login]

krb4_convert = true

krb4_get_tickets = true

#===============================================================

Teste suas configurações gerando um Ticket kerberos para o seu domínio:

srvdeb03# kinit Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.

Ao listar os seus tickets com o comando klist terá como saída algo parecido com isto:

srvdeb03# klist
Ticket cache: File: /tmp/krb5cc_0
Default principal: Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.

Valid starting          Expires Service principal
14-05-2017 18:12:21     15-05-2017 00:52:16 Krbtgt/Este endereço de email está sendo protegido de spambots. Você precisa do JavaScript ativado para vê-lo.
     

O samba é uma aplicação para interoperabilidade entre servidores GNU/Linux e Microsoft Windows em ambientes heterogêneos. Ele possibilita que um servidor GNU/Linux compartilhe e acesse diretórios e impressoras na rede, assim como, também possibilita configurar o GNU/Linux como um servidor de Domínio ou cliente do domínio.

Um servidor Active Directory possui informações necessárias para a autenticação em sistemas Windows, para que seja possível realizar a autenticação de contas do AD em servidores GNU/Linux é necessário, além do samba, o pacote winbind que é responsável por “traduzir” informações do AD com a autenticação GNU/Linux. Um exemplo claro referente a essa condição é que o GNU/Linux exige um UID e um GID para as contas de usuários, como o AD não possui este conceito é o winbind o responsável por essa tarefa de mapear as contas do AD com UIDs e GIDs locais.

Instale o samba e o winbind:

srvdeb03# apt-get install samba winbind

O conteúdo de configuração do samba deverá conter em sua sessão global as seguintes configurações:

#======================= Global Settings =======================

[global]

security = ads

realm = bsbit.net.br

password server = dc01.bsbit.net.br

workgroup = BSBIT

idmap uid = 10000-20000

idmap gid = 10000-20000

winbind enum users = no

winbind enum groups = no

template homedir = /home/%D/%U

template shell = /bin/bash

client use spnego = yes

client ntlmv2 auth = yes

encrypt passwords = yes

winbind use default domain = yes

restrict anonymous = 2

domain master = no

local master = no

preferred master = no

os level = 0

#==========================================================

Para que as configurações sejam atualizadas e utilizadas pelo serviço samba será necessário a reinicialização dos serviços:

srvdeb03# invoke-rc.d winbind stop
srvdeb03# invoke-rc.d samba restart
srvdeb03# invoke-rc.d winbind start

Após tantas configurações o servidor cliente já está pronto para ser inserido ao domínio, realize tal tarefa com o seguinte comando:

srvdeb03# net ads join -U Administrator

img5 inserindo no dominio

Agora poderá listar os usuários e grupos do domínio com os seguintes comandos:

srvdeb03# wbinfo -u

srvdeb03# wbinfo -g

O grande desafio que um administrador de sistemas operacionais Debian encontra neste momento é que para a autenticação dos usuário do domínio funcionar no servidor local é preciso a configuração de arquivos do módulo PAM. Inúmeras documentações online, artigos, livros, e, até mesmo, na wiki oficial do Debian sugerem a configuração de diversos arquivos PAM desnecessariamente. O segredo consiste em instalar os seguintes pacotes:

libpam-winbind e libnss-winbind

Estes pacotes inserem informações necessárias para a realização do login de usuários do domínio nos diversos arquivos do PAM, sendo necessário fazer apenas a seguinte configuração no arquivo /etc/pam.d/common-session.

Edite o arquivo:

srvdeb03# vim /etc/pam.d/common-session

e após a linha:

session required pam_unix.so

Inclua a seguinte linha de configuração:

session required pam_mkhomedir.so umask=0022 skel=/etc/skel

Essa linha possibilita a criação do diretório home do usuário do domínio no ato do login automaticamente.

            Para que o sistema operacional consiga verificar a autenticação do usuário utilizando o winbind edite o arquivo /etc/nsswitch.conf inserindo a opção winbind nas linhas referentes ao passwd e ao group:

nsswitch

 

Com isso nosso servidor já está integrado e autenticando qualquer um dos usuários do domínio localmente no servidor, porém, não podemos parar por aqui, pois, apesar de autenticarmos ainda é necessário nos promover para superusuários para podermos realizar as atividades mais críticas no sistema. Para que não seja necessário a promoção para usuário root é necessário a instalação do sudoers.

Observe a seguinte imagem e verifique que mesmo logando no sistema não é possível utilizar boa parte dos comandos disponíveis no sistema operacional:

img7 sudo negado

Instale o sudo:

srvdeb03# apt-get install sudo

Configure permitindo o uso dos comandos pelos usuários ou grupos necessários, como o foco deste artigo não é a configuração do sudoers iremos habilitar todos os comandos para os usuários do grupo do domínio chamado “redes” da seguinte forma:

# Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

%redes ALL=(ALL:ALL) ALL

Agora veja o que acontecerá ao utilizar os mesmo comandos:

img8 sudo permitido

Devemos garantir a segurança do sistema permitindo que apenas os usuários pré-definidos por grupos no domínio consiga realizar autenticação remota com o ssh. Para isso basta configurar o ssh para permitir acesso apenas de usuários do domínio que estejam cadastrados em determinado(s) grupo(s) inserindo a seguinte linha no final do arquivo /etc/ssh/sshd_config

AllowGroups redes

Obs.: Atente-se às letras maiúsculas e minusculas desta linha, pois, se errar o ssh não conseguirá iniciar.

Obs.: redes, nessa linha é o grupo de usuários do domínio definido para o acesso remoto.

Observe as tentativas de acesso dos usuários através do SSH:

img9 auth ssh

Podemos verificar que o usuário carlos.teste não consegue acessar remotamente o servidor através do ssh, porém a usuária carla.teste consegue por ser membro do grupo redes do domínio e que está permitido acesso nas configurações do openssh-server.

img10 auth ssh

Conclusão:

Com isso conseguimos a integração de sistemas operacionais GNU/Linux e Microsoft Windows através de autenticação centralizada, possibilitando rastreabilidade, auditoria, gerenciamento centralizado de usuários, senhas e permissões. Conseguimos garantir a segurança com a limitação de perfis de acesso remoto, assim como, a não necessidade da divulgação da senha do usuário root para todos os analistas que precisam acessar o servidor para realizar uma atividade qualquer.

Referências:

https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory

http://gutocarvalho.net/dokuwiki/doku.php/autenticando_debian_em_active_directory_via_kerberos_e_pam

http://www.guilhermearaujo.com.br/artigos/linux/ingressar-desktop-gnulinux-no-dominio-active-directory-47.html


Imprimir  
Adicionar comentário