Thin clients: montar shares Windows com Kerberos

Configurações do servidor DHCP

Estas são as configurações necessárias para que um thin client faça boot a partir do thinserver.

default-lease-time            21600;
max-lease-time                21600;

option subnet-mask            255.255.255.0;
option broadcast-address      10.255.255.255;
option routers                10.0.0.1;
option domain-name-servers    10.0.0.10
option domain-name            "domain.internal";
option root-path              "/opt/ltsp/i386";

host thinclient1 {
        next-server             10.0.0.10;
        hardware ethernet       00:AA:BB:CC:DD:EE;
        fixed-address           10.0.0.100;
        filename                "ltsp/i386/pxelinux.0";
        option root-path        "10.0.0.10:/opt/ltsp/i386";
}

host thinclient2 {
        next-server             10.0.0.10;
        hardware ethernet       00:BB:CC:DD:EE:FF;
        fixed-address           10.0.0.101;
        filename                "ltsp/i386/pxelinux.0";
        option root-path        "10.0.0.10:/opt/ltsp/i386";
}

Nota: mantenha os endereços IP e MAC conforme sua topologia. Esses valores são exemplos; não os use sem adaptação.

Configuração do Thin Client

Para facilitar para os usuários dos thin clients, instalei o tema XPGnome e ajustei os menus Start. Também instalei Adobe Reader 9 e Skype.

Tive um problema com o ícone “Sair” não aparecendo. Corrigi encontrando um ícone 48×48 no Google e depois usei o GIMP para escalá-lo para 32×32, 24×24, 22×22 e 16×16. Renomeie o ícone para system-log-out.png e salve em /usr/share/icons/GnomeXP/{tamanhodoícone}/actions.

O resultado final ficou assim:

Área de trabalho do thin client com tema XPGnome mostrando ícones e painel

Para tornar essas configurações padrão para todos os usuários que fazem login no thinserver, copie as pastas .config, .gconf, .icons, .local e .themes da pasta home do usuário que instalou o tema XPGnome para /etc/skel. A partir daí, qualquer alteração que você queira aplicar globalmente precisará ser copiada novamente para /etc/skel.

Importante: ajuste permissões e propriedade dos arquivos em /etc/skel para que novos usuários recebam configurações sem problemas de permissão.

Montagem de shares Windows no login

Existem várias maneiras de montar shares Windows no Linux; aqui usei scripts Bash e Perl em conjunto com o mecanismo “Startup Applications” do Ubuntu para montar as shares no login do usuário. Vou incluir todos os scripts usados para que você possa adaptar ao seu ambiente.

Pré-requisito: garanta que o share NETLOGON do dc.domain.internal esteja montado em thinserver.domain.internal. No meu ambiente criei uma conta de domínio genérica com permissão apenas de listagem do AD. Para este exemplo, a conta é “public” com senha “password” — altere para credenciais seguras no seu ambiente.

Crie o diretório onde o share será montado:

sudo mkdir /mnt/logon

Adicione a entrada abaixo em /etc/fstab para montar o NETLOGON automaticamente:

//dc.domain.internal/netlogon      /mnt/logon           cifs   username=public,password=password 0  0

Depois execute:

sudo mount -a

Os scripts assumem que cada usuário terá um arquivo batch de logon no NETLOGON e uma share no servidor server.domain.internal. Exemplo de batch para o usuário “John Doe” (username jdoe), arquivo jdoe.bat:

@echo off
NET USE S: \\\server\\common
NET USE T: \\\server\\IT

Script win_share.sh

Crie o script win_share.sh em /usr/local/bin/ e torne-o executável. Ele verifica se já existem .mount.sh e .umount.sh no diretório home do usuário e os recria executando o mount.pl. Finalmente executa .mount.sh para montar as shares sem solicitar senha (usa Kerberos).

#!/bin/sh
# Check to see if .mount.sh and .umount.sh exist, if so delete them!

if [ -f /home/$USER/.mount.sh ]; then
   rm /home/$USER/.mount.sh
fi

if [ -f /home/$USER/.umount.sh ]; then
   rm /home/$USER/.umount.sh
fi

# Create the .mount.sh and .umount.sh scripts from users batch file

/usr/local/bin/mount.pl $USER

# Mount network shares when logging on.
/home/$USER/.mount.sh

Torne o script executável:

sudo chmod +x /usr/local/bin/win_share.sh

Script mount.pl (Perl)

Crie /usr/local/bin/mount.pl com o conteúdo abaixo. Ele gera dinamicamente /home/$USER/.mount.sh e /home/$USER/.umount.sh com base no arquivo .bat do usuário.

#!/usr/bin/perl
# Build dynamic ~user/.mount.sh based on logon.bat

$user = $ARGV[0];
$file = "/mnt/logonbat/$user.bat";  # <-- Change this from $user to the name of the batch script if you only use one.

die if ! $user;
die if ! -e $file;

open (PAM_CONF, ">/home/$user/.mount.sh");
open (LOGOFF, ">/home/$user/.umount.sh");

print PAM_CONF qq{#!/bin/sh
if [ ! -d /home/$user/Home ]; then
mkdir /home/$user/Home
fi
mount.cifs //server/$user /home/$user/Home -o username=$user,sec=krb5
};

print LOGOFF qq{#!/bin/sh
if [ "`cat /proc/mounts | grep /home/$user/Home | wc -l`" -ge "1" ]; then 
umount.cifs /home/$user/Home 
fi \n};

my(@arr)=`cat /mnt/logonbat/$user.bat`;
$mounts = parse_batfile(\@arr);
foreach $mount (@$mounts) {
  chomp($mount);
  ($server,$share) = $mount =~ /\\\\(.*)\\(.*)/;
  $share =~ tr/\cM//d;
  $mnt = $share;

  # skip AUDIT.  It's for PCs only
  next if $mnt =~ /AUDIT/;

  # skip personal shares.  
  next if lc("$mnt") eq lc("$user");
  next if ! $mnt;

  #strip dollar sign from mount point
  $mnt =~ s/\$$//;

  # make sure mount point is unique
  $mnt .= "-$server"  if $seen{$mnt}++;

  # upshift first letter of mnt point
  $mnt =~ s/^(.) (.*)/\u$1$2/g;

#  print PAM_CONF "volume $user cifs $server $share  /home/$user/$mnt  - - -\n";
  print PAM_CONF qq{if [ ! -d /home/$user/$mnt ]; then
mkdir /home/$user/$mnt
fi
mount.cifs //$server/$mnt /home/$user/$mnt -o username=$user,sec=krb5 \n};

  print LOGOFF qq{if [ "`cat /proc/mounts | grep /home/$user/$mnt | wc -l`" -ge "1" ]; then 
umount.cifs /home/$user/$mnt 
fi \n};
}

close PAM_CONF;
close LOGOFF;
system ("chown $user:16777729 /home/$user/.mount.sh");   #  16777729 is my GID for "Domain Users"
system ("chown $user:16777729 /home/$user/.umount.sh");  #  16777729 is my GID for "Domain Users"
system ("chmod +x /home/$user/.mount.sh");
system ("chmod +x /home/$user/.umount.sh");

# All done

sub parse_batfile {
  my($file) = @_;
  my(@mounts);
  foreach $line (@$file) {
    (@val) = split / /,$line;
    if (uc($val[0]) eq "NET" && uc($val[1]) eq "USE") {
       push (@mounts,$val[3]);
    }
    if ($val[0] eq "CALL") {
      my($match) = $val[1]  =~ /\\\\.*\\NETLOGON\\(.*)/ ;
      if ($match) {
        chop($match);
        my(@arr)=`cat /mnt/logonbat/$match`;
        $mounts = parse_batfile(\@arr);
        unshift @mounts, @ $mounts;
      }
    }
  }
  return \@mounts;
}

Torne-o executável:

sudo chmod +x /usr/local/bin/mount.pl

Exemplo de .mount.sh gerado

Este é um exemplo do que o script .mount.sh gerado para jdoe pode parecer:

#!/bin/sh
if [ ! -d /home/jdoe/Home ]; then
mkdir /home/jdoe/Home
fi
mount.cifs //server/jdoe /home/jdoe/Home -o username=jdoe,sec=krb5
if [ ! -d /home/jdoe/common ]; then
mkdir /home/jdoe/common
fi
mount.cifs //server/common /home/jdoe/common -o username=jdoe,sec=krb5 
if [ ! -d /home/jdoe/IT ]; then
mkdir /home/jdoe/IT
fi
mount.cifs //server/IT /home/jdoe/IT -o username=jdoe,sec=krb5

Criando a aplicação de inicialização (Startup Application)

Depois que win_share.sh e mount.pl estiverem no lugar, crie uma entrada em “Startup Applications” para executar o win_share.sh no login do usuário. No Ubuntu: abra Preferences > Startup Applications e adicione o comando /usr/local/bin/win_share.sh.

Janela de Preferências do Startup Applications mostrando lista de aplicações de inicialização

Removendo shares no logoff

Para desmontar os shares no logoff, utilizei pam_script.so, um módulo PAM que permite executar scripts em sessão de login e logoff. Não usei pam_script para o login porque ele executa como root e os scripts win_share.sh/mount.pl dependem da variável $USER.

Instale o pacote libpam-script (ajuste o nome da versão se necessário):

sudo dpkg -i libpam-script_1.1.4-1_i386.deb

Exemplo do .umount.sh gerado para jdoe:

#!/bin/sh
if [ "`cat /proc/mounts | grep /home/jdoe/Home | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/Home 
fi 
if [ "`cat /proc/mounts | grep /home/jdoe/common | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/common 
fi 
if [ "`cat /proc/mounts | grep /home/jdoe/IT | wc -l`" -ge "1" ]; then 
umount.cifs /home/jdoe/IT 
fi

Crie /usr/share/libpam-script/pam_script_ses_close com o conteúdo:

#!/bin/sh
# pam_script_ses_close script to remove windows shares

/home/$PAM_USER/.umount.sh 2>&1 >> /var/log/umount.log

Adicione a linha abaixo em /etc/pam.d/common-session:

session     optional              pam_script.so

Teste fazendo login e logoff e verificando /var/log/umount.log e os pontos de montagem em /proc/mounts.

SSH sem senha com Kerberos

Com Kerberos bem configurado no domínio, você pode permitir login SSH sem senha. No servidor thinserver, ajuste /etc/ssh/sshd_config:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UseDNS yes

No workstation Linux do usuário, ajuste /etc/ssh/ssh_config:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Teste com:

ssh -v thinserver

Se a autenticação via Kerberos funcionar, você não será solicitado a digitar senha e verá mensagens de debug como:

debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).

Problemas e soluções frequentes

Abaixo algumas ocorrências que encontrei e as soluções aplicadas.

PROBLEMA: LTSP client autentica mas desloga imediatamente SOLUÇÃO: gconftool-2 –direct –config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory –type string –set /desktop/gnome/session/required_components/windowmanager metacity
PROBLEMA: Sem VNC nos thin clients SOLUÇÃO: http://bootpolish.net/home_ltsp_installx11vnconltsp5
PROBLEMA: Trocar a tela de login padrão por uma customizada SOLUÇÃO: https://help.ubuntu.com/community/EdubuntuFAQ
PROBLEMA: Como configurar senha root no thin client SOLUÇÃO: https://help.ubuntu.com/community/EdubuntuFAQ
PROBLEMA: Ícone de logout não aparece SOLUÇÃO: http://ubuntuforums.org/archive/index.php/t-815188.html

Checklist por função

Admin de Infraestrutura:

Verificar entradas de DHCP e PXE
Garantir que LTSP esteja atualizado e imagens corretas
Configurar Kerberos e testar kinit para contas de serviço
Habilitar GSSAPI em SSH e testar

Suporte de Desktop:

Instalar tema XPGnome e ajustar ícones
Validar execução dos scripts de montagem no login
Testar montagem/desmontagem em contas reais de usuário

Equipe de Segurança:

Revisar uso de credenciais hardcoded no /etc/fstab
Recomendar uso de credenciais seguras ou keytab para NETLOGON
Validar permissões de /home e /etc/skel

Usuário final:

Confirmar que drives mapeados aparecem em /home/username
Reportar problemas de permissão ou ícones ausentes

Playbook de implantação passo a passo

Planejamento
- Inventariar thin clients e MACs
- Definir endereços IP e servidor next-server
Preparação do servidor
- Instalar LTSP, configurar /opt/ltsp/i386
- Configurar DHCP com entradas PXE (veja bloco DHCP acima)
Montagem do NETLOGON
- Criar /mnt/logon e atualizar /etc/fstab
- mount -a e verificar conteúdo
Scripts de montagem
- Colocar mount.pl e win_share.sh em /usr/local/bin/ e tornar executáveis
- Testar manualmente para um usuário de teste
Startup Applications
- Criar entrada para /usr/local/bin/win_share.sh
Remoção no logoff
- Instalar libpam-script e configurar pam_script_ses_close
Testes
- Login de múltiplos usuários, verificar montagem, SSH Kerberos
Produção
- Copiar configurações para /etc/skel e comunicar equipe de suporte

Critérios de aceitação

Usuário realiza login sem prompts de senha para montar shares (Kerberos configurado)
Pontos de montagem aparecem automaticamente em /home/username
Compartilhamentos são desmontados corretamente no logoff e não ficam presos
SSH com GSSAPI permite conexão sem senha entre workstation e thinserver
Novos usuários recebem tema e configurações copiadas de /etc/skel

Testes/aceitação (casos de teste rápidos)

Teste 1: Login do usuário jdoe; verificar /home/jdoe/Home, /home/jdoe/common; montar com mount.cifs
Teste 2: Logoff de jdoe; verificar que os pontos de montagem foram desmontados e /var/log/umount.log contém execuções
Teste 3: SSH a partir de estação configurada; verificar debug1: Authentication succeeded (gssapi-with-mic)

Alternativas e quando não usar este método

Se não houver Kerberos no ambiente: considerar usar credenciais armazenadas em credential files ou usar autofs com credenciais seguras.
Ambientes que exigem alta segregação: evitar uso de contas genéricas em /etc/fstab; prefira keytabs ou autenticação por máquina.
Em redes sem AD: montar shares via smbclient ou configurar NFS para recursos Linux.

Riscos e mitigação

Risco: credenciais em texto plano no /etc/fstab. Mitigação: usar credencial store (ex.: /etc/smbcredentials com permissão 600) ou kerberos keytabs.

Risco: scripts gerados com permissões incorretas que permitem escalonamento. Mitigação: chown/chmod corretos e revisão de ownership; logs e auditoria.

Risco: pontos de montagem presos após falha. Mitigação: rotina de verificação e cron job que roda um script para desmontar pontos órfãos.

Maturidade e evolução

Nível 1 (básico): scripts locais e /etc/fstab com credenciais genéricas. Nível 2 (intermediário): Kerberos integrado, scripts dinâmicos por usuário, pam_script para logoff. Nível 3 (avançado): automação centralizada, keytabs e gestão de configuração para /etc/skel, CI/CD para imagens LTSP.

Compatibilidade e migração

Teste versões de Samba/cifs-utils e compatibilidade com sec=krb5.
Em migrações para novas versões do Ubuntu, valide formatos de /etc/pam.d e módulos PAM compatíveis.
Ao atualizar LTSP, teste imagens em um ambiente isolado antes de promover em produção.

Procedimento de rollback (execução rápida)

Remova a entrada de Startup Applications que chama win_share.sh.
Pare de servir a imagem LTSP atual (ou altere DHCP para não fornecer next-server temporariamente).
Remova entradas recentes em /etc/skel que causaram problemas.
Reimplemente configurações anteriores a partir de backup.

Mini-metodologia de troubleshooting

Reproduza o problema com uma conta de teste.
Verifique logs: /var/log/syslog, /var/log/auth.log, /var/log/umount.log.
Refaça passos manualmente: execute /usr/local/bin/win_share.sh e veja saídas.
Isole componentes: DHCP/PXE, LTSP, Samba/Kerberos, PAM.

Diagrama de decisão para método de montagem (Mermaid)

flowchart TD
  A[Precisa montar shares Windows no login?] --> B{Ambiente com Kerberos/AD?}
  B -- Sim --> C[Usar mount.cifs com sec=krb5 + scripts dinâmicos]
  B -- Não --> D{Aceita credenciais armazenadas?}
  D -- Sim --> E[Usar /etc/fstab com arquivo de credenciais protegido]
  D -- Não --> F[Considerar autofs ou smbclient sob demanda]
  C --> G[Fazer testes e monitoramento]
  E --> G
  F --> G

Glossário em uma linha

LTSP: Thin client server solution que permite inicialização por rede.
NETLOGON: Share típico do AD/Windows usado para scripts de logon.
Kerberos: protocolo de autenticação baseado em tickets.
pam_script: módulo PAM que executa scripts na abertura/fechamento de sessão.

Notas de segurança e privacidade

Nunca deixe senhas em texto plano em repositórios ou imagens públicas.
Use permissions 600 para arquivos de credenciais e restrinja acesso.
Revise periodicamenta GIDs e ownership configurados no mount.pl.

Resumo final

Este guia mostra um caminho pragmático para integrar thin clients com infraestrutura Windows usando LTSP, Kerberos e scripts automáticos de montagem. Ele prioriza experiências transparentes para o usuário final (montagem automática sem prompts de senha) e inclui passos para desmontar recursos com segurança no logoff. Testes, gerenciamento de permissões e revisão de credenciais são essenciais antes da produção.

Importante: adapte endereços, nomes de servidores, grupos e GIDs ao seu ambiente. Faça auditoria e backup antes de aplicar mudanças em massa.

Configuração de Thin Clients e montagem de shares Windows com Kerberos