GERENCIAMENTO CENTRALIZADO DOS MAPEAMENTOS DE UNIDADES DE REDE NO UBUNTU COM PAM_MOUNT & CID (CLOSED IN DIRECTORY)

Transcrição

1 GERENCIAMENTO CENTRALIZADO DOS MAPEAMENTOS DE UNIDADES DE REDE NO UBUNTU COM PAM_MOUNT & CID (CLOSED IN DIRECTORY) DESCRIÇÃO: Este artigo apresenta a solução pam_mount para o mapeamento automático de unidades de rede durante o logon dos usuários nas estações Linux, e como o cid (Closed In Directory) modifica os arquivos de configuração do sistema para que as definições dos mapeamentos se replique em todas estações da rede. No artigo Ubuntu no AD com cid foi mostrado como utilizar o cid para permitir o logon de usuários de um domínio AD (Active Directory) em estações Ubuntu. Lembrando que o cid trata-se de um Shell Script que faz modificações no sistema para viabilizar esta interoperabilidade, será então apresentada uma dessas modificações realizadas, no intuito de configurar o pam_mount (solução para mapeamento de unidades de rede) de forma centralizada para todas as estações Linux da rede, viabilizando a montagem automática das unidades de rede durante (e de acordo) ao logon do usuário. O PAM_MOUNT A ideia aqui não é discorrer sobre a solução de fato, e sim mostrar como configurá-la de maneira centralizada para realizar o mapeamento automático de compartilhamentos de rede no Linux, mais especificamente sobre o protocolo SMB (ou sistema de arquivos SMB/CIFS), utilizado principalmente nos compartilhamentos de redes Microsoft Windows (suportado também pelo SAMBA ). No Ubuntu, o pacote pode ser instalado através do seguinte comando: $ sudo apt-get install libpam-mount

2 Nota: Durante a execução do script de instalação do cid (INSTALL.sh) este pacote já deve ser instalado automaticamente. Logo, basta executá-lo conforme as instruções de instalação do cid (ler artigo Ubuntu no AD com cid ). O arquivo de configuração global geralmente é o /etc/security/pam_mount.conf.xml. Como pode-se observar, trata-se de um artigo no formato XML, onde suas configurações são definidas por tags (<... />). Segue um exemplo básico deste arquivo de configuração: <pam_mount> <debug enable="0" /> <mkmountpoint enable="1" remove="false" /> <!-- PASTA PÚBLICA (SHARE EM ) --> <volume icase="no" user="*" fstype="cifs" server=" " path="share" mountpoint="/home/%(user)/share" options="uid=0,gid=0,iocharset=utf8,soft,file_mode=0777,dir_mode=0777" /> <logout wait="0" hup="yes" term="yes" kill="yes" /> </pam_mount> Trocando em miúdos: <pam_mount> = Tag inicial. Demarca o início das configurações. <debug enable="0" /> = Habilita ou desabilita o log da aplicação em /var/log/auth.log. 0 (zero) desabilita, 1 (um) habilita. <mkmountpoint enable="1" remove="false" /> = Cria e/ou remove os pontos de montagem das unidades a serem mapeadas caso estes ainda não existam. <!-- --> = Demarcam o início e o fim de um comentário. <logout wait="0" hup="yes" term="yes" kill="yes" /> = Opções para o encerramento da sessão de um usuário. Responsável por matar os processos quando o usuário efetua logoff.

3 Devem terem percebido que pulei a tag <volume... />. Sim, foi de propósito! Não que esta deva ficar por último dentro do arquivo de configuração, pois o ideal é que esteja antes das opções de encerramento (<logout... />), uma vez que o arquivo é lido pelo módulo da aplicação de cima para baixo. Mas, sem mais delongas, a deixei por último por ser justamente a nossa cereja do bolo, pois são dentro dos diversos elementos dessas tags que são definidos os mapeamentos. Então a deixarei para o próximo capítulo para que possamos desmiuçar melhor, não todas as suas opções, mas sim as que nos interessam dentro da finalidade para qual esse artigo foi objetivado.

4 DEFININDO OS MAPEAMENTOS Basicamente, a montagem da unidade de rede se dá através de um comando mount de acordo a uma condição de autenticação. Para quem já montou uma pasta compartilhada de um servidor Windows num terminal Linux certamente já utilizou a seguinte sintaxe do comando mount: # mount t cifs //FILESERVER/COMPARTILHAMENTO /mnt/ponto_de_montagem o user=usuário,pass=senha... Nesta sintaxe, por exemplo, temos sendo especificados, o sistema de arquivos cifs, o hostname (ou IP) do servidor de arquivos FILESERVER, o nome do compartilhamento COMPARTILHAMENTO, o diretório na estação onde será montado o compartilhamento /mnt/ponto_de_montagem, e as opções (-o) de autenticação e montagem, usuário com permissão de acesso ao compartilhamento (definido no servidor), e a respectiva senha. Lembrando que quando a senha não é informada na sintaxe, esta é solicitada logo após a confirmação do comando no bash. A tag <volume... /> basicamente reúne todos esses elementos da sintaxe do comando, porém a autenticação ocorre de forma automática, sem necessidade de informar a senha do usuário que estará montando o mapeamento. Isso é possível porque o módulo pam_mount.so atua no final das pilhas de autenticação (/etc/pam.d/common-auth), e de sessão (/etc/pam.d/common-session) do PAM (Pluggable Authentication Modules), aproveitando os tokens de autenticação dos módulos anteriores da pilha, como por exemplo, pam_krb5.so e/ou pam_winbind.so, para validação do comando de montagem. Sendo assim, se o usuário que realizar o logon no sistema se encaixar em alguma das condições de montagem de alguma das tags <volume... /> especificadas no arquivo, o mapeamento será realizado automaticamente. A seguir alguns exemplos para entendermos melhor os elementos que compõe essa tag:

5 Exemplo 1: Supondo que numa organização cada setor ou departamento tenha um diretório exclusivo compartilhado na rede, onde somente os usuários membros do setor específico tenham acesso a respectiva pasta do grupo. Podemos criar então como exemplo a seguinte tag: <volume icase="no" sgrp="dti" fstype="cifs" server="srv-file" path="dti$" mountpoint="/home/%(user)/dti" options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mode=0770,dir_mode=0770" /> Entendendo os elementos, temos: icase= no -> O XML (e o Linux) é case sensitive, logo para que não haja nenhuma confusão para o sistema quanto os nomes das diversas definições da tag, é recomendado a utilização deste parâmetro com o valor no para desconsiderar a propriedade case sensitive. sgrg= DTI -> Isso significa que se o usuário pertencer ao grupo DTI, o compartilhamento definido será montado. Ou seja, este elemento é que dará a condição se um determinado compartilhamento será montado, ou não para o usuário que efetua o logon. Existem também outras formas de estabelecer essa condição, tais como: user: Especifica a nível de usuário. Seu valor pode ser preenchido para o nome de um único usuário específico, ou pelo asterisco (*) que significa qualquer usuário; pgrp: Similar ao sgrp que especifica a nível do grupo ao qual o usuário pertence, porém este trata-se diretamente do grupo primário, enquanto o sgrp refere-se a um dos grupos secundários ao qual o usuário possa pertencer, sendo que no domínio um usuário só pode ter um único grupo primário, e ser membro de diversos grupos secundários simultaneamente. Geralmente por padrão os usuários do AD quando criados são atribuídos ao grupo usuários do domínio como grupo primário;

6 uid: Especifica o usuário, ou um intervalo de usuários através dos respectivos UID, que nada mais é que o número de identificação do usuário no sistema. Nas configurações do winbind dentro do ficheiro /etc/samba/smb.conf o parâmetro idmap uid delimita o range de UID s que o sistema irá distribuir aos usuários do domínio que se logarem estação. Esse número pode variar para cada estação Ubuntu da rede a depender da ordem dos usuários que se logarem em cada estação e/ou ordem de criação dos usuários no domínio. Para verificar qual o uid atual do usuário numa determinada estação, basta aplicar em seu terminal o comando id. gid: Similar ao uid, sendo que este especifica o id do grupo (ou range) ao qual o usuário pertence. Alinha-se ao parâmetro idmap gid do /etc/samba/smb.conf. fstype="cifs" -> Especifica o filesystem (Sistema de arquivo) referente ao servidor de arquivos. Neste caso o cifs, mais comumente usado nas redes de compartilhamentos Windows, mas também suportado pelos servidores SAMBA ; server="srv-file" -> Informa o hostname ou IP do servidor que dispõe o compartilhamento desejado; path="dti$" -> Informa o nome do compartilhamento propriamente dito. Detalhe é que o cifrão ($) no final do nome é uma característica dos servidores Windows para ocultarem os compartilhamentos na rede. Ou seja, não é obrigatório! É só um exemplo de um compartilhamento com o nome de DTI$ dentro de um servidor Windows que está oculto ao ambiente de rede, justamente por conta do cifrão no final do nome; mountpoint="/home/%(user)/dti" -> Indica onde será montado o compartilhamento, ou seja, o ponto de montagem. Geralmente como o usuário precisa ter acesso a pasta, esta é montada em alguma pasta dentro do seu diretório home por questões de permissões de acesso.

7 Portanto que geralmente é utilizada a variável %(USER), que é substituída pelo nome do usuário que está logando, para indicar o seu home (/home/%(user)). Lembrando que os diretórios home dos usuários do domínio podem não estar exatamente dentro do /home, isso vai depender de como esteja configurado o parâmetro template homedir nas opções do winbind no arquivo /etc/samba/smb.conf. Existem outras variáveis de ambiente que podem ser úteis em outros cenários, tais como: %(GROUP): Substituída pelo grupo primário do usuário; %(DOMAIN_NAME): Substituída pelo nome do domínio ao qual o usuário pertence; %(USERUID), %(USERGID): Indicam respectivamente o UID, e o GID principal do usuário. options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mo de=0770,dir_mode=0770" -> Por fim são estabelecidas de fato as opções de montagem da unidade de rede. Essas opções são variadas de acordo ao protocolo ou sistema de arquivo utilizado pelo servidor do compartilhamento. No manual do comando mount (man mount) é possível ver todas as opções de montagem dentro dos variados protocolos e sistemas de arquivos de ficheiros de rede. Em nossa tag não é necessário especificar todas as opções referentes ao smb/cifs, mas sim as principais, como são utilizadas no exemplo: uid=%(useruid): O comando mount geralmente só pode ser executado com privilégios de super-usuário. Logo após mapeado, as permissões de acesso dos arquivos e subpastas do referente compartilhamento estarão associadas ao usuário root. Isto é péssimo, principalmente no ponto de vista da auditoria do servidor de arquivo, pois toda e qualquer modificação realizada no compartilhamento será gravada no log do serviço como feito pelo root, não sendo possível identificar exatamente o usuário que de fato a fez. Sendo assim a especificação do uid nas opções do comando apontando para variável %(USERUID), que terá o seu valor substituído pelo UID do usuário logado, torna-se de suma importância, pois isso

8 garantirá que as manipulações realizadas no diretório mapeado sejam associadas justamente ao usuário logado, e não ao root (quem executa a montagem). Isso garantirá também que as permissões de segurança implementadas ao compartilhamento através do servidor sejam respeitadas. gid=%(usergid): Seguindo a mesma lógica do uid, porém a nível de grupo primário do usuário. iocharset=utf8: Grosseiramente, faz com que o mapeamento esteja sob sistema de codificação UTF-8, o que permite a tradução de determinados caracteres em nomes de arquivos e pastas, tais como: ç, ~, etc, bem como arquivos de nomes extensos. file_mode=0770: Define as permissões de acesso dos arquivos no formato octal (ver man chmod). Estas deverão estar alinhadas as permissões aplicadas no servidor de arquivos. As permissões mais comuns utilizadas são: o 700 Só o dono (usuário logado) terá permissão total de acesso Compartilhamentos a nível user ; o 770 O usuário e o grupo terão permissão total de acesso Compartilhamento a nível pgrp ou sgrp ; o 777 Permissão total para todos; Nota: Entenda-se como permissão total o poder de leitura (valor 4), escrita/modificação (valor 2), e execução (valor 1). Os valores somados para cada bit de permissão ativado formam a umask do arquivo (4+2+1 = 7), sendo que o primeiro número da máscara identifica a permissão do dono do arquivo; o segundo a permissão referente aos demais usuários dos grupos aos quais pertence; e por último as permissões dadas a quaisquer outros usuários. O valor zero indica nenhuma permissão! dir_mode=0770: Define as permissões de acesso dos DIRETÓRIOS no formato octal.

9 Neste exemplo tivemos então que todos os membros do grupo DTI (grupo de segurança do domínio no AD), irão mapear o compartilhamento DTI$, que está sendo disponibilizado pelo servidor SRV-FILE, dentro do diretório home do usuário, na pasta DTI. Lembrando que se a pasta do ponto de montagem especificado não existir, a tag <mkmountpoint enable="1"... /> garantirá a criação da pasta para que o ponto seja montado. É importante observar que a sigla DTI utilizada tanto para o nome do grupo, nome do compartilhamento, e o nome da pasta, é somente um exemplo, e não significa que estes elementos tenham que ter a mesma nomenclatura. Isso irá depender do cenário da rede, e a forma como os administradores da rede poderão definir. Então para podermos assimilar melhor, segue outro exemplo de um mapeamento montado de acordo ao grupo que o usuário pertence: <volume icase="no" sgrp="drh" fstype="cifs" server=" " path="rh$" mountpoint="/home/%(user)/recursos_humanos" options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mode=0770,dir_mode=0770" /> Neste último exemplo temos que os usuários do grupo DRH irão mapear o compartilhamento RH$, que fica oculto no servidor cujo IP é , em seus diretórios home, numa pasta chamada RECURSOS_HUMANOS. Exemplo 2: Neste cenário gostaria de descrever uma situação que é muito comum em boa parte das organizações, que trata-se do chamado perfil móvel. Supondo que cada usuário do domínio tenha os arquivos do seu perfil de usuário carregados a partir de um compartilhamento num servidor de arquivos. Sendo assim, ele poderá ter acesso aos seus arquivos em qualquer estação da rede que se logar. Ainda pensando neste cenário, vamos dizer que os nomes desses compartilhamentos na rede são exatamente iguais aos nomes dos respectivos usuários. Logo, podemos criar uma única tag <volume /> que será comum a todos os usuários da seguinte forma: <volume icase="no" user="*" fstype="cifs" server=" " path="%(user)" mountpoint="/home/%(user)/ %(USER)_MÓVEL"

10 options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mode=0700,dir_mode=0700" /> Percebam que agora a condição de montagem é definida a nível do usuário (user), onde o asterisco (*) significará qualquer usuário. A variável %(USER) substituída pelo nome do usuário, irá indicar que o nome do compartilhamento será igual ao nome do usuário logado (path= %(USER) ), e que será mapeado dentro do seu próprio diretório home, numa pasta cujo nome será %(USER)_MÓVEL (sendo %(USER) substituído pelo próprio nome do usuário). Importante também observar as opções de permissão de acesso aos arquivos e pastas do compartilhamento em file_mode=0700, e dir_mode=0700, que significa que sendo a pasta exclusiva do usuário, somente o dono (o usuário logado) terá permissão total de acesso, e nem mesmo membros do grupo, nem demais usuários terão qualquer tipo de permissão. Talvez alguém possa se perguntar, e por que não montar o compartilhamento no próprio /home/%(user), já que este terá também justamente o mesmo nome do usuário? Acontece que quando o mapeamento é montado as propriedades de dono da pasta é atribuída ao usuário logado (uid=%(useruid),gid=%(usergid)), que por sua vez não tem permissão de escrever dentro do diretório /home. Quando o usuário loga-se pela primeira vez no Linux, e o seu perfil de usuário é criado dentro do /home, o processo do winbind utiliza-se do id do root (0) para poder criar a estrutura de pastas do usuário dentro deste diretório, e em seguida altera as propriedades dos arquivos e pastas para o usuário que está efetuando o logon. Exemplo 3: Por fim uma última situação também muito comum nos ambientes de rede, que é um compartilhamento público, que pode ser acessado por todos os usuários, independente do grupo de segurança do domínio ao qual seja membro: <volume icase="no" user="*" fstype="cifs" server=" " path="publico" mountpoint="/tmp/publico" options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mode=0777,dir_mode=0777" />

11 Neste caso também é utilizado a condição de montagem a nível do usuário (user), sendo que qualquer usuário que logar-se (representado assim pelo asterisco (*)), irá mapear o compartilhamento PUBLICO, do servidor , na pasta /tmp/publico do sistema de arquivos local. Poderia ter sido utilizado também o home do usuário, mas preferir usar o /tmp para mostrar que pode ser também uma opção de ponto de montagem, uma vez que geralmente no sistema de arquivo Linux, este é um diretório com permissão de acesso total para todos os usuários (drwx-rwx-rwt). Uma outra observação é que como foi utilizado o user= * indicando que qualquer usuário que se logar poderá mapear o compartilhamento, os usuários locais do sistema também poderão realizar essa operação no logon. Logo, caso deseje-se restringir apenas aos usuários do domínio, é possível utilizar a condição a nível de uid definindo a range de ID s desses usuários de acordo ao parâmetro idmap uid nas configurações do winbind em /etc/samba/smb.conf. A tag então ficaria da seguinte forma: <volume icase="no" uid=" " fstype="cifs" server=" " path="publico" mountpoint="/tmp/publico" options="uid=%(useruid),gid=%(usergid),iocharset=utf8,file_mode=0777,dir_mode=0777" /> Ou seja, será mapeado para todos os usuários cujo ID esteja dentro do range " ". De acordo ao propósito deste artigo, estas foram as configurações do pam_mount que nos interessavam. Nota: Para uma visão mais ampla da solução, e todas as suas possibilidades, pode-se acessar o link am_mount.conf.5.html. O manual está em inglês, mas o Google Tradutor está ai para isso (fica a dica!). No entanto, percebemos que o arquivo de configuração do pam_mount, onde foram definidos os mapeamentos ficam no ficheiro

12 /etc/security/pam_mount.conf.xml do sistema de arquivos local da estação Ubuntu. Isto significa que toda essa configuração teria que ser replicada uma a uma em todas as estações da rede, e toda vez que houvesse uma mudança referente ao esquema de mapeamento, seria necessário alterar esse arquivo em cada máquina novamente. Porém eu disse teria, porque é justamente ai onde o cid entra com o que podemos chamar de cereja do bolo...

13 CENTRALIZANDO O GERENCIAMENTO E A CONFIGURAÇÃO DO PAM_MOUNT Como havia dito, o cid é apenas um shell script que faz modificações interessantes em determinados arquivos de configuração, relacionadas a soluções de interoperabilidade entre os ambientes Linux e Windows, no intuito de tornar esses ambientes os mais homogêneos possíveis. Logo, quando descobri esta fantástica ferramenta, pam_mount, pensei em como eu poderia utilizá-la para gerenciar toda uma rede de estações Ubuntu de forma centralizada ou remota, de forma similar à como é feita para mapear as unidades de rede dos usuários em estações Windows (seja lá por um script de logon para cada usuário, ou um script para cada grupo de usuários dentro de uma Unidade Organizacional, por exemplo, através de uma GPO)? Enfim, acabei chegando a uma ideia que se tornaria uma solução ainda melhor que as soluções utilizadas para as estações Windows, a partir do ponto de vista que em um único script eu teria definidos todos os mapeamentos para todos os usuários ou grupos de usuários da rede, e todas as possíveis modificações que tivessem de ser realizadas posteriormente, eu também só precisaria alterar este único arquivo apenas, e isto seria válido para toda minha rede. E como fazer? Simples! Pega-se um arquivo de configuração do pam_mount, define-se todas as tags de volumes referentes aos possíveis mapeamentos de acordo ao cenário da rede, salva-se em algum lugar público na rede onde todas as minhas estações Linux possam ter acesso (ou seja, num compartilhamento), e apenas as instrui a sempre substituir o ficheiro /etc/security/pam_mount.conf.xml do seu sistema de arquivo, por este outro arquivo.xml publicado na rede, cujo possa-se acessar de qualquer lugar, para se fazer as devidas alterações quando necessárias. Como acontece?

14 Após ingressar a estação Ubuntu no domínio, o script do cid acessa o compartilhamento público NETLOGON que fica no servidor AD. Geralmente, toda vez que um servidor Windows é eleito servidor de domínio, ou seja, toda vez que o AD é instalado, é configurado automaticamente neste servidor o compartilhamento NETLOGON, cuja finalidade principal é justamente carregar os scripts de logon para os usuários e estações da rede. Nesse compartilhamento é dada permissão de leitura para todos os usuários da rede, porém as modificações só poderão ser realizadas por membros do grupo de administradores (admins. do domínio). Logo o cid usa as mesmas credenciais do usuário com privilégios de administrador do domínio para montar esse compartilhamento na estação Ubuntu que foi ingressada, e verificar se o arquivo shares.xml já existe dentro do NETLOGON. Caso não exista, ele exporta o diretório /usr/lib/cid/scripts_cid para o NETLOGON, que contém o arquivo shares.xml, onde deverão ser definidos os mapeamentos para toda a rede, e esse arquivo posteriormente será replicado para todas as máquinas Ubuntu, substituindo os seus ficheiros /etc/security/pam_mount.conf.xml por ele. A substituição ocorrerá da seguinte forma: Ainda após o ingresso da estação no domínio, nas configurações finais realizadas pelo cid, será criada a seguinte entrada nas linhas finais do arquivo /etc/fstab : # --- < Modified by cid > --- < NETLOGON in [HOSTNAME_AD] for users of [DOMÍNIO] > --- # //[IP_DO_AD]/netlogon /mnt/.netlogon cifs users,credentials=/usr/lib/cid/control/.key_netlogon,file_mode=0775,dir_mode=0775,iocharset= utf8,mapchars,nocase,soft 0 0 Isto fará com que o netlogon seja montado em /mnt/.netlogon toda vez que a estação for ligada. Cria-se também a seguinte entrada no arquivo /etc/rc.local: # --- < Modified by cid > --- #

15 /bin/cp -f /mnt/.netlogon/scripts_cid/shares.xml /etc/security/pam_mount.conf.xml Essa é exatamente a linha de comando que substitui o ficheiro /etc/security/pam_mount.conf.xml pelo shares.xml que contém todas as definições dos mapeamentos das unidades de rede. Mas, pensando numa possível falha na montagem automática do compartilhamento durante o start do sistema, seja por uma falha de comunicação na rede, ou qualquer outro motivo, é que o cid já traz préconfigurado dentro da pilha dos módulos de sessão do PAM o módulo pam_exec.so, que será responsável pela execução dos seguintes comandos durante o logon do usuário: session optional pam_exec.so debug quiet /bin/mount -a session optional pam_exec.so debug quiet /bin/cp -f /mnt/.netlogon/scripts_cid/shares.xml /etc/security/pam_mount.conf.xml O /bin/mount a se encarregará de forçar a montagem de todos os volumes declarados em /etc/fstab. E o comando /bin/cp vai fazer uma cópia para substituir o conteúdo do arquivo pam_mount.conf.xml pelo do shares.xml. Vale frisar que dentro da pilha de sessão, os módulos que executam os comandos (pam_exec.so) são declarados antes do módulo do pam_mount.so, o que permite que se caso haja uma nova modificação, o seu arquivo de configuração é atualizado antes da aplicação promover a montagem dos volumes para o usuário que está logando-se no sistema. Ao final do logon o NETLOGON é automaticamente desmontado por questões de segurança, uma vez que a montagem é realizada através das credenciais do usuário com privilégios de administrador que fez o ingresso da determinada estação no domínio, sendo assim um usuário comum poderia ter acesso aos arquivos e pastas contidos neste compartilhamento com privilégios totais de manipulação.

16 A desmontagem é chamada pelo próprio usuário durante o término do logon através de uma linha de um script executado por todos os usuários do domínio, invocado através da seguinte modificação que o cid faz no /etc/profile : # --- < Modified by cid > --- # sh /usr/lib/cid/exec/uid_logon.sh Nota: Não deve-se alterar o nome do diretório scripts_cid dentro do NETLOGON, bem como os nomes dos arquivos, e sub-diretórios nele contido, principalmente o shares.xml, pois o comando /bin/cp que faz a substituição do conteúdo dos ficheiros do sistema de arquivo local das estações pelos dessa pasta, utiliza o caminho absoluto desses arquivos previamente definidos durante a programação do cid! (Ex.: /bin/cp f /mnt/.netlogon/scripts_cid/shares.xml /etc/security/pam_mount.conf.xml)

17 ACESSANDO RAPIDAMENTE O SHARES.XML EM NETLOGON Apesar de ser possível ler, e editar o shares.xml dentro do próprio servidor Windows, é preferível que modificações neste arquivo sejam realizadas nas estações Linux, e seus próprios editores de texto. Geralmente é possível acessar rapidamente compartilhamentos Windows através do gerenciador de arquivos do Ubuntu (nautilus, por exemplo), desde que os plug-ins do samba estejam devidamente instalados. Isto serve também para as distribuições derivadas do Ubuntu. Logado com um usuário do domínio com privilégios de administrador, basta-se apenas então invocar uma espécie de barra de execução através da combinação das teclas de atalho ALT + F2, ou na opção de digitar o local da barra de endereços do próprio gerenciador de arquivos, e informar em seguida o caminho do compartilhamento da seguinte forma: smb://[ip_ou_hostname_do_ad]/netlogon

18

19

20 UM PEQUENO BUG Como vimos, o cid configura o /etc/fstab para que seja montado o NETLOGON na estação Linux, no intuito de exportar o conteúdo do shares.xml para o ficheiro de configuração do pam_mount (/etc/security/pam_mount.conf.xml), bem como para a execução do script de logon (logon.sh - ver artigos posteriores). Porém para montar este mapeamento do fstab é utilizada as mesmas credenciais do usuário com privilégios de administrador que ingressou a estação no domínio, que é guardada pelo cid durante o ingresso da estação, num arquivo somente leitura e escrita para o root (chmod 600). Isso significa que se a senha deste usuário for alterada, por questões de segurança, ou qualquer outro motivo, dentro do domínio, o mapeamento deixará de ser montado, até que este usuário, ou qualquer outro com privilégios de administrador, com a senha atualizada, remova e ingresse novamente a estação no domínio, ou atualize o campo password deste arquivo para senha nova correspondente. Processo que terá que ser repetido se mais uma vez a senha deste usuário expirar, ou for alterada. Nas versões anteriores do cid eu utilizava o próprio pam_mount para montar o netlogon nas estações utilizando a seguinte tag já pré-configurada no /etc/security/pam_mount.conf.xml, e no shares.xml : <volume icase="no" user="*" fstype="cifs" server="[ip_do_ad]" path="netlogon" mountpoint="/mnt/.netlogon" options="uid=0,gid=0,iocharset=utf8,file_mode=0775,dir_mode=0775" /> No entanto toda alteração realizada no shares.xml só entrava em vigor a partir de um 2º logon de usuário numa determinada estação, pois no primeiro o pam_mount era executado antes de realizar a cópia do /mnt/.netlogon/scripts_cid/shares.xml para /etc/security/pam_mount.conf.xml, e só depois de um logoff e um novo logon, é que as alterações do arquivo surtiam efeito a partir de um novo início de sessão do pam_mount. Então voltei a utilizar o fstab (da forma como já havia pensado antes na primeira versão do cid), e até que surja uma nova ideia, ou uma boa sugestão

21 com ajuda de vocês da comunidade, a minha sugestão seria criar um usuário no domínio, e torna-lo membro do grupo de administradores (admins. do domínio) para que tenha privilégios administrativos, sendo que este usuário terá uma senha fixa (que não expira). Sendo assim, deveria-se sempre utilizar esta conta de usuário para ingressar as estações Ubuntu no domínio, para não se ter problemas futuros com expiração da senha dessa conta.

22 Sei que não é o ideal, mas como nada é perfeito... Apesar de estarmos caminhando neste sentido. Contudo, espero que tenham gostado da ideia, ou que pelo menos aprovem a intenção, pois o cid é um projeto novo, o qual eu venho amadurecendo ao passar do tempo, e que der repente pode se tornar de fato um grande incentivo ao uso do software livre dentro das organizações!