De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Logando Clientes Linux num PDC Samba

Colaboração: Carlos E. Morimoto

Data de Publicação: 12 de Maio de 2006

Além de autenticar as máquinas Windows, o servidor Samba PDC pode ser usado para logar também os clientes Linux, centralizando a autenticação de toda a rede.

Fazer uma máquina Linux se logar no PDC é mais complicado do que uma máquina Windows, 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 (que permite que uma máquina Linux ingresse num domínio) para buscar os logins no servidor.

Esta configuração é indicada para distribuições derivadas do Debian que utilizam o KDM, com destaque para o Kurumin, ideal para situações onde você usa o Kurumin nos desktops da empresa e quer usar a lista de logins de um servidor Samba, ao invés de logins locais. 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" 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]
  	workgroup = Dominio
  	netbios name = cliente1
  	winbind use default domain = yes
  	obey pam restrictions = yes
  	security = domain
  	encrypt passwords = true
  	wins server = 192.168.1.1
  	winbind uid = 10000-20000
  	winbind gid = 10000-20000
  	template shell = /bin/bash
  	template homedir = /home/%U
  	winbind separator = +
  	printing = cups
  	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.1" 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 novo 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

Neste ponto o cliente já está 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 no iní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). Esta 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, 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 também não vai conseguir se logar nas estações.

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 nesta ordem. No caso de distribuições que inicializam o KDM primeiro (como no caso do Kurumin), 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. 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 Slackware de Slackware, e assim por diante.

Gostou da dica? Venha fazer um curso com o autor:

Curso: Redes e servidores Linux

Com Carlos E. Morimoto

Em São Paulo, de 29/05 a 03/06 (intensivo, com aulas à tarde)

Este é um curso sobre a configuração de servidores Linux. Nele você aprende a configurar cada serviço diretamente nos arquivos de configuração ou utilizando ferramentas genéricas, sem se prender a uma única distribuição. Os exemplos dados durante o curso usam como base o Debian e Fedora, com dicas de peculiaridades do Mandriva, Slackware, Kurumin e Ubuntu.

Este é um curso intensivo, onde você passa menos tempo vendo teoria e opções pouco usadas e mais tempo aprendendo a resolver problemas do dia a dia. O formato das aulas permite que sejam abordados uma grande quantidade de temas numa única semana, oferecendo uma visão global dos recursos disponíveis e onde eles podem ser aplicados. Ao invés de fazer um curso sobre o Squid, outro sobre o Samba, outro sobre o Apache, etc., você aprende muitas coisas de uma única vez, economizando tempo e dinheiro.

Nesta turma do dia 29/05, combinou do curso de redes e o curso para iniciantes serem ministrados na mesma semana: o curso para iniciantes de segunda a sexta, das 8:00 às 11:00, e o curso de redes das 12:30 às 18:00. Fazendo o curso de redes, você tem acesso também às aulas para iniciantes e pode fazer os dois cursos simultaneamente (pagando apenas um), e assim aproveitar para tirar todas as dúvidas.

Veja mais detalhes sobre a programação de cursos, temas abordados, preços e formas de pagamento no:

http://guiadohardware.net/cursos/

Todas as aulas do curso de redes são ministradas pelo próprio Carlos Morimoto, o que garante o nível do curso. Nada de aulas inaugurais e mutretas do gênero :)