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

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

Nosso Ambiente

 

  • server01: Debian 10 instalado com ip 192.168.0.40 e é controlador de domínio
  • server02: Debian 10 instalado com ip 192.168.0.41 e é controlador de domínio
  • ubuntu20: Ubuntu Server Instalado com ip 192.168.0.43 e  é/será um membro do domínio
  • ubuntu: Ubuntu Instalado com ip 192.168.0.55 e  é/será um membro do domínio

 

IDs de Usuários e Grupos Locais no Linux

Localmente, o Linux  guarda seus usuários dentro de /etc/passwd e grupos dentro de /etc/group. Nesses arquivos cada usuário ou grupo possui um número que o identifica.

Exemplo:

elder@ticpd:~$ cat /etc/passwd 
.....
maria:x:1001:1002::/home/maria:/bin/sh
.....

ID aqui vem de identificação. Para usuários esse id é chamado de UID, para grupos de GID.

Acima, o uid(ou user id) da usuária maria é 1001. o gid(ou group id) dela é 1001 também.

Acontece que os usuários do samba, para constarem localmente, isto é, dentro de /etc/passwd e em /etc/group, precisam ser mapeados;  precisam aparecer localmente contendo seus nomes e identificadores numéricos.

 

Winbind e Seus Mapeamentos

 

Ao criarmos um usuário no controlador de domínio esse usuário recebe uma identificação numérica chamada de SID.  Estou falando aqui de usuários criados no servidor com  samba instalado, pois num PC comum, que não é servidor,  a identificação é chamada de UID e GID  e não SID.

Para converter um usuário ou grupo criado no domínio para um usuário ou grupo local um mapeamento entre SIDs e IDs precisa ser feito. Este é um dos trabalhos que o winbind realiza.

Os usuários e grupos são trazidos do servidor e os IDs são gravados localmente a partir de um intervalo que definimos, por exemplo, quero que os IDs para usuários do domínio comecem em 10000(dez mil) e termine em 20000(vinte mil). O primeiro usuário do domínio terá o ID 10000(dez mil), o segundo 10001…..

Esses IDs são guardados no PC comum, no que não é o servidor :), no PC que é um membro do domínio.

Repetindo: A conversão/mapeamento do SID para ID é feita pelo winbind e essas informações convertidas são guardadas em uma base de dados localizada no pc membro do domínio e não no servidor. Isso significa que se essa base de dados é deletada ou corrompida não haverá nenhuma forma do winbind sabver qual ID de usuário ou grupo corresponde com o seu SID  no domínioEsse alerta em vermelho acima é válido para os Backends RID e AutoRID. O backend AD Pega IDs localizados dentro do servidor. Falaremos sobre isso mais tarde.

Winbind trabalha junto com o Name Service Switch(ou nsswitch) para tradução de nomes.

Winbind oferece informações para o nsswitch. Com essas informações o nsswitch  resolve os nomes de usuários e grupos que estão no domínio para aparecerem localmente no computador Linux do usuário.

 

Para configurar o winbind no nsswitch basta que dentro de /etc/nsswitch.conf  digitemos a palavra winbind na frente de passwd e group:

elder@ticpd:~$ cat /etc/nsswitch.conf 
passwd:         files winbind
group:          files winbind
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

Assim o nsswitch irá resolver nomes de usuários e grupos de dentro de /etc/passwd e /etc/group.

Repetindo mais uma vez: o Winbind trabalha com mapeamentos, isto é, ele vincula o nome do usuário e grupo a um número, conhecido como ID.

Essa mapeamento é feito através do que chamamos de beck ends. Vamos falar sobre esses backends: ‘ad’, ‘rid’, ‘autorid’ e tdb.

 

Back ends

 

As configurações de qual backend escolher, qual intervalo de IDs e se os usuários terão o mesmo shell(bash, sh…) ou as pastas home dentro do mesmo diretório, todas essas decisões são feitas editando o arquivo smb.conf.

A depender de qual Backend escolhermos a maneira de como configuramos o arquivo smb.conf mudará.

 

AD

o back end AD implementa uma API somente leitura para ler informações de usuários e grupos do ACtive Directory(AD). Esse back end é baseado no RFC 2307.

 

Exemplo de smb.conf Usando o back End AD

O smb.conf editado aqui é o do computador linux que será membro(ubuntu e ubunt20). Lembre-se de trocar LAB e LAB.LOCAL pelo nome do seu domínio.

Não coloque essas linhas dentro do smb.conf do Controlador de Domínio(server01 ou server02)!

Abaixo está um exemplo do smb.conf configurado para usar o back end AD.

[global]

security = ADS
workgroup = LAB
realm = LAB.LOCAL

# - como o backend ad é somente leitura 
# - devemos usar um de escrita, usaremos o tdb. 
# O sinal de * representa o domínio padrao.
idmap config * : backend = tdb
idmap config * : range = 3000-7999

# idmap config para o domínio LAB
idmap config LAB:backend = ad
idmap config LAB:schema_mode = rfc2307
idmap config LAB:range = 10000-99000
idmap config LAB:unix_nss_info = yes

# Define o shell e o caminho para o diretorio home dos usuarios
template shell = /bin/bash
template homedir = /home/%U
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

 

O back end AD ler as informações do Controlador de Domínio.

Os IDs ficam dentro do Controlador de Domínio, ou seja, diferentemente do RID e AutoRID, não ficam armazenados dentro da distro linux que é membro do domínio. Essa é uma grande vantagem!

A grande desvantagem do back end AD é que esses IDs(números) dos usuários têm que ser adicionados manualmente. Isso mesmo! Ao criar um usuário teremos que escolher o seu número(UID) e o número que representará o seu grupo(GID).

 

Exemplo criando um usuário:

Ao criar um novo usuário no servidor samba já podemos aproveitar e usar as opções –uid-number e   –gid-number.

No servidor server01, que é controlador de domínio(DC), abra o terminal e acesse a pasta /usr/local/samba/bin

elder@server01:~$ cd /usr/local/samba/bin

Execute “samba-tool create user…” para criar um usuário qualquer. Criarei o usuário paulo. Aqui aviso que o usuário paulo terá o uid 10002 e o gid também 10002.

elder@server01:/usr/local/samba/bin$ sudo ./samba-tool user create paulo --uid-number=10002 --gid-number=10002

 

Acesse a pasta  /usr/local/samba

elder@server01:~$ cd /usr/local/samba/

Use um dos dois comandos abaixo:

  • samba-tool user show paulo
  • ldbsearch -H ./private/sam.ldb ‘name=paulo*’ 

usarei o primeiro

elder@server01:/usr/local/samba$ sudo ./bin/samba-tool user show paulo
dn: CN=paulo,CN=Users,DC=lab,DC=local
objectClass: top
.....
name: paulo
objectGUID: 9e7f034b-7b9a-4561-905d-e0e98358446c
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
.......
userPrincipalName: paulo@lab.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=lab,DC=local
uidNumber: 10002
gidNumber: 10002
pwdLastSet: 132847478824657990
userAccountControl: 512
uSNChanged: 8628
distinguishedName: CN=paulo,CN=Users,DC=lab,DC=local

 

Exemplo Editando um usuário existente:

E para os casos de usuários que já existem?  Se criamos um usuário sem o alimentar o samba-tool com “–uid-number=…    –gid-number=…”  precisaremos editar e acrescentar esses atributos.

Iremos editar o usuário joao. Ele não possui os atributos  uid e gid.

Para editar podemos usar um dos dois comandos abaixo:

    • samba-tool user edit joao
    • ldbedit -H ./private/sam.ldb ‘name=joao*’

 

Usarei a primeira opção. Adicione as linhas alaranjadas abaixo:

elder@server01:/usr/local/samba$ sudo ./bin/samba-tool user edit  joao
dn: CN=joao,CN=Users,DC=lab,DC=local
objectClass: top
......
cn: joao
.......
primaryGroupID: 513
objectSid: S-1-5-21-3600158205-1358415253-1697110825-1605
accountExpires: 9223372036854775807
sAMAccountName: joao
sAMAccountType: 805306368
userPrincipalName: joao@lab.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=lab,DC=local
lastLogonTimestamp: 132826670534470080
lastLogon: 132829380566354630
logonCount: 25
gidNumber: 10003
uidNumber: 10003
whenChanged: 20211223202720.0Z
uSNChanged: 8632
distinguishedName: CN=joao,CN=Users,DC=lab,DC=local

 

O Grupo Primário

Temos que definir um gidNumber para o grupo primário. Se não fizermos isso os usuários não irão ser trazidos para o samba membro.

Por exemplo, nos laboratórios, eu tive que definir o “domain users” com o gidNumber de 10999. Só aí os usuários foram disponibilizados no samba membro.

Como fazer?

#1 No server01 ou server02, abra o terminal

#2 Execute o comando abaixo:

sudo /usr/local/samba/bin/samba-tool group edit "domain users"

#3 Insira o atributo “gidNumber: 10999”. O número pode ser um de sua escolha, desde que seja único atual e futuramente.

dn: CN=Domain Users,CN=Users,DC=lab,DC=local
objectClass: top
objectClass: group
cn: Domain Users
description: All domain users
instanceType: 4
whenCreated: 20210720140831.0Z
uSNCreated: 3849
name: Domain Users
objectGUID: baa9a589-fc1a-4906-9070-6f33d08b2158
objectSid: S-1-5-21-3600158205-1358415253-1697110825-513
sAMAccountName: Domain Users
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=lab,DC=local
isCriticalSystemObject: TRUE
memberOf: CN=Users,CN=Builtin,DC=lab,DC=local
gidNumber: 10999
whenChanged: 20211227195517.0Z
uSNChanged: 8645
distinguishedName: CN=Domain Users,CN=Users,DC=lab,DC=local

 

Vantagens do back end AD

  • Administração centralizada Controlador de Domínio(DC) do Active Directory(AD)
  • Os IDs serão consistentes em todos os clientes samba que usam o ad como back end
  • Os atributos uidNumber e gidNumber só precisam ser criados uma vez. Isso pode ser feito ao criar o usuário
  • Como os IDs são guardados no servidor controlador de domínio , no pc membro os IDs são apenas guardados em cache. Se o cache se corromper os dados informações de proprietário dos arquivos não serão perdidas.

Desvantagens do back end AD

  • Deveremos manualmente monitorar os valores IDs criados para evitar duplicados
  • Os valores para os atributos uidNumber e gidNumber devem ser criados manualmente

 

RID

O back end RID também implementa uma API somente leitura para obter informações de usuários e grupos do Active Directory Controlador de Domínio.  Ao contrário do back end AD onde temos que atribuir manualmente os IDs aos usuários, o back end RID atribui IDs automaticamente por domínio. Porém, diferentemente do back end AD, o back end RID armazena esses IDs dentro do pc membro do domínio e não dentro do Controlador Samba no Active Directory.

Usando o RID como back end não precisaremos criar uidNumber e gidNumber, eles serão criados e atribuídos automaticamente

 

Exemplo de smb.conf Usando o back End RID

[global]

security = ADS
workgroup = LAB
realm = LAB.LOCAL

# O sinal de * representa o domínio padrão.
# - Temos que usar um back end com leitura e escrita, como o tdb.
idmap config * : backend = tdb
idmap config * : range = 3000-7999
# - You must set a DOMAIN backend configuration

idmap config LAB : backend = rid
idmap config LAB : range = 10000-999999

template shell = /bin/bash
template homedir = /home/%U

 

Vantagens do back end RID

  • Fácil de configurar
  • IDs são monitorados automaticamente
  • Requere apenas acesso de leitura do controlador de domínio
  • todas as contas de usuários e grupos estarão automaticamente disponíveis no pc membro do domínio
  • nenhum atributo é preciso ser criado manualmente para usuários e grupos.

 

Desvantagens do back end RID

  • Todos os usuários no membro do domínio recebem o mesmo shell de login e caminho de pasta home
  • Os números IDs dos usuários e grupos são somente os mesmos em outros membros que também usem o  back end rid e se o mesmo intervalo de IDs forem configurado para o domínio, exemplo, ter esse mesmo intervalo em todos: idmap config LAB : range = 10000-999999
  • Todas as contas de usuários e grupos são disponíveis no pc membro.  Não poderemos deixar de  disponibilizar um usuário ou grupo. Ou todos ou nada.

 

 

AUTORID

O back end AutoRID funciona semelhante ao RID, mas pode automaticamente atribuir IDs para diferentes domínios. Isso significa que se tivermos mais de um domínio não precisaremos criar vários “idmap config”; nisso incluo o domínio padrão, aquele representado pelo *

 

Exemplo de smb.conf Usando o back End AutoRID

[global]

security = ADS
workgroup = LAB
realm = LAB.LOCAL

idmap config * : backend = autorid
idmap config * : range = 10000-24999999

template shell = /bin/bash
template homedir = /home/%U

 

Obs.: Depois de definir o intervalo e o Samba começar a usá-lo, você só pode aumentar o limite superior do intervalo. Qualquer outra mudança no intervalo pode resultar em novas atribuições de ID e, portanto, na perda de propriedade de arquivos. 

 

Vantagens do back end AUTORID

  • Não há IDs duplicados mesmo em um ambiente com vários domínios
  • Não precisamos atribuir manualmente IDs, shells e caminhos para pasta home
  • Todos os usuários e grupos com UID e GID dentro do mesmo intervalo serão automaticamente disponibilizados no membro do domínio.

Desvantagens do back end AUTORID

  • IDs de usuários e grupos não são os mesmos em todos os membros do domínio
  • Todas as contas de usuários e grupos são disponíveis no pc membro. A não ser os usuários e grupos com IDs fora intervalo.
  • Todos os usuários pegam o mesmo shell de login e pasta home. Mas podemos usar variáveis para contornar essa situação.

 

 

 

Fontes: wiki.samba

Leitor voraz e um dos administradores do GNU/Linux Brasil no Whatsapp, facebook, youtube e nesse dito site: www.gnulinuxbrasil.com.br

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *