Usando o Samba como PDC

Em uma pequena rede, manter as senhas dos usuários sincronizadas entre as estações Windows e o servidor Samba não chega a ser um grande problema. No entanto, em redes de maior porte, isso pode se tornar uma grande dor de cabeça e passar a consumir uma boa parte do seu tempo. Para solucionar o problema, existe a opção de usar o servidor Samba como um controlador primário de domínio (PDC), onde ele passa a funcionar como um servidor de autenticação para os clientes Windows e, opcionalmente, armazenar os perfis dos usuários, permitindo que eles tenham acesso a seus arquivos e configurações a partir de qualquer máquina onde façam logon. Ao cadastrar um novo usuário no servidor Samba, ele automaticamente pode fazer logon em qualquer uma das estações configuradas. Ao remover ou bloquear uma conta de acesso, o usuário é automaticamente bloqueado em todas as estações. Isso elimina o problema de sincronismo entre as senhas no servidor e nas estações, além de centralizar a administração de usuários e permissões de acesso no servidor, simplificando bastante seu trabalho de administração. O primeiro passo é modificar o arquivo de configuração do Samba. Existem algumas regras adicionais para transformar o Samba em um controlador de domínio. A seção "global" deve conter as linhas "domain master = yes", "domain logons = yes", "logon script = netlogon.bat" e (importante) não deve conter a linha "invalid users = root", pois precisaremos usar a conta de root no Samba ao configurar os clientes. É preciso, ainda, adicionar um compartilhamento chamado "netlogon", que conterá o script de logon que será executado pelas estações. Continuando a lista de "exigências", é necessário também que o modo de segurança esteja configurado em nível de usuário (security = user) e que o uso de senhas encriptadas esteja ativado (encrypt passwords = yes). Na verdade, não é obrigatório incluir estas duas linhas no smb.conf, já que estes valores são usados por default pelo Samba 3, mas é sempre interessante usá-los em exemplos e modelos de configuração para fins didáticos e para deixar claro que o arquivo não deve ter opções que conflitem com elas. Embora não seja obrigatório, é fortemente recomendável ativar o uso do tdbsam como backend, adicionando a linha "passdb backend = tdbsam", como vimos a pouco. Usar o smbpasswd em um PDC oferece várias desvantagens. A principal delas é que o smbpasswd armazena um conjunto bastante incompleto de atributos referentes aos usuários, de forma que atributos como o SID (um código de identificação único a cada usuário, usado como verificação de segurança) ficam em branco ou são gerados dinamicamente durante os acessos, o que pode quebrar o suporte aos roaming profiles em algumas situações. O uso do tdbsam soluciona estes problemas. Este é um exemplo de arquivo de configuração do Samba para um controlador de domínio. Ele não contém as configurações para compartilhamento de impressoras, lixeira e outras opções que você pode adicionar (juntamente com os compartilhamentos desejados) depois de testar a configuração básica:

[global]
workgroup = Dominio
netbios name = GDH server
string = Samba PDC
domain master = yes
domain logons = yes
logon script = netlogon.bat
security = user
encrypt passwords = yes
enable privileges = yes
passdb backend = tdbsam
preferred master = yes
local master = yes
os level = 100
wins support = yes

[netlogon]
comment = Servico de Logon
path = /var/samba/netlogon
read only = yes
browseable = no

[homes]
valid users = %S
create mask = 0700
directory mask = 0700
browseable = no

Acostume-se a sempre rodar o comando "testparm" depois de fazer alterações no arquivo, pois ele verifica a sintaxe e indica erros de configuração. Ao configurar o Samba como PDC, ele deve exibir a mensagem: "Server role: ROLE_DOMAIN_PDC", como em:

$ testparm 

Load smb config files from /etc/samba/smb.conf
Processing section "[netlogon]"
Processing section "[homes]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC

As linhas "preferred master = yes", "local master = yes" e "os level = 100" fazem com que o servidor assuma também a função de master browser da rede. É comum que o PDC acumule também a função de master browser, mas, na verdade, uma coisa não tem relação com a outra. Você pode remover as três linhas e configurar outra máquina para assumir a função de master browser se preferir. Depois de configurar o arquivo, verifique se a conta root do sistema foi cadastrada no Samba e se as senhas estão iguais. Caso necessário, use o comando "smbpasswd -a root" para cadastrar o a conta de root no Samba. Aproveite para criar a pasta "/var/samba/netlogon" e configurar corretamente as permissões:

# mkdir -p /var/samba/netlogon
# chmod 775 /var/samba/netlogon

Com o "775" estamos permitindo que, além do root, outros usuários que você adicionar no grupo possam alterar o conteúdo da pasta. Isso pode ser útil caso existam outros administradores de rede além de você. Cadastre agora os logins dos usuários, com as senhas que eles utilizarão para fazer logon a partir das máquinas Windows. Nesse caso, não é preciso se preocupar em manter as senhas em sincronismo entre o servidor e as estações. Na verdade, as contas que criamos aqui não precisam sequer existir nas estações, pois o login será feito no servidor. Para adicionar um usuário de teste "joao", use os comandos:

# adduser joao
# smbpasswd -a joao

É importante criar também a pasta "profile.pds" dentro do diretório home do usuário, onde o cliente Windows armazena as informações da sessão cada vez que o usuário faz logon no domínio:

# mkdir /home/joao/profile.pds

Ao rodar este comando como root, não se esqueça de ajustar as permissões da pasta, de forma que o usuário seja o dono:

# chown -R joao:joao /home/joao/profile.pds

Aproveite e crie a pasta "profile.pds" dentro do diretório /etc/skel, de forma que ela seja criada automaticamente dentro do home dos usuários que criar daqui em diante:

# mkdir /etc/skel/profile.pds

Além das contas para cada usuário, é preciso cadastrar também uma conta (bloqueada, e por isso sem senha), para cada máquina. Você deve usar aqui os mesmos nomes usados na configuração de rede em cada cliente. Se a máquina se chama "alesia" por exemplo, é preciso criar um login de máquina com o mesmo nome:

# useradd -d /dev/null -s /bin/false alesia$
# passwd -l alesia$ # smbpasswd -a -m alesia

Note que, nos dois primeiros comandos, é adicionado um "$" depois do nome, que indica que estamos criando uma conta de máquina, que não tem diretório home (-d /dev/null), não possui um shell válido (-s /bin/false) e está travada (passwd -l); a conta é válida apenas no Samba, onde é cadastrada com a opção "-m" (machine). Essas contas de máquina são chamadas de "trusted accounts" ou "trustees". Lembre-se de que para usar este comando o arquivo "/etc/shells" (no servidor) deve conter a linha "/bin/false". Em caso de erro ao adicionar a máquina, use o comando abaixo para adicionar a linha e tente novamente:

# echo "/bin/false" >> /etc/shells
(este comando só funciona se executado diretamente usando o root, não funciona se executado usando o sudo)

Se preferir, você pode adicionar as contas de máquina dentro de um grupo do sistema ("maquinas" ou "machines" por exemplo). Nesse caso, crie o grupo usando o comando "groupadd" e use o comando abaixo para criar as contas de máquina já incluindo-as no grupo:

# useradd -g maquinas -d /dev/null -s /bin/false alesia$

Por último, é necessário criar o arquivo "/var/samba/netlogon/netlogon.bat", um script que é lido e executado pelos clientes ao fazer logon. Você pode fazer muitas coisas através dele, mas um exemplo de arquivo funcional é:

net use h: /HOME
net use x: gdharquivos /yes

Este script faz com que a pasta home de cada usuário (compartilhada pelo Samba através da seção "homes") seja automaticamente mapeada como a unidade "H:" no cliente, o que pode ser bastante útil para backups, por exemplo. Naturalmente, cada usuário tem acesso apenas a seu próprio home. A segunda linha é um exemplo de como fazer com que determinados compartilhamentos do servidor sejam mapeados no cliente. O "net use x: gdharquivos /yes" faz com que o compartilhamento "arquivos" (que precisaria ser configurado no smb.conf), seja mapeado como o drive "X:" nos clientes. Lembre-se que o "gdh" dentro do netlogon.bat deve ser substituído pelo nome do seu servidor Samba, configurado na opção "netbios name =" do smb.conf. Mais um detalhe importante é que o arquivo do script de logon deve usar quebras de linhas no padrão MS-DOS e não no padrão Unix (que é o padrão na maioria dos editores de texto do Linux). Você pode criá-lo usando um editor de texto do Windows ou usar algum editor do Linux que ofereça esta opção. No Kwrite por exemplo, a opção está em: "Configurações > Configurar Editor > Abrir/Salvar > Fim de linha > DOS/Windows":

Mais uma configuração útil (porém opcional) é fazer com que o servidor armazene os arquivos e configurações do usuário (recurso chamado Roaming Profiles, ou perfis móveis), fornecendo-os à estação no momento em que o usuário faz logon. Isso permite que o usuário possa trabalhar em outras máquinas da rede e faz com que seus arquivos de trabalho sejam armazenados no servidor, reduzindo a possibilidade de perda de dados. Por outro lado, ativar os perfis móveis faz com que seja consumido mais espaço de armazenamento no servidor e aumenta o tráfego da rede, já que os arquivos precisam ser transferidos para a estação a cada logon. Isso pode tornar-se um problema caso os usuários da rede tenham o hábito de salvar muitos arquivos grandes na área de trabalho. Note que o servidor não armazena todos os arquivos do usuário, apenas as configurações dos aplicativos, entradas do menu iniciar, cookies, bookmarks, arquivos temporários do IE e o conteúdo das pastas "Desktop", "Modelos" e "Meus Documentos". Para ativar o suporte no Samba, adicione as duas linhas abaixo no final da seção "global" do smb.conf (abaixo da linha "logon script = netlogon.bat"):

logon home = %L%U.profiles
logon path = %Lprofiles%U

A variável "%L" indica, neste caso, o nome do servidor, enquanto o "%U" indica o nome do usuário que está fazendo logon. Dessa forma, quando o usuário "joao" faz logon é montado o compartilhamento "gdhprofilesjoao", por exemplo. Adicione também um novo compartilhamento, adicionando as linhas abaixo no final do arquivo:

[profiles]
path = /var/profiles
writeable = yes
browseable = no
create mask = 0600
directory mask = 0700

Concluindo, crie a pasta "/var/profiles", com permissão de escrita para todos os usuários:

# mkdir /var/profiles
# chmod 1777 /var/profiles

Cada usuário passa a ter uma pasta pessoal dentro da pasta ("/var/profiles/joao", por exemplo) onde as configurações são salvas. Apesar das permissões locais da pasta permitirem que qualquer usuário a acesse, o Samba se encarrega de permitir que cada usuário remoto tenha acesso apenas ao seu próprio profile. As estações Windows 2000 utilizam os perfis móveis automaticamente, quando o recurso está disponível no servidor Samba. Você pode verificar a configuração e, caso desejado, desativar o uso do perfil móvel no cliente no "Meu Computador > Propriedades > Perfis de Usuário > Alterar tipo". No Windows XP, o default foi alterado e o sistema tenta usar o perfil móvel por padrão, exibindo uma mensagem de erro (repetida a cada logon) caso o recurso não esteja disponível no servidor. Para eliminar as mensagens de erro é necessário desativar o uso dos perfis móveis, o que é feito através do utilitário "gpedit.msc", que pode ser chamado através do "Iniciar > Executar" (é necessário estar logado localmente, usando uma conta com privilégios administrativos). Dentro dele, acesse a opção "Configuração do computador > Modelos administrativos > Sistema > Perfis de usuário > Só permitir perfis de usuário locais" e mude a opção de "Não configurado" para "Ativado" (esta alteração precisa ser repetida em todas as máquinas):

Aqui vai mais um exemplo de configuração para o servidor Samba, incluindo a configuração para uso como PDC, o compartilhamento netlogon, suporte a perfis móveis e compartilhamento de impressoras:

[global]
netbios name = Byzantium
workgroup = Dominio
server string = Servidor PDC
domain master = yes
domain logons = yes
logon script = netlogon.bat
logon home = %L%U.profiles
logon path = %Lprofiles%U
security = user
encrypt passwords = yes
enable privileges = yes
passdb backend = tdbsam
preferred master = yes
local master = yes
os level = 100
wins support = yes
printing = cups
load printers = yes
enable privileges = yes 

[printers]
path = /var/spool/samba
print ok = yes
guest ok = yes
browseable = yes

[print$]
path = /var/smb/printers
read only = yes
write list = gdh
inherit permissions = yes

[netlogon]
comment = Servico de Logon
path = /var/samba/netlogon
read only = yes
browseable = no<

[profiles]
path = /var/profiles
writeable = yes
browseable = no
create mask = 0600
directory mask = 0700

[homes]
valid users = %S
create mask = 0700
directory mask = 0700
browseable = no

[arquivos]
path = /mnt/hda2
writable = no
write list = +arquivos

Com o servidor Samba configurado, falta o mais importante, que é configurar os clientes para fazerem logon no domínio. Ao usar um PDC, surge a necessidade de cadastrar as máquinas no domínio, para só então os usuários cadastrados poderem utilizar as máquinas. É possível cadastrar tanto máquinas Windows quanto máquinas Linux no domínio, vamos agora às peculiaridades de cada sistema.

• Logando Clientes Windows

Nem todas as versões do Windows suportam o uso de um domínio. Como controladores de domínio são usados principalmente em redes de médio ou grande porte, em empresas, a Microsoft não inclui suporte no Windows XP Home e no XP Starter, assim como no Vista Starter, Vista Home Basic e Vista Home Premium, de forma a pressionar as empresas a comprarem as versões mais caras do sistema. É possível burlar a limitação através da alteração de chaves do registro, mas isso viola o contrato de uso do sistema, o que de qualquer forma não é aceitável em um ambiente de produção. Tendo isso em mente, vamos aos passos relacionados à configuração, que muda de acordo com a versão do Windows: No Windows XP Professional, acesse o "Painel de Controle > Sistema > Nome do Computador" e use a opção "Alterar...". No menu seguinte, defina o nome da máquina (que precisa ser um dos logins de máquinas adicionados na configuração do Samba) e o nome do domínio, que é definido na opção "workgroup =" do smb.conf. Para ter acesso a esta opção, você deve estar logado como administrador:

Nunca é demais lembrar que o "Nome do computador" fornecido na opção deve corresponder a uma das contas de máquinas cadastradas no servidor Samba, usando os três comandos que citei anteriormente. Para cadastrar a máquina "hp", por exemplo, você usaria (no servidor, como root) os comandos abaixo:

# useradd -d /dev/null -s /bin/false hp$
# passwd -l hp$ # smbpasswd -a -m hp

Na tela de identificação que será aberta a seguir, logue-se como "root", com a senha definida no servidor Samba. É normal que a conexão inicial demore um ou dois minutos. Se tudo der certo, você é saudado com a mensagem "Bem-vindo ao domínio Dominio" (onde o "Dominio" é o nome definido na opção "workgroup" do smb.conf):

Fornecer a senha de root do servidor ao cadastrar o cliente no domínio, prova que quem está fazendo a operação é o administrador, ou alguém autorizado por ele. Se qualquer um pudesse adicionar e remover máquinas do domínio, ele não seria muito diferente de um grupo de trabalho e a configuração perderia todo o sentido. Se você não gostou da idéia de usar a senha de root para cadastrar as máquinas, é possível também outorgar o privilégio a uma outra conta através do comando "net", como veremos a seguir. Quando a máquina passa a fazer parte do domínio, é criada uma "relação de confiança" entre ela e o servidor. Uma senha (chamada de "machine trust account password") é usada pela máquina para comprovar sua identidade ao contatar o servidor de domínio. Esta é uma senha interna, gerada automaticamente pelo sistema durante a conexão inicial. Depois de reiniciar a estação, aparecerá a opção "Efetuar logon em: DOMINIO" na tela de login, permitindo que o usuário faça logon usando qualquer uma das contas cadastradas no servidor. Continua disponível também a opção de fazer um login local, mas, nesse caso, perde-se o acesso aos recursos relacionados ao domínio e é usado o perfil do usuário local:

Para remover a máquina do domínio, é preciso acessar a mesma opção e mudar a opção de "Membro de Domínio:" para "Membro de Grupo de trabalho:". O sistema solicita novamente a senha do servidor, como uma forma de comprovar que o usuário está autorizado a realizar a operação. Isso evita que os usuários da rede desfaçam a configuração, removendo as máquinas do domínio sem permissão do administrador. Para confirmar se os clientes estão realmente efetuando logon no servidor, use o comando "smbstatus" (no servidor). Ele retorna uma lista dos usuários e das máquina logadas, como em:

Samba version 3.0.14a-Debian
 PID Username Group  Machine
-----------------------------------------------------
4363 joao  joao  athenas (192.168.0.34)


Service pid machine Connected at
-----------------------------------------------------
joao  4363 athenas Sat Jul 9 10:37:09 2005

No Windows Vista, a opção de adicionar a máquina ao domínio está no "Painel de Controle > Sistema > Configurações avançadas do sistema (na lista à esquerda) > Nome do Computador > Alterar":

A forma como você escolhe se quer se logar ao domínio ou fazer um login na máquina local na tela de login do Vista segue uma lógica um pouco curiosa. Depois que a máquina é adicionada ao domínio, a tela de login mostra a opção de fazer logon no domínio, onde o último login utilizado fica pré-selecionado. Para usar outro login, é necessário clicar no botão "Trocar Usuário" e fornecê-lo na tela seguinte. Entretanto, não existe uma opção para fazer logon na máquina local. Para isso, é necessário especificar o nome da máquina seguido pelo nome do usuário no campo de login, como em: Vistagdh. Outra opção é usar um "." antes do nome do usuário, como em ".gdh". No Windows 2000, o procedimento é basicamente o mesmo do Windows XP, muda apenas a localização da opção, que está disponível no "Meu Computador > Propriedades > Identificação de rede > Propriedades". Ao contrário do XP Home, XP Starter, Vista Starter e Vista Home, as máquinas com o Windows 98 ou o Windows ME podem ser adicionadas ao domínio. Entretanto, elas participam dentro de um modo de compatibilidade, onde podem acessar os compartilhamentos, mas não têm acesso ao recurso de perfis móveis, por exemplo. Para cadastrar a máquina, comece logando-se na rede (na tela de login aberta na inicialização do sistema) com o mesmo usuário e senha que será usado para fazer logon no domínio. Acesse agora o "Painel de Controle > Redes > Cliente para redes Microsoft > Propriedades". Marque a opção "Efetuar Logon num domínio NT", informe o nome do domínio e marque a opção "Efetuar logon e restaurar conexões". Ao terminar, é preciso fornecer o CD do Windows (para a instalação dos componentes necessários) e reiniciar a máquina.

• Corrigindo problemas

Naturalmente, com tantos passos a seguir, nem sempre as coisas dão certo na primeira tentativa. Vamos então a uma rápida seção de troubleshoot, com mensagens de erro comuns ao tentar cadastrar a máquina no domínio:

Esta primeira mensagem aparece quando o nome da máquina não foi cadastrado no servidor Samba como uma conta de máquina. O "nome de usuário" se refere, na verdade, à conta da máquina, adicionada usando os três comandos que vimos a pouco. Outro erro comum é:

Esta segunda mensagem indica que a conta de root não foi cadastrada no Samba (smbpasswd -a root), que a senha informada no cliente está incorreta ou que o Samba não está sendo capaz de utilizar a conta de root devido à presença da linha "invalid users = root" no smb.conf. Em resumo, ela é exibida quando, por qualquer motivo, o servidor Samba não consegue autenticar a conta de root e recusa o login da máquina Windows no domínio. O Samba é inteiramente compatível com as estações rodando o Windows XP a partir da versão 3. As últimas versões da série 2.x também podiam ser configuradas como servidores de domínio, mas, ao usá-las, era necessário fazer um conjunto de alterações nos clientes, desativando recursos que não eram suportados pelo Samba. Naturalmente, é muito mais fácil simplesmente atualizar o servidor Samba do que fazer alterações em cada cliente, mas de qualquer forma, caso isso não seja possível, você pode ajustar os clientes de duas formas:

1. Copie o arquivo "/usr/share/doc/samba-doc/registry/WinXP_SignOrSeal.reg" (do servidor), que fica disponível como parte da instalação do pacote "samba-doc" para cada cliente e execute o arquivo, para que ele faça as alterações necessárias no registro.
2. Acesse o "Painel de controle > Ferramentas administrativas > Diretiva de segurança local > Diretivas locais > Opções de segurança" e desative as seguintes opções:

• Membro do domínio: criptografar ou assinar digitalmente os dados de canal seguro (sempre)
• Membro do domínio: desativar alterações de senha de conta da máquina
• Membro do domínio: requer uma chave de sessão de alta segurança (Windows 2000 ou posterior).

• Cadastrando as máquinas sem usar a conta de root

Normalmente, você deve fornecer a senha de root ao inserir cada máquina no domínio. Fornecer a senha de root é justamente uma prova de que você é realmente o administrador do servidor e está autorizado a cadastrar as máquinas. Esta é a forma mais simples de trabalhar, mas muitos torcem o nariz para a idéia, temendo abrir uma brecha para ataques. É possível evitar a necessidade de usar a conta de root ao cadastrar as máquinas criando uma conta especial, com privilégios para adicionar máquinas ao domínio, de forma similar ao que fizemos ao configurar o fornecimento automático de drivers de impressão. Para isso, usamos novamente o comando "net", adicionando agora o privilégio "SeMachineAccountPrivilege" ao usuário que terá permissão para adicionar as máquinas no domínio. Se o servidor se chama "athenas" e o usuário se chama "gdh", o comando seria:

# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeMachineAccountPrivilege(todo o comando forma uma única linha)

Este comando deve ser executado em um prompt do próprio servidor, e não localmente, nos clientes. Se você não tem acesso físico ao servidor, pode se logar nele via SSH. Ao executar o comando, o sistema solicita a senha de root (do servidor) e exibe uma mensagem de confirmação. Com isso, a conta de usuário especificada no comando (gdh no exemplo) ganha permissão para adicionar máquinas no domínio e pode ser usada para cadastrar os clientes, no lugar da conta root. Lembre-se de que, para adicionar os privilégios, você deve comentar ou remover a linha "invalid users = root" e adicionar a linha "enable privileges = yes" na seção [global] do smb.conf, como vimos no tópico sobre impressão.

• Ajustando as permissões locais

Ao adicionar uma máquina Windows ao domínio, é criada uma distinção entre as contas locais e as contas de domínio. Quando o usuário se loga na estação Windows usando uma das contas cadastradas no servidor, ele é na verdade logado (na estação local) usando uma conta limitada, onde ele não tem permissão para compartilhar arquivos, para alterar as configurações da rede, nem para alterar a maior parte das configurações do sistema. Em muitas situações, é exatamente isso que você quer, mas em outras isso pode ser um grande problema, já que o usuário não conseguirá compartilhar pastas com outros usuários da rede, por exemplo. Veja que a aba de compartilhamento sequer fica disponível nas propriedades da pasta:

Para mudar isso, é necessário ajustar as permissões da máquina local, de forma que a conta do domínio tenha permissão para alterar as configurações. Para isso, logue-se localmente na estação Windows, usando uma conta com privilégios administrativos e acesse o "Painel de controle > Contas de usuário". Clique no "Adicionar" e especifique o login do usuário e o nome do domínio e, na tela seguinte, especifique o nível de permissão na máquina local (Administrador, Usuário avançado, etc.). Você pode adicionar outros usuários se desejar:

Faça logoff e logue-se novamente no domínio com a conta que foi cadastrada. Se você a cadastrou com privilégios administrativos, você notará que a aba de compartilhamento voltou a aparecer e o acesso às demais configurações foi destravado. Com isso o usuário assume o controle de sua máquina local e pode criar compartilhamentos e alterar as demais configurações:

Inicialmente, os compartilhamentos aparecerão no ambiente de rede, mas usuários de outras máquinas (também cadastradas no domínio) não conseguirão acessá-los, recebendo uma mensagem de permissão negada. Para solucionar este último problema, acesse as permissões da pasta (ainda na máquina local) e adicione os usuários do domínio que terão permissão para acessá-la, definindo as permissões de acesso de cada um:

Note que essa configuração é necessária apenas se você quiser que os usuários das estações possam criar compartilhamentos locais. Outra opção é simplesmente adicionar compartilhamentos no servidor e orientar os usuários a usarem os compartilhamentos criados para compartilharem os arquivos desejados. Centralizar todos os compartilhamentos no servidor Samba é mais seguro e facilita bastante os backups, já que você precisará se preocupar apenas em fazer backup dos arquivos do servidor. Continuando, é possível também criar usuários administrativos, com permissão para alterar o dono e as permissões dos arquivos colocados nos compartilhamentos do próprio servidor. Isso é feito usando o comando "net", o mesmo que utilizamos para permitir que o usuário possa dar upload dos drivers de impressão e possa adicionar máquinas ao domínio. Os três privilégios relacionados são:

• SeDiskOperatorPrivilege: Permite que o usuário altere as permissões de acesso dos compartilhamentos e arquivos dentro deles.
• SeRestorePrivilege: Permite que o usuário altere o dono dos arquivos e pastas, transferindo a posse para outro usuário (exceto ele mesmo)
• SeTakeOwnershipPrivilege: Permite que o usuário assuma para si a posse de arquivos e pastas, complementando o SeRestorePrivilege.

Se o servidor se chama "athenas" e o usuário que receberá os privilégios se chama "gdh", os comandos para fornecer os três privilégios (a serem executados em um terminal do servidor) seriam:

# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeDiskOperatorPrivilege
# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeRestorePrivilege
# net -S localhost -U root -W ATHENAS rpc rights grant 'ATHENASgdh' SeTakeOwnershipPrivilege

Não é preciso dizer que, em uma grande rede, estes privilégios devem ser atribuídos apenas a outros administradores ou a usuários de sua inteira confiança, já que eles permitem acesso quase que irrestrito aos arquivos no servidor. Para listar os privilégios atribuídos a cada usuário, use o comando:

# net -S localhost -U% rpc rights list accounts

Isso lista todos os usuários com privilégios especiais, incluindo as contas do sistema. Depois de executar os três comandos que vimos a pouco, teríamos o usuário "gdh" aparecendo no final da lista, com os três privilégios:

ATHENASgdh
SeDiskOperatorPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege

Para remover um determinado privilégio, é usado o mesmo comando que usamos para adicionar, apenas substituindo o "grant" por "revoke", como em:

# net -S localhost -U root -W ATHENAS rpc rights revoke
'ATHENASgdh' SeTakeOwnershipPrivilege

• Logando clientes Linux no domínio

Embora a configuração seja um pouco mais complexa, é possível também logar clientes Linux no domínio, já que o Samba pode ser usado como cliente de um PDC Samba (ou de um PDC Windows). Isso permite que a estação Linux acesse os recursos do domínio normalmente e utilize o PDC como um servidor de autenticação na hora de compartilhar arquivos com a rede, da mesma forma que as máquinas Windows. Com isso, você elimina a necessidade de cadastrar os logins de usuários em todas as máquinas Linux que precisarem compartilhar arquivos, já que todo o processo de autenticação é centralizado no servidor. O primeiro passo é cadastrar o nome da máquina no servidor PDC, usando os três comandos que já vimos:

# useradd -d /dev/null -s /bin/false nome$
# passwd -l nome$
# smbpasswd -a -m nome

No caso dos clientes Linux, vale o nome definido durante a instalação do sistema, que fica armazenado dentro do arquivo "/etc/hostname". Esta é a única configuração que precisa ser feita no servidor. Os passos seguintes são feitos no próprio cliente. Comece fazendo uma instalação normal do Samba, instalando os pacotes "samba" e "samba-client" (ou smbclient) através do gerenciador de pacotes, da mesma forma que faria ao instalar um servidor Samba para a rede. É necessário cadastrar pelo menos uma conta de usuário no Samba (da estação), com a mesma senha definida no sistema, usando o comando smbpasswd, como em:

# smbpasswd -a joao

Com o Samba instalado, edite o arquivo smb.conf, deixando-o como este modelo:

[global]
netbios name = M5
workgroup = Dominio
security = domain
encrypt passwords = yes
password server = 192.168.1.254
username map = /etc/samba/smbusermap

[arquivos]
path = /home/arquivos
writable = yes

A seção global deve conter as linhas "security = domain" (como citei anteriormente, este é o nível de segurança que permite que o Samba atue como cliente de um PDC), "encrypt passwords = yes" e a linha "password server =" que indica o endereço IP (ou o nome netbios) do servidor PDC. É importante também que a linha "workgroup" inclua o nome correto do domínio e a linha "netbios name" contenha o nome da máquina (cliente), como cadastrado no servidor e salvo no arquivo "/etc/hostname". Você pode incluir também os compartilhamentos de arquivos e impressoras desejados, como no caso do compartilhamento [arquivos] que incluí no exemplo. Depois de salvar o arquivo e reiniciar o serviço, é hora de adicionar a máquina ao domínio, o que é feito usando o comando abaixo (executado na estação):

# net join -U root

Password:
Joined domain DOMINIO.

A senha de root solicitada é a senha de root cadastrada no servidor, que é checada ao cadastrar a estação como uma forma de provar que você é o administrador da rede. Você pode também criar um usuário administrativo com poderes para adicionar as máquinas ao domínio (evitando assim o uso da conta de root), dando a ela o privilégio "SeMachineAccountPrivilege", como vimos no tópico anterior. Se o comando exibir a mensagem "Joined domain DOMINIO." sem solicitar a senha, rode-o novamente, pois isso acontece quando (por qualquer motivo) ele não conseguiu contactar o servidor. Se ele reclamar que a senha está incorreta, ou exibir um erro de permissão, verifique a configuração do servidor. Isso acontece, por exemplo, quando a linha "invalid users = root" está presente na configuração. Uma vez inserida no domínio, a instância do Samba rodando na estação passará a encaminhar todos os pedidos de autenticação para o servidor. Se o servidor autoriza o acesso, então o servidor Samba local permite o acesso ao compartilhamento. Com isso, um novo usuário cadastrado no servidor PDC, ganha acesso também aos compartilhamentos do estação, sem que você precise cadastrá-lo duas vezes. Para que isso funcione, é necessário duas coisas. Em primeiro lugar, é necessário especificar o endereço IP ou nome do servidor, para que a estação consiga contactá-lo, o que e feito através da opção "password server", como já vimos. O segundo passo é criar um arquivo com um mapa dos usuários na estação. O arquivo pode ser armazenado em qualquer pasta, mas você precisa especificar sua localização corretamente na opção "username map" do smb.conf, como em:

username map = /etc/samba/smbusermap

Este arquivo relaciona os logins cadastrados no servidor PDC com a conta cadastrada no servidor Samba local, explicando a ele como acessar os arquivos no sistema depois que o acesso é autorizado pelo PDC. Sem isso, o sistema bloqueia o acesso, já que as contas cadastradas no PDC não existem localmente. O arquivo com o username map segue uma estrutura muito simples, onde você especifica uma conta por linha, sempre seguindo a sintaxe "conta_local = nome_do_dominioconta_no_dominio", como em:

joao = DOMINIOgdh
joao = DOMINIOmaria
joao = DOMINIOjose
joao = DOMINIOisac

Basta criar um arquivo de texto usando qualquer editor e salvá-lo, prestando atenção no uso de barras invertidas. Quando qualquer usuário especificado no arquivo é autorizado pelo PDC, o servidor Samba local realiza a leitura no sistema de arquivos utilizando a conta "joao", que é a única cadastrada localmente. Com isso, você precisa apenas manter o arquivo atualizado, sem se preocupar com com senhas. Ao administrar uma rede com várias estações, é interessante manter o SSH ativo em todas as máquinas, de forma que você possa atualizar o arquivo remotamente, quando necessário. Ao serem acessados através do ambiente de rede, os compartilhamentos das estações de trabalho Linux ficam disponíveis para as demais máquinas do domínio sem necessidade de autenticação adicional, já que a autenticação é centralizada no PDC. Aqui temos um exemplo de máquina Linux, configurada como cliente do PDC, que está compartilhando uma pasta com a rede:

Concluindo, caso você deseje mais tarde remover a máquina Linux do domínio, basta alterar novamente o smb.conf (na estação), mudando a linha "workgroup = ", para que ela passe a indicar o nome do grupo de trabalho (e não mais do domínio) e alterar a linha "security = domain" para "security = user", como em:

[global]
workgroup = grupo
netbios name = M5
security = user
encrypt passwords = yes

Depois de reiniciar o Samba (ou aguardar o tempo de atualização após a mudança no arquivo), a estação deixa o domínio e volta a fazer parte do grupo de trabalho. A principal limitação dessa configuração é que ela permite centralizar apenas a autenticação dos compartilhamentos de rede, mas não resolve o problema da autenticação local nas estações Linux, que continua sendo feita da forma tradicional. Isso nos leva ao tópico seguinte...

• Usando o PDC para autenticação local no Linux

É possível configurar os clientes Linux para fazerem a autenticação dos usuários locais no PDC e armazenarem as configurações no próprio servidor (assim como no caso das máquinas Windows), mas, nesse caso, a configuração é bem mais complicada, pois temos que fazer várias alterações que alteram a forma como sistema autentica os usuários. Ao invés de verificar os arquivos "/etc/passwd" e "/etc/shadow", onde ficam armazenadas as contas locais, o cliente passa a utilizar o Samba e o Winbind para buscar os logins no servidor e assim autenticar o usuário. Se você procura uma solução simples e limpa, recomendo que se limite à configuração que mostrei até aqui. Se não se importa de sujar as mãos, continue por sua conta e risco. :) Esta configuração é indicada para distribuições derivadas do Debian que utilizam o KDM. Ela funciona em outras distribuições, mas, eventualmente, podem ser necessárias pequenas mudanças, de acordo com as peculiaridades de cada uma. O primeiro passo é instalar os pacotes "samba" (ou samba-server), "winbind" (ou samba-winbind) e "libpam-modules" em cada cliente. Nas distribuições derivadas do Debian, instale diretamente os três pacotes:

# apt-get install samba winbind libpam-modules

No Fedora, o winbind está incluído no pacote principal do Samba e os módulos do PAM são instalados através do pacote "pam_smb":

# yum install samba pam_smb

A configuração no servidor não muda em relação ao que já vimos. Toda a configuração que vemos aqui é feita nos clientes. Abra agora o arquivo "/etc/samba/smb.conf" (no cliente Linux) e faça com que a seção Global fique como o exemplo. Você pode tanto adicionar compartilhamentos, quanto ficar apenas com esta configuração básica:

[global]
netbios name = cliente1
workgroup = Dominio
winbind use
default domain = yes
obey pam restrictions = yes
security = domain
encrypt passwords = true
wins server = 192.168.1.254
winbind uid = 10000-20000
winbind gid = 10000-20000
template shell = /bin/bash
template homedir = /home/%U
winbind separator = +
invalid users = root

Não se esqueça de substituir o "Dominio" pelo nome do domínio usado na rede, o "cliente1" pelo nome do cliente e o "192.168.1.254" pelo endereço IP do servidor Samba PDC. Abra agora o arquivo "/etc/nsswitch.conf" e substitua as linhas:

passwd: compat
group: compat
shadow: compat

No início do arquivo, por: passwd: compat winbind group: compat winbind shadow: compat winbind Um exemplo do arquivo completo é:

passwd: compat
winbind group: compat
winbind shadow: compat
winbind hosts: files dns mdns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

Depois de modificar os dois arquivos, reinicie o Samba e o Winbind e teste a configuração, ingressando no domínio. Para isso, use o comando "net rpc join":

# net rpc join member -U root

Password:
Joined domain DOMINIO.

A senha solicitada é a senha de root do servidor PDC, cadastrada no Samba, assim como fazemos ao cadastrar as máquinas Windows. Em caso de problemas, você pode usar também o comando abaixo, que especifica o nome do servidor (-S) e o nome do domínio (-w):

# net rpc join -S gdh -w dominio -U root

Se você receber uma mensagem de erro, como:

Creation of workstation account failed
Unable to join domain DOMINIO.

Provavelmente você esqueceu de cadastrar a máquina cliente no servidor. O nome da máquina (que você verifica através do comando "hostname") deve ser o mesmo que o incluído no arquivo smb.conf. Para criar a conta de máquina para o cliente, use (no servidor) os comandos que vimos anteriormente:

# useradd -d /dev/null -s /bin/false cliente1$
# passwd -l cliente1$
# smbpasswd -a -m cliente1

Nesse ponto o cliente já estará logado no domínio. Esta configuração é permanente, de forma que você não precisa se preocupar em refazer a configuração a cada boot. Falta agora a parte mais problemática, que é configurar o PAM, o sistema de autenticação do sistema, para buscar os logins no servidor. Isso é feito modificando os arquivos "/etc/pam.d/login" e "/etc/pam.d/kdm". Comece adicionando as linhas abaixo noinício do arquivo "/etc/pam.d/login" (responsável pela autenticação dos usuários no sistema), sem apagar as demais:

session required pam_mkhomedir.so skel=/etc/skel umask=0022
session optional pam_mount.so
auth sufficient pam_winbind.so
account sufficient pam_winbind.so
session required pam_winbind.so

Abra agora o arquivo "/etc/pam.d/kdm", deixando o arquivo com o seguinte conteúdo (apague ou comente as demais linhas). A mesma configuração pode ser usada no arquivo "/etc/pam.d/gdm", usado por distribuições que trazem o Gnome por padrão:

auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_winbind.so
auth required /lib/security/pam_pwdb.so use_first_pass shadow nullok
account required /lib/security/pam_winbind.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022

Esta configuração faz com que o KDM exiba a lista de usuários cadastrados no servidor e permita que você faça login diretamente no domínio, sem passar pela autenticação local. É importante também desativar o autologin do KDE (ainda no cliente), no "Centro de Controle do KDE > Administração do Sistema > Gerenciador de login".

Se você apenas adicionar as linhas acima no "/etc/pam.d/kdm", mas não apagar as linhas que já existem no arquivo (que permitem a autenticação local), a tela do KDM vai exibir a lista de logins do servidor, mas vai recusar o login, dizendo que a senha está incorreta. Este é um dos erros de configuração mais comuns. Se você deixar disponível a opção "Bloquear sessão" do KDE, vai precisar editar também o arquivo "/etc/pam.d/kscreensaver", para que ele também use as contas do servidor. Caso contrário, o usuário vai acabar tendo que reiniciar o X, cada vez que clicar por engano no ícone:

Adicione as duas linhas abaixo no início do arquivo (/etc/pam.d/kscreensaver), sem apagar as demais:

auth sufficient pam_winbind.so
auth required pam_unix.so shadow nullok

Para que esta configuração funcione, é importante que os usuários sejam cadastrados no servidor como usuários reais, usando o comando "adduser", e não o "adduser --disabled-login --no-create-home" ou similar. Basicamente, é preciso que o usuário possa se logar no servidor, caso contrário ele também não vai conseguir se logar nas estações. Ainda no cliente, acesse a pasta "/etc/rc5.d" e verifique se os links responsáveis por inicializar os serviços samba, winbind e kdm foram criados corretamente. Eles precisam ser carregados nessa ordem. No caso de distribuições que inicializam o KDM primeiro, renomeie o link, de forma que ele seja inicializado por último, como em:

# mv /etc/rc5.d/S02kdm /etc/rc5.d/S99kdm

Reinicie o cliente para que os módulos do PAM sejam atualizados e os serviços inicializados na ordem correta. Você notará que a tela de login do KDM passará a exibir os usuários cadastrados no servidor, ao invés dos usuários locais, sintoma de que está tudo funcionando:

Configurando desta forma, os usuários locais que forem eventualmente criados no terminal chegam a aparecer na lista, mas não é possível fazer login neles através do KDM (essa é justamente a idéia). Apesar disso, você pode se logar nos terminais remotamente (usando o root e outros logins locais) via SSH, quando precisar alterar as configurações. No arquivo "/etc/pam.d/login", incluímos a linha "session required pam_mkhomedir.so skel=/etc/skel umask=0022". Ela faz com que a pasta "/etc/skel" (da estação) seja usada como um template para a criação dos diretórios home dos usuários que só existem no servidor PDC. A pasta "/home" (na estação) armazena apenas os arquivos que forem alterados em relação à pasta "/etc/skel", simplificando os backups. Você pode configurar o servidor Samba instalado em cada estação para compartilhar o diretório home, com permissões de acesso apenas para o administrador da rede, de forma que você possa acessar o home de cada estação a partir do servidor e fazer backup periodicamente. O "/etc/skel" é justamente uma pasta modelo, cujo conteúdo é copiado para o diretório home, sempre que um novo usuário é criado. As configurações padrão mudam muito de distribuição para distribuição. Esta configuração privilegia o uso das configurações padrão de cada distribuição, permitindo que você use diversas distribuições diferentes nos clientes, independentemente de qual esteja usando no servidor. O Fedora continua com cara de Fedora, o Debian com cara de Debian e assim por diante.

Fonte: www.mktecnologia.net.br