Samba 24: As 7 Funções(Roles) FSMO

No Artigo Samba 19: Unindo(Joining) Um Samba a Outro Domínio  adicionamos um outro servidor ao domínio.

Então, no domínio lab.local temos adicionados os servidores server01 e server02.  As alterações feitas em um servidor são replicadas para o outro.

Falando de alterações entre servidores samba,  no antigo domínio NT4, existia apenas um servidor responsável por todas as mudanças, isto é, um servidor samba era o controlador de domínio primário(PDC)  que replicava as mudanças para os demais que eram apenas controladores de domínio de backup(BDC). Alterações eram sempre feitas no PDC e replicadas para os BDCs. Por exemplo, uma conta de usuário era criada primeiramente no PDC e este replicava para os backups.

A abordagem acima é conhecida como Modelo de Mestre Único(Single-master Model).

Anos depois do sistema de Domínio NT4 a Microsoft criou o Active Directory(AD) .

O Active Directory foi criado levando em conta um outro modelo conhecido como Modelo de Multi-Mestre(Multi-Master Model).

Em um modelo Multi-Mestre todos os servidores podem executar tarefas ao mesmo tempo, todos são ativos.

Resumindo, quando o assunto é alteração, tarefas e mudança temos dois modelos:

  • Modelo de Mestre Único(Single-master Model) e
  • Modelo de Multi-Mestre(Multi-Master Model)

 

Mas, por mais que sejamos induzidos a pensar que o Modelo Multi-Mestre é o que reina atualmente, estamos bem enganados. Logicamente que também não é usado o modelo de replicação de mudanças do antigo NT4, mas é bem parecido.

Como a Replicação de Tarefas Funciona Atualmente?

Há diversos tipos de  tarefas no samba. Geralmente um servidor fica responsável por replicar aos demais servidores  essas tarefas.

Por exemplo,

Se um usuário altera a senha no Windows essa alteração é recebida pelo servidor samba  responsável pela replicação dessa tarefa e a replicação  da informação de alteração de senha para os demais servidores é feita.

 

Por que esse Artigo é Importante?

Em um ambiente com vários servidores samba um deles será o responsável pela replicação das alterações aos demais.

Se um servidor samba qualquer, que não seja o responsável, ficar offline, danificado, não teremos problema. Tudo continuará funcionando adequadamente já que outro servidor tomará o seu lugar.

Se o servidor samba offline for o responsável pela replicação das tarefas então temos um problema. Mas tenha calma, basta transferir a responsabilidade pelas tarefas para outro servidor.

Há diversas tarefas que o servidor DC pode ficar responsável. Geralmente essas tarefas ficam em apenas um servidor, mas isso não é a regra, podemos colocar umas tarefas em um servidor e outras em outros.

Para isso devemos estudar FSMO.

 

FSMO(Flexible  Single-Master Operations) ou Operações Flexíveis de Mestre Único

 

Sabe as palavras “mudanças” ou “alterações” mencionadas acima?  fsmo usa o termo “Operação“.

Essas operações são divididas em grupos chamados de roles(ou funções em português 🙂 ).  Há 7 roles. Abaixo listo cada uma:

  • PDC Emulator
  • RID Master
  • Schema Master
  • Domain Naming Master
  • Infrastructure Master
  • Domain DNS Zone Master role
  • Forest DNS Zone Master role

 

Vamos ver qual responsabilidade de cada role

PDC Emulator

 

Sincronização de tempo: O servidor com essa função é responsável por sincronizar o tempo/horário nos computadores que fazem parte do domínio.

Alteração de senha: Operação de troca de senhas em um servidor é replicada preferencialmente para o servidor samba que está como PDC Emulator.

Bloqueios de Contas: Bloqueio de contas são gerenciadas pelo servidor samba que contém o PDC Emulator

Falha de Autenticação: Quando o usuário coloca uma senha errada o erro primeiro é levado até o PDC Emulator e só depois o é enviada uma resposta para o usuário informando que houve erro de senha.

Console de Gerenciamento de Política de Grupo(GPMC): O console de gerenciamento de política de grupo comunica o PDC Emulator por padrão.

 

RID Master

RID vem de Relative Identifier ou Identificador Relativo.

O servidor samba proprietário da função RID Master é responsável por responder às solicitações de RID pool de todos os Controladores de Domínios(DC). É também responsável por mover objetos(usuários, computadores, grupos….) para outro domínio ou removê-los do domínio.

Todo objecto de segurança(usuário, computador, grupo…) é identificado por um sid. O sid desses objetos é composto por duas partes, o “sid do domínio” + “RID”.

Ficou confuso?

Para entendermos antes vamos falar sobre SID ou Security Identifier(Identificador Seguro) e RID(Relative Identifier). Lembrando que o samba, além de muitas outras coisas, é um controlador de domínio(DC: Domain Controller). O que é um domínio? www.gnulinuxbrasil.com.br é um domínio, categoriaoutros.com.br é outro domínio. Em nosso caso, criamos um domínio chamado lab.local; logicamente um domínio sem acesso externo, com acesso somente dentro da nossa empresa ou casa.  Não vamos entrar em detalhes aqui sobre domínio, mas acho que ficou fácil de entender.

No domínio lab.local temos computadores cadastrados e usuários criados(parte01 e parte02).

No Samba, e Active Directory da microsoft, todo domínio possui um SID que é um monte de letras que o identifica.

Execute o comando “net getdomainsid” para obter o sid do domínio

elder@server01:~$ sudo /usr/local/samba/bin/net getdomainsid
SID for domain LAB is: S-1-5-21-3600158205-1358415253-1697110825

O domínio lab.local tem o  sid  S-1-5-21-3600158205-1358415253-1697110825

Já para obtermos o sid de um usuário usamos “samba-tool user show nome_usuário“. Para filtrar somente a linha que nos interessa usarei “| grep Sid”. Se não usar grep aparecerá um monte de informação que não nos interessa no momento.

elder@server01:~$ sudo /usr/local/samba/bin/samba-tool user show elder | grep Sid
ldb_wrap open of secrets.ldb
objectSid: S-1-5-21-3600158205-1358415253-1697110825-1104

O Sid do usuário elder é    S-1-5-21-3600158205-1358415253-16971108251104

Onde

  • domain sid = S-1-5-21-3600158205-1358415253-1697110825
  • rid =  1104

Podemos afirmar que “domain  sid” + “rid” é a identidade de um objeto de segurança(usuário, computador, grupo)

Podemos ver ainda que a única parte que muda é o RID.

Vejamos outro exemplo, só que com um computador.

elder@server01:~$ sudo /usr/local/samba/bin/samba-tool computer show server01 | grep Sid
ldb_wrap open of secrets.ldb
objectSid: S-1-5-21-3600158205-1358415253-1697110825-1000

 

Vendo o sid do grupo Domains Admins:

elder@server01:~$ sudo /usr/local/samba/bin/samba-tool group show "Domain Admins" | grep Sid
ldb_wrap open of secrets.ldb
objectSid: S-1-5-21-3600158205-1358415253-1697110825-512

 

Sei que esse assunto está longo, mas não deixa de ser interessante.

Vamos retornar ao tema: RID Master

O Servidor responsável pelo RID Master  concede a cada servidor samba(DC) um espaço/intervalo para armazenar de 500 RID. Ou seja, um servidor   ao criar um objeto de segurança(grupo, usuário, computador) terá seu intervalo/espaço de RIDs diminuído.

Chamamos de RID Pool a esse espaço concedido pelo servidor RID Master a cada outro servidor

O servidor samba RID Master garante que cada RID pego do RID Pool seja único, nunca repetido com nenhum dos outros RIDs criados nos outros servidores DCs.

Lembrando que RID é somente a última parte daquele monte de letras, visto que o restante é o SID do domínio que sempre se repetirá.

 

Outros Pontos Importantes Sobre o RID Master

  • O servidor DC com responsável pelo RID Master tem que estar online/ligado quando um novo DC é juntado/promovido ao domínio, então esse novo DC receberá o Pool de RIDs, ou seja , o intervalo para 500 RIDs únicos.
  • O servidor DC com responsável pelo RID Master tem que está online para que os outros DCs atualizem seus intervalos de RID Pool quando necessário.
  • Juntar(join) um novo DC: Não é possível juntar um novo DC ao domínio quando o RID Master estiver offline.
  • Se um RID Master ficar offline  os outros servidores samba, DCs, ainda  continuarão com seus espaços de RIDs a ser usado, mas quando esse espaço esvaziar nenhum usuário, grupo ou computador poderá ser criado, visto não haver mais RIDs disponíveis e nem o RID Master para recarregar.

 

Schema Master

O DC possuindo esse role, Schema Master, é o único em uma floresta que tem a permissão de atualizar o directory schema.

 

Domain Naming Master

O DC que possui esse role, Domaing Naming Master, é o único responsável por mudanças em todo espaço de nome de domínio(domain naming space) da floresta. Isso significa que o servidor samba que possui esse role é o único que pode adicionar ou remover da floresta:

  • domínio
  • confiança em um diretório externo e
  • partições de aplicações

 

Infrastructure Master

O servidor controlador de Domínio(DC) que é proprietário dessa rol, Infrastructure Master, é responsável por atualizar os SIDs objetos e “distinguished names” em uma referência de objeto de domínio cruzado.  

Confuso essa explicação foi retirada do site wiki.samba.org e é bem confusa!

 

Domain DNS Zone Master

O DC proprietário dessa role é responsável por coordenar a adição e remoção de qualquer zona de DNS nos DCs com Servidores DNS que hospeda o domínio.

 

Forest DNS Zone Master

Essa role faz praticamente a mesma coisa que a role acima(Domain DNS ZOne Master) com a diferença que está relacionado com floresta enquanto a role acima está relacionada apenas com o domínio.

O DC proprietário desse role é responsável por coordenar a adição  e remoção de registros nos Servidores DNS que hospeda a zona top-level do DNS. Esses registros contém os nomes dos servidores de Catálogo Global(Global Catalog ou GC).

 

Vendo o Proprietário das Roles

Para vermos qual servidor é ó proprietário de uma role precisarmos executar o comando “samba-tool fsmo show“. Vejamos abaixo:

elder@server01:~$ sudo /usr/local/samba/bin/samba-tool fsmo show
ldb_wrap open of secrets.ldb
SchemaMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
InfrastructureMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
RidAllocationMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
DomainNamingMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=SERVER01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local

Podemos ver acima que o servidor chamado SERVER01  está como responsável por todas as 7 roles.

 

Em Versões Mais Antigas do Samba

Em servidores com samba mais antigos, mais precisamente com samba versão 4.3.0 ou anterior, ao executarmos o comando acima veremos somente 5 roles ao invés de 7.

Nesse caso de uma versão antiga do samba, para vermos as 7 roles devemos executar os dois comandos abaixo.

ldbsearch --cross-ncs -H /usr/local/samba/private/sam.ldb '(fsmoroleowner=*)' |\
 grep 'dn:' | sed 's|dn: ||'

e

ldbsearch --cross-ncs -H /var/lib/samba/private/sam.ldb -b "CN=Infrastructure,DC=lab,DC=local" \
-s base fsmoroleowner

Conclusão

É bom sabermos a função de cada role para estarmos cientes do impacto caso o servidor proprietário da role fique desconectado por algum problema. Por exemplo, se um servidor responsável pela role/função PDC Emulator ficar offline os computadores dos usuário não receberão o horário correto do servidor samba.

 

 

 

 

Fontes: samba.wiki, samba.org

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 *