Samba 27: Configurando Samba Como um Membro do Domínio – Parte 01

ATENÇÃO: APENAS LEIA ESSE ARTIGO, NÃO SE PREOCUPE EM EXECUTAR COMANDOS.

 

Clique aqui para saber o que é um domínio

 

Um domínio é uma área protegida e essa área contém um conjunto de dispositivos: usuários, computadores, impressoras. O Acesso à essa área deve ser por autorização, geralmente por usuário e senha. Esse domínio possui um nome no estilo exemplo.local, teste.net…

Active Directory, ou simplesmente AD, foi criado  pela Microsoft e é um conjunto de serviços. Dentre esses serviços temos

  • LDAP que é um banco de dados para armazenar informações sobre objetos. Essas informações podem ser nome, sobrenome, telefone, endereço, idade…. Em nosso caso, são informações relacionadas aos produtos do domínio: nome do domínio, nome dos usuários, computadores, dns e muito mais.
  • DNS  é um serviço que traduz ou converte nome em endereço IP e vice versa. Por exemplo, ao acessar o computador chamado casa01 estarei indo para o ip 192.168.0.100.
  • Controlador de Domínio: Como explicado acima, o domínio concede segurança por meio de acesso autenticado.

Um servidor pode atuar somente como Controlador de Domínio(DC) e escolher não ser um Active Directory(AD). Mas se ele for um AD então será um DC 🙂

O Samba só passou a atuar como AD a partir da versão 4. Antes disso era somente um DC.

 

Introdução

Aqui chegamos num ponto onde, assim como a maioria dos usuários, apanhei um pouco para poder conseguir inserir uma distro Linux como membro de um domínio. Essa dificuldade deve-se ao fato de documentação confusa na internet; há muitas opções a serem consideradas e escolhidas. Por exemplo, precisamos saber a diferença entre os back ends: rid, autorid, tdb e ad; escolher um deles para colocarmos dentro do arquivo  smb.conf. Ainda dentro do smb.conf há a opção “security=…” que induz a pensarmos enganosamente como sendo o método como o samba trabalha com segurança. Mas não, é mais o modo como o cliente irá ser autenticado ao acessar o  servidor. A opção security pode receber o valor server que também pode nos induzir ao erro de pensar que  “security=server” transformará o computador em um servidor. Reforço que é mais a maneira como a autenticação é feita, como o acesso é autorizado.

 

Relembrando

 

No artigo intitulado “Debian Buster: Instalando o Samba” instalamos o samba no servidor chamado server01 e criamos o domínio lab.local. Então server01 é o controlador do domínio(DC)  lab.local.

No artigo de número 19, Samba 19: Unindo(Joining) Um Servidor Samba ao Domínio, adicionamos ao lab.local o server02 como sendo também um Controlador de Domínio.

Nosso domínio lab.local atual está  assim:

  • server01: faz parte do domínio lab.local e contém as 7 roles fsmo.
  • server02: faz parte do domínio lab.local mas não possui nenhuma role.

 

server01 e server02 são Controladores de Domínio(DC). Eles replicam dos dados entre si. Se um falhar teremos o outro para continuar a produção.

Lembre-se: Domínio é um espaço e dentro dele inserimos dispositivos. Já temos dois objetos dentro do domínio e iremos adicionar mais dois.

Porém, esse artigo é sobre um computador com samba adicionado como membro de um  domínio. Que fique claro: como um membro e não como DC. Iremos adicionar ao domínio um membro e não um Controlador de Domínio.

Iremos adicionar

  • ubuntu20: PC com Ubuntu server versão 20 a ser adicionado como membro. Não possui interface gráfica. Usaremos ele como servidor de arquivos.
  • ubuntu: PC com Ubuntu versão 18 a ser adicionado como membro. Esse Ubuntu possui Interface Gráfica e nele poderemos logar com usuários do domínio lab.local.

 

Primeiramente iremos adicionar o ubuntu20 como membro do nosso domínio lab.local.

 

Samba Como Membro do Domínio

Um computador com samba instalado e adicionado ao domínio como membro não possui e nem executa serviços de domínio; mas pode ser usado para:

  • Usar os usuários e grupos do domínio lab.local para aplicar permissões aos seus próprios arquivos locais.
  • Se o membro reconhece usuários e grupos  e pode aplicar permissões de acesso então pode servir como um servidor de arquivos. Podemos compartilhar pastas do servidor membro com os demais computadores da rede.
  • Pode ser usado como servidor de impressão.
  • Através da biblioteca PAM(Pluggable Authentication Modules for Linux) usuários do domínio podem ser usados para logar/acessar um computador linux. Quando você ligar o computador com Ubuntu, por exemplo, poderá  logar  com o usuário que não é local e sim do Domínio.
  • Podemos também usar os usuários do domínio para autenticarmos serviços(programas) instalados.

 

Modo de Segurança(Security Mode) para smb.conf

 

De antemão avisamos que “security = ads” será a opção que usaremos.

Security Mode é a forma como a autenticação é realizada no samba.

Definiremos qual será o Security Mode editando o arquivo smb.conf; dentro da seção [global] do smb.conf usamos “security = ads”

Há dois tipos de security mode: share-level ou user-level

share-level possui somente share como opção. Já user-level, por sua vez, possui 4 alternativas: user, server, domain, ads.

Resumindo, “security = …. ”  pode ser:

  • security = share
  • security = server
  • security = user
  • security = domain
  • security = ads

 

security = share 

Nesse modo o servidor recebe somente a senha sem o nome do usuário. Uma senha é enviada para cada compartilhamento.

Esse modo não é recomendado para ser usado.

Evite usar share-level.

 

security = server

É um modo que era usado quando o samba não era capaz de ser usado como um “membro de domínio”.

Esse modo não deve ser usado. Há diversas brechas de segurança.

 

security = user

Esse user-level é o padrão para o samba. Mesmo que não vejamos essa diretiva dentro de smb.conf ela é usada.

“usuário+senha” são enviados do cliente para o servidor. Se o servidor aceitar o usuário+senha então o usuário terá acesso à todas as pastas compartilhadas. Não precisará conceder uma senha para cada compartilhamento.

 

security = domain

Com essa diretiva é possível tonar o computador um membro do domínio como sendo um membro nativo do Active Directory.

Se você quiser usar kerberos como método de autenticação então não use “security = domain“. Para usar kerberos  “security = ads” deverá ser usado.

 

security = ads

A mesma explicação para “security = domain” mas aqui será usado kerberos. Essa é a melhor opção para tornar o servidor um membro do domínio.

 

Winbind

Winbind é um programa que faz parte do samba.

Winbind pode trabalhar juntamente com nsswitch(Name Service Swttch), PAM, ntlm_auth e logicamente, com o próprio samba.

O serviço nsswitch tem a função de obter informação de usuários e do sistema. Essas informações são obtidas de bancos de dados como NIS e DNS. O Arquivo a ser configurado é o /etc/nsswitch.conf. Os usuários e grupos são reconhecidos pelo computador membro do domínio graças ao winbind.

O winbind além de usar nsswitch também pode usar o módulo PAM para prover autenticação de usuários. Os arquivos a serem configurados estão dentro de /etc/pam.d/.O uso de PAM aqui nesse artigo está mais relacionado ao acesso com interface gráfica, aquela tela que aparece ao ligarmos o computador pedindo usuário e senha.

Winbind também faz uso o kerberos. O kerberos é uma plataforma de autenticação. Enquanto o PAM está mais relacionado com Login do tipo “usuário e senha”, kerberos trabalha com autenticação via rede com tickets.Tickets são as credenciais do Kerberos e é um conjunto de informações usadas para validar a identidade do computador na rede. Use o comando “klist” para verificar seus tickets.

Resumindo: Um computador Linux membro do domínio recebe usuários usando nsswitch e esses usuários podem autenticar usando Kerberos. Se quiser acesse sua distro com login e senha então será usado PAM.

Programas a Serem Instalados

Logicamente que o samba tem que estar instalado ou compilado. Aqui iremos instalá-lo via repositório

sudo apt install samba -y

Instalaremos o winbind

sudo apt install winbind -y

Temos que instalar o libnss-winbind para que o winbind use o nsswitch.

sudo apt install libnss-winbind -y

Outro programa a ser instalado é o libpam-winbind para que exista conversa entre winbind e módulo PAM. O libpam-winbind só precisa ser instalado se você quiser que os usuários do domínio consigam fazer login digitando usuário e senha na tela inicial do computador membro.

sudo apt install libpam-winbind  -y

Outros programas a serem instalados por estarem relacionados com o samba é o kerberos

sudo apt install krb5-user -y

 

 

Winbind Faz Mapeamento Entre Usuários  e Seus Números(Identidades)

 

Todo usuário possui um nome: joao, elder, maria etc. Todo usuário também possui um número que o identifica, que o distingue dos demais. Esse número é chamado de UID. Os grupos também possuem um número de identificação e é chamado de GID.

Os nomes são apenas uma forma do computador ser legal conosco, seres humanos. O computador lida realmente com números. Números ficariam difíceis de decorarmos, não é mesmo?

Em uma distro Linux recém instalada, enxuta, haverá em /etc/passwd usuários criados automaticamente para uso do sistema operacional e programas/serviços e haverá o usuário root e outro com o nome seu nome.

Vejamos um trecho do conteúdo em /etc/passwd

elder@ticpd:~$ cat /etc/passwd
root:x:0:0:Super Usuario:/root:/bin/bash
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
.........
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
.........
elder:x:1000:1000:Elder Rodrigues,,,:/home/elder:/bin/bash
maria:x:1001:1002::/home/maria:/bin/sh

As linhas acima são dividas por dois pontos “:”

Verificando a primeira linha temos:

  • root: nome do usuário
  • x: Indica que a senha está dentro de um arquivo protegido
  • 0: o primeiro zero é o uid do usuário
  • 0: esse segundo zero é o gid do grupo do qual o usuário pertence
  • Super Usuario: um comentário sobre o usuário. Nesse caso ele é um usuário poderoso, super.
  • /root: a pasta home desse usuário.
  • /bin/bash: o shell do usuário, usado no terminal para traduzir os comandos para o sistema. Nesse caso é o bash. Em outros casos pode ser o sh ou outros.

Agora observe que temos alguns usuários estranhos: bin, sys, mail e backup. Eles possuem, respectivamente, os uids e gids 2, 3, 8 e 34. São usuários para o sistema.

Observe meu usuário(elder) e o usuário maria. Como fui o primeiro usuário criado que não trabalha especificamente para o sistema então recebi uid e gid 1000. Maria possui o 1001.

Podemos afirmar com isso que esses usuários estão mapeados, ou seja, possuem seus uid  e gid.

Podemos afirmar ainda que os IDs de 0 até 999 pertencem a usuários com funções específicas para serviços. Os usuários regulares começam seus IDs a partir do 1000.

Essas contas de usuários são locais. E os usuários e grupos do domínio? Ainda não configuramos, mas devemos configurá-los para usarem uids e gids fora da faixa dos usuários locais e do sistema acima.

Para configurar o winbind dentro do smb.conf usamos as diretivas “idmap config”. Percebe-se que a palavra idmap é auto entendido como

mapear identidades ou
configurar mapeamento de identidades.

 

Backends do Winbind: AD, RID, AUTORID e TDB

 

Back End é a forma como um programa trabalha internamente. O Winbind possui essas formas de trabalhar: ‘ad’,  ‘rid’, ‘autorid’ e ‘tdb’.

AD, RID, tdb e AutoRID são Back Ends que usamos  na configuração do arquivo smb.conf do “samba membro” e dessa forma ele recebe as informações de usuários  e grupos do Controlador de Domínio.

a opção “idmap config….” é usada para indicar que esse é um samba membro usando winbind para receber informação do samba AD DC.

Os back ends rid, autorid e ad são epenas leitura. Eles apenas recebem informações.  É necessário colocar um back end de escritura que trabalhe junto com os de somente leitura. Nesse caso usamos o tdb.

Olha abaixo trecho de texto extraído do meu smb.conf. Os pontinhos significam textos que excluir para diminuir poluição visual. Não se preocupe com o significado de cada linha, por enquanto.

elder@ubuntu20:~$ cat /etc/samba/smb.conf
[global]
 ......
   security = ADS
   
   idmap config * : backend =  tdb
   idmap config * : range = 3000-7999
   idmap config LAB : backend = ad
   idmap config LAB : range = 10000-999999
    
 .......

Alerta: Não Use configuração do Winbind acima dentro do smb.conf de um Servidor samba que  seja um DC ou AD. Se colocar samba ficará com falha. 

 

Acima temos um exemplo que usa ad como back end. Como ele é somente leitura então definimos o tdb que é escrita.

 

Outras Observações:

A depender de qual back end for escolhido, a forma de receber(mapear) os usuários do Controlador de Domínio irá mudar.

A escolha de um back end também interfere  em:

  • de onde e como o usuário receberá seu número(id)? Esse número ficará alojado no servidor DC ou no membro do domínio?
  • Se tivermos mais de um domínio na rede, como lab.local e exemplo.local, esse id será o mesmo para qualquer domínio?
  • Esse id será atribuído automaticamente ou eu terei que digitá-lo manualmente para cada conta criada?
  • O diretório home de todos os usuários estará dentro de uma pasta somente? Por exemplo, dentro da pasta /home? Exemplo: /home/elder, /home/joao …? ou usuários poderão estar em diferentes locais?
  • o shell será o mesmo para qualquer usuário ou não? Todos terão como padrão /bin/bash ou /bin/sh?

 

tdb, rid, ad, autorid trabalham de formas diferentes e deveremos conhecer cada uma para tomamos a melhor decisão para nosso ambiente e necessidades.

Ficarei por aqui. Deixarei para continuar em outros artigos. Até lá!

 

 

 

Fontes: manual winbind, wiki.samba, old.samba.org, linux-pam.org, thegeekdiary, mit.edu, samba.org(backend ‘ad’), web.mit.edu(tickets), web.mit.edu(ver tickets), web.mit.edu(funcionamento), kerberos.org(o que é?)

One Comment to “Samba 27: Configurando Samba Como um Membro do Domínio – Parte 01”

Deixe um comentário

O seu endereço de e-mail não será publicado.