pam_mount e CiD - Gerenciamento centralizado dos mapeamentos de unidades de rede no Ubuntu
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 GNU/Linux, e como o CiD (Closed in Directory) modifica os arquivos de configuração do sistema, para que as definições dos mapeamentos se repliquem em todas as estações da rede.
[ Hits: 37.649 ]
Por: Perfil removido em 12/09/2014
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 GNU/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:
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:
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 à respectiva pasta do grupo. Podemos criar então, como exemplo, a seguinte tag:
Entendendo os elementos, temos:
icase=no :: o XML (e o GNU/Linux) é "case sensitive", logo, para que não haja nenhuma confusão para o sistema quanto aos 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:
fstype=cifs :: especifica o filesystem (sistema de arquivos) 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 à pasta, esta é montada em alguma pasta dentro do seu diretório home por questões de permissões de acesso. 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:
options=uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=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 superusuá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 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.
As permissões mais comuns utilizadas, são:
* Nota: entende-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!
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:
Neste último exemplo, temos que os usuários do grupo "DRH" irão mapear o compartilhamento "RH$", que fica oculto no servidor cujo IP é 192.168.1.100, 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:
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, são atribuídas 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 GNU/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:
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 192.168.1.101, na pasta /tmp/PUBLICO do sistema de arquivos local.
Poderia ter sido utilizado também o home do usuário, mas preferi usar o /tmp para mostrar que pode ser também uma opção de ponto de montagem, uma vez que geralmente no sistema de arquivos 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 IDs 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:
Ou seja, será mapeado para todos os usuários cujo ID esteja dentro do range "10000-2000000".
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:
O manual está em inglês, mas o Google Tradutor está aí 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 /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 aí onde o CiD entra, com o que podemos chamar de "cereja do bolo".
# 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:
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 à 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 GNU/Linux) é "case sensitive", logo, para que não haja nenhuma confusão para o sistema quanto aos 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.
- 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 UIDs que o sistema irá distribuir aos usuários do domínio que se logarem na 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 arquivos) 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 à pasta, esta é montada em alguma pasta dentro do seu diretório home por questões de permissões de acesso. 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_mode=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 superusuá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 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:
- 700 :: só o dono (usuário logado) terá permissão total de acesso - compartilhamentos a nível user.
- 770 :: o usuário e o grupo terão permissão total de acesso - compartilhamento a nível pgrp ou sgrp.
- 777 :: permissão total para todos.
- dir_mode=0770 :: define as permissões de acesso dos "DIRETÓRIOS" no formato octal.
* Nota: entende-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!
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="192.168.1.100" 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 é 192.168.1.100, 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="192.168.1.100" path="%(USER)" mountpoint="/home/%(USER)/ %(USER)_MÓVEL" 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, são atribuídas 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 GNU/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="192.168.1.101" path="PUBLICO" mountpoint="/tmp/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777" />
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 192.168.1.101, na pasta /tmp/PUBLICO do sistema de arquivos local.
Poderia ter sido utilizado também o home do usuário, mas preferi usar o /tmp para mostrar que pode ser também uma opção de ponto de montagem, uma vez que geralmente no sistema de arquivos 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 IDs 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="10000-2000000" fstype="cifs" server="192.168.1.101" 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 "10000-2000000".
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:
O manual está em inglês, mas o Google Tradutor está aí 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 /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 aí onde o CiD entra, com o que podemos chamar de "cereja do bolo".
Páginas do artigo
1. Introdução2. Definindo os mapeamentos
3. Centralizando gerenciamento e configuração do pam_mount com CiD
4. NETLOGON e editando shares.xml
Outros artigos deste autor
Instalando o modem Huawey E1556 no GNU/Linux
Datagramas IP (Protocolo Internet)
Leitura recomendada
Ingressando estações de trabalho Ubuntu no AD com Closed In Directory
Kit de scripts para backup (Full + Diferencial + Samba + Rede)
Processamento Paralelo em Shell Script - Conversão de Arquivos WAV para MP3
Assinatura de documentos PDF em lote via Bash
Comentários
[1] Comentário enviado por pinguintux em 13/09/2014 - 12:03h
Boa tarde Eduardo! Mais uma vez, parabéns pelo excelente material disponibilizado. Consegui aplicar com sucesso os mapeamentos automáticos, principalmente para os grupos, conforme suas orientações. Eu ainda estou na luta para criar o perfil padrão para os usuários. Caso o nobre amigo tenha mais alguma orientação será muito bem vinda!
Saudações!
Boa tarde Eduardo! Mais uma vez, parabéns pelo excelente material disponibilizado. Consegui aplicar com sucesso os mapeamentos automáticos, principalmente para os grupos, conforme suas orientações. Eu ainda estou na luta para criar o perfil padrão para os usuários. Caso o nobre amigo tenha mais alguma orientação será muito bem vinda!
Saudações!
[2] Comentário enviado por removido em 14/09/2014 - 22:08h
Então companheiro... Não tive muito tempo para encontrar uma solução, mas creio que você pode estar utilizando o script "logon.sh" que fica na pasta "scripts_cid" no netlogon do seu servidor de domínio para definir configurações comuns a todos os usuários através do comando ''gsettings". É provável que eu publique um novo artigo para falar desse script de logon que você pode estar gerenciando de forma centralizada também, pois será sincronizado com todas as estações ubuntu ingressas no domínio pelo cid.
Não vou entrar em muitos detalhes agora por falta de tempo mesmo, mas de antemão te adianto que trata-se basicamente de um comando para alterar valores de chaves dentro de um determinado "esquema de diretórios" referente a uma série de configurações possíveis nos diversos aplicativos do Ubuntu.
Para ficar mais fácil de entender, instale o pacote "dconf-editor" (sudo apt-get install dconf-editor -y). Depois o execute em modo gráfico (ALT + F2 >> gconf-editor). Abrirá justamente o gerenciador gráfico para que possa alterar essas chaves. Selecionando cada chave há uma descrição para tal, o que vai te ajudar a entender melhor a configuração. De qualquer forma, o script "logon.sh" exportado pelo cid para o netlogon, já traz alguns exemplos de configuração que você pode estar seguindo para melhor compreender, e já aplicar até mesmo ao seu cenário.
Fiz algumas modificações no pacote para adaptar esse script as versões 13.04 do Ubuntu e superiores, e também para resolver o problema do atraso na resposta da estação quando uma conta de usuário entra em modo de bloqueio de tela. Acredito que isso se deu por conta de alguns parâmetros do winbind que esqueci de pré-configurar para o ficheiro "/etc/samba/smb.conf" enquanto escrevia o código do cid. Após isso, testei em meu ambiente virtual e não notei mais nenhum problema. Se acaso em seu cenário persista, por favor me avise, para que eu possa estudar melhorias.
Baixe então a versão mais nova (5.1) que estarei disponibilizando no sourceforge (http://sourceforge.net/projects/c-i-d/), mas antes de instalar, remova a estação do domínio que já havia inserido com a versão anterior (5.0), e após instalar a nova, ingresse-a novamente.
Agradeço mais uma vez por todo prestígio, e aguardo retorno!
Abraços!
Então companheiro... Não tive muito tempo para encontrar uma solução, mas creio que você pode estar utilizando o script "logon.sh" que fica na pasta "scripts_cid" no netlogon do seu servidor de domínio para definir configurações comuns a todos os usuários através do comando ''gsettings". É provável que eu publique um novo artigo para falar desse script de logon que você pode estar gerenciando de forma centralizada também, pois será sincronizado com todas as estações ubuntu ingressas no domínio pelo cid.
Não vou entrar em muitos detalhes agora por falta de tempo mesmo, mas de antemão te adianto que trata-se basicamente de um comando para alterar valores de chaves dentro de um determinado "esquema de diretórios" referente a uma série de configurações possíveis nos diversos aplicativos do Ubuntu.
Para ficar mais fácil de entender, instale o pacote "dconf-editor" (sudo apt-get install dconf-editor -y). Depois o execute em modo gráfico (ALT + F2 >> gconf-editor). Abrirá justamente o gerenciador gráfico para que possa alterar essas chaves. Selecionando cada chave há uma descrição para tal, o que vai te ajudar a entender melhor a configuração. De qualquer forma, o script "logon.sh" exportado pelo cid para o netlogon, já traz alguns exemplos de configuração que você pode estar seguindo para melhor compreender, e já aplicar até mesmo ao seu cenário.
Fiz algumas modificações no pacote para adaptar esse script as versões 13.04 do Ubuntu e superiores, e também para resolver o problema do atraso na resposta da estação quando uma conta de usuário entra em modo de bloqueio de tela. Acredito que isso se deu por conta de alguns parâmetros do winbind que esqueci de pré-configurar para o ficheiro "/etc/samba/smb.conf" enquanto escrevia o código do cid. Após isso, testei em meu ambiente virtual e não notei mais nenhum problema. Se acaso em seu cenário persista, por favor me avise, para que eu possa estudar melhorias.
Baixe então a versão mais nova (5.1) que estarei disponibilizando no sourceforge (http://sourceforge.net/projects/c-i-d/), mas antes de instalar, remova a estação do domínio que já havia inserido com a versão anterior (5.0), e após instalar a nova, ingresse-a novamente.
Agradeço mais uma vez por todo prestígio, e aguardo retorno!
Abraços!
[3] Comentário enviado por serafim.fabio em 18/09/2014 - 08:13h
Parabens pelo seu artigo, estou tentando por um comando para ser executado no logon como no caso dos compartilhamento, só que para desabilitar a usb de algumas máquinas do domínio, sendo estes os comandos: rmmod usb_storage e echo blacklist usb_storage >> /etc/modprobe.d/blacklist.conf, ja pus no logon.sh mas não obtive sucesso.
Parabens pelo seu artigo, estou tentando por um comando para ser executado no logon como no caso dos compartilhamento, só que para desabilitar a usb de algumas máquinas do domínio, sendo estes os comandos: rmmod usb_storage e echo blacklist usb_storage >> /etc/modprobe.d/blacklist.conf, ja pus no logon.sh mas não obtive sucesso.
[4] Comentário enviado por removido em 18/09/2014 - 13:38h
Obrigado "serafim.fabio"!
O logon.sh é executado com o próprio ID do usuário que efetua logon, e o arquivo que você tenta modificar (/etc/modprobe.d/blacklist.conf) só pode ser alterado pelo root, e por isso que não irá conseguir pelo "logon.sh".
Foi ótimo você ter trazido esta situação problema, porque já é algo que venho pensando e tentando encontrar uma solução viável e segura para implementar ao "cid", que é justamente a possibilidade dos administradores definirem scripts que sejam executados no logon por qualquer usuário com privilégios de root, o que facilitaria justamente a administração remota das estações de trabalho Ubuntu. Já fiz alguns testes, mas ainda não conseguir 100% de segurança, pois da forma que imaginei, os usuários comuns ainda poderiam executar qualquer outro comando com esses privilégios, mesmo após o logon, e que poderia causar consequências drásticas. Porém, assim que aperfeiçoar a ideia, pretendo implementar numa atualização do cid, e volto a te responder com esta solução concretizada. Até lá, acredito que a única forma de realizar a configuração que deseja é criando este script manualmente em cada estação para ser carregado, por exemplo, a cada inicialização do sistema (/etc/rc.local).
Obrigado mais uma vez!
Abraços!
Obrigado "serafim.fabio"!
O logon.sh é executado com o próprio ID do usuário que efetua logon, e o arquivo que você tenta modificar (/etc/modprobe.d/blacklist.conf) só pode ser alterado pelo root, e por isso que não irá conseguir pelo "logon.sh".
Foi ótimo você ter trazido esta situação problema, porque já é algo que venho pensando e tentando encontrar uma solução viável e segura para implementar ao "cid", que é justamente a possibilidade dos administradores definirem scripts que sejam executados no logon por qualquer usuário com privilégios de root, o que facilitaria justamente a administração remota das estações de trabalho Ubuntu. Já fiz alguns testes, mas ainda não conseguir 100% de segurança, pois da forma que imaginei, os usuários comuns ainda poderiam executar qualquer outro comando com esses privilégios, mesmo após o logon, e que poderia causar consequências drásticas. Porém, assim que aperfeiçoar a ideia, pretendo implementar numa atualização do cid, e volto a te responder com esta solução concretizada. Até lá, acredito que a única forma de realizar a configuração que deseja é criando este script manualmente em cada estação para ser carregado, por exemplo, a cada inicialização do sistema (/etc/rc.local).
Obrigado mais uma vez!
Abraços!
[5] Comentário enviado por removido em 19/09/2014 - 01:21h
Resolvido o problema!
Lançando agorinha mesmo uma atualização do cid (cid 5.2) onde será possível executar comandos com privilégios de root automaticamente a partir do logon de qualquer usuário, ainda que seja um usuário comum. Com isso será possível aos administradores aplicar modificações no sistema de forma remota para toda a rede, ou parte dela se assim preferir. Para tanto basta editar o novo script ".logon_(root).sh" que deverá aparecer no diretório "scripts_cid" dentro do netlogon do servidor de domínio. Maiores detalhes em um possível artigo posterior.
Abraços!
Resolvido o problema!
Lançando agorinha mesmo uma atualização do cid (cid 5.2) onde será possível executar comandos com privilégios de root automaticamente a partir do logon de qualquer usuário, ainda que seja um usuário comum. Com isso será possível aos administradores aplicar modificações no sistema de forma remota para toda a rede, ou parte dela se assim preferir. Para tanto basta editar o novo script ".logon_(root).sh" que deverá aparecer no diretório "scripts_cid" dentro do netlogon do servidor de domínio. Maiores detalhes em um possível artigo posterior.
Abraços!
[6] Comentário enviado por serafim.fabio em 26/09/2014 - 14:19h
Obrigado Eduardo Moraes, eu estava viajando, ja estou testando, pelo que entendi posso por no arquivo .logon_(root).sh, pretendo por estas duas linhas
#rmmod usb_storage
# echo blacklist usb_storage >> /etc/modprobe.d/blacklist.conf
Obrigado Eduardo Moraes, eu estava viajando, ja estou testando, pelo que entendi posso por no arquivo .logon_(root).sh, pretendo por estas duas linhas
#rmmod usb_storage
# echo blacklist usb_storage >> /etc/modprobe.d/blacklist.conf
[7] Comentário enviado por serafim.fabio em 26/09/2014 - 17:01h
esta dando esse erro, ele não esta montando
cp: impossível obter estado de “/mnt/.netlogon/scripts_cid/logon.sh”: Permissão negada
sh: 0: Can't open /mnt/.netlogon/scripts_cid/logon.sh
sh: 0: Can't open /home/secinfo2/.cid/logon.sh
esta dando esse erro, ele não esta montando
cp: impossível obter estado de “/mnt/.netlogon/scripts_cid/logon.sh”: Permissão negada
sh: 0: Can't open /mnt/.netlogon/scripts_cid/logon.sh
sh: 0: Can't open /home/secinfo2/.cid/logon.sh
[8] Comentário enviado por removido em 27/09/2014 - 15:38h
"Serafim.fabio",
Há algumas possibilidades que podem explicar o motivo dessa erro por falta de permissão;
1 - Possa ser que no momento em que a sua estação foi inserida no domínio o cid não conseguiu acessar o compartilhamento "netlogon" do seu AD e acabou copiando a pasta "scripts_cid" para dentro do diretório local da sua estação "/mnt/.netlogon" com o id do usuário root. Sendo assim, o netlogon que deveria ser montando nessa pasta, na verdade não estar sendo montando, e quando o usuário comum efetua logon não consegue executar o script por conta da permissão, uma vez que este pertence ao root. Neste caso, o mais fácil seria vc apenas remover o diretório com o comando "# rm -rf /mnt/.netlogon", e verificar se no compartilhamento netlogon do AD já existe a pasta "scripts_cid". Se não existe, use o cid para remover a estação do domínio, e depois para inseri-lá novamente (utilize a versão mais recente do cid - 5.3). Lembrando que ao atualizar a versão do cid, é extremamente recomendável que antes você remova a estação do domínio, e insira novamente já com a nova versão.
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
O "mount -a" força a montagem dos volumes definidos em "/etc/fstab", ou seja, se tiver faltando uma dessas duas entradas em seus respectivos arquivos certamente o netlogon do seu AD não será montado para a execução do script durante o logon do usuário.
Seja lá qual for a causa deste erro estar ocorrendo certamente foi por uma falha "não prevista" durante o ingresso da estação no domínio. Então muito provavelmente a solução mais provável é repetir o procedimento após removê-la do domínio, e utilizando a versão mais recente. Já revisei o código do cid diversas vezes, e ainda não encontrei motivos para isso ocorrer, pois definir em seu shell script, que a cópia do diretório "scripts_cid" só deve ser realizada para o diretório /mnt/.netlogon, somente se o compartilhamento netlogon do AD esteja realmente montado nesse diretório, justamente para que não seja copiado para o diretório local da estação. De qualquer forma, antes de você tentar solucionar o problema com as orientações que te passei, peço que aplique o comando "ls -la /mnt/.netlogon/scripts_cid" para confirmar o nome do usuário e grupo que aparece como dono do diretório e arquivos, e depois que relatasse isso para mim. Isso é muito importante para que eu possa aperfeiçoar o "cid" a cada dia, e conto com essa ajuda!
"Serafim.fabio",
Há algumas possibilidades que podem explicar o motivo dessa erro por falta de permissão;
1 - Possa ser que no momento em que a sua estação foi inserida no domínio o cid não conseguiu acessar o compartilhamento "netlogon" do seu AD e acabou copiando a pasta "scripts_cid" para dentro do diretório local da sua estação "/mnt/.netlogon" com o id do usuário root. Sendo assim, o netlogon que deveria ser montando nessa pasta, na verdade não estar sendo montando, e quando o usuário comum efetua logon não consegue executar o script por conta da permissão, uma vez que este pertence ao root. Neste caso, o mais fácil seria vc apenas remover o diretório com o comando "# rm -rf /mnt/.netlogon", e verificar se no compartilhamento netlogon do AD já existe a pasta "scripts_cid". Se não existe, use o cid para remover a estação do domínio, e depois para inseri-lá novamente (utilize a versão mais recente do cid - 5.3). Lembrando que ao atualizar a versão do cid, é extremamente recomendável que antes você remova a estação do domínio, e insira novamente já com a nova versão.
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
O "mount -a" força a montagem dos volumes definidos em "/etc/fstab", ou seja, se tiver faltando uma dessas duas entradas em seus respectivos arquivos certamente o netlogon do seu AD não será montado para a execução do script durante o logon do usuário.
Seja lá qual for a causa deste erro estar ocorrendo certamente foi por uma falha "não prevista" durante o ingresso da estação no domínio. Então muito provavelmente a solução mais provável é repetir o procedimento após removê-la do domínio, e utilizando a versão mais recente. Já revisei o código do cid diversas vezes, e ainda não encontrei motivos para isso ocorrer, pois definir em seu shell script, que a cópia do diretório "scripts_cid" só deve ser realizada para o diretório /mnt/.netlogon, somente se o compartilhamento netlogon do AD esteja realmente montado nesse diretório, justamente para que não seja copiado para o diretório local da estação. De qualquer forma, antes de você tentar solucionar o problema com as orientações que te passei, peço que aplique o comando "ls -la /mnt/.netlogon/scripts_cid" para confirmar o nome do usuário e grupo que aparece como dono do diretório e arquivos, e depois que relatasse isso para mim. Isso é muito importante para que eu possa aperfeiçoar o "cid" a cada dia, e conto com essa ajuda!
[9] Comentário enviado por removido em 27/09/2014 - 15:42h
Esqueci também de dizer que é crucial também que ao inserir a estação no domínio você utilize uma conta do domínio com privilégios de administrador do domínio, ou que pertença ao grupo "admins. do domínio" (ou domain admins em inglês) do seu AD.
Esqueci também de dizer que é crucial também que ao inserir a estação no domínio você utilize uma conta do domínio com privilégios de administrador do domínio, ou que pertença ao grupo "admins. do domínio" (ou domain admins em inglês) do seu AD.
[10] Comentário enviado por serafim.fabio em 28/09/2014 - 21:57h
Boa noite Moraes, obrigado pelo sua disposição em ajudar, eu estou utilizando a 5.3, fiz os dois passos que pediste e removi a maquina do domínio, remove e instalei o cid,
quando executo mount -a ele monta normalmente
quando logo com um usuário do grupo admins, não da erro, mas se é um usuário comun, da esse erro: cp: impossível obter estado de “/mnt/.netlogon/scripts_cid/logon.sh”: Permissão negada
sh: 0: Can't open /mnt/.netlogon/scripts_cid/logon.sh
sh: 0: Can't open /home/secinfo4/.cid/logon.sh
fiz alguns testes comentei a desmontagem do netlogon no arquivo uid_logon.sh reinicie e dei um ls com usuario comun /mnt/.netlogon/ e resultado: não foi possível abrir o diretório /mnt/.netlogon/: Permissão negada
Boa noite Moraes, obrigado pelo sua disposição em ajudar, eu estou utilizando a 5.3, fiz os dois passos que pediste e removi a maquina do domínio, remove e instalei o cid,
quando executo mount -a ele monta normalmente
quando logo com um usuário do grupo admins, não da erro, mas se é um usuário comun, da esse erro: cp: impossível obter estado de “/mnt/.netlogon/scripts_cid/logon.sh”: Permissão negada
sh: 0: Can't open /mnt/.netlogon/scripts_cid/logon.sh
sh: 0: Can't open /home/secinfo4/.cid/logon.sh
fiz alguns testes comentei a desmontagem do netlogon no arquivo uid_logon.sh reinicie e dei um ls com usuario comun /mnt/.netlogon/ e resultado: não foi possível abrir o diretório /mnt/.netlogon/: Permissão negada
[11] Comentário enviado por removido em 28/09/2014 - 22:43h
Desculpa serafim, mas ainda não consegui identificar a causa do seu problema, pois já fiz diversos testes no meu cenário, e tudo ocorre perfeitamente. Talvez eu esteja desconsiderando as possibilidades mais óbvias, então vou pedir que me passe uma descrição mais completa do seu cenário para tentarmos identificar o que possa der repente estar trazendo alguma diferença.
Vou precisar que:
- Me diga qual é a versão do Windows Server que está instalado o seu AD;
- Qual a distribuição e versão do Linux (Se Ubuntu, Kubuntu, Debian, etc... E a respectiva versão);
- Se estar utilizando realmente uma conta de usuário do domínio para ingressar a estação com o cid;
- Que verifique no seu servidor AD quais são as permissões de segurança do compartilhamento NETLOGON. Certifique-se de que "todos os usuários" tenham no mínimo permissão de "leitura";
- Logue na sua estação Linux com um usuário local do sistema, certifique-se que o "NETLOGON" NÃO esteja montado em "/mnt/.netlogon" com um simples comando "mount" (irá exibir os volumes montados no momento); se estiver montado, desmonte-o com o "umount"; em seguida certifique-se de que não haja absolutamente nada em /mnt/.netlogon com um ls -la /mnt/.netlogon; Caso exista a pasta scripts_cid neste diretório sem o NETLOGON está montado nele, remova esta pasta com um rm -rf /mnt/.netlogon/scripts_cid; Em seguida, use o "mount -a" e certifique de que o NETLOGON agora tenha sido realmente montado (use mount novamente), logo importe a pasta "scripts_cid" padrão que vem na instalação do cid no diretório "/usr/lib/cid/scripts_cid" com um "cp -rfv /usr/lib/cid/scripts_cid /mnt/.netlogon;
Por enquanto aguardarei que realize estes procedimentos, e que me dê um retorno, pois em caso de persistir o problema pensarei em possíveis novas soluções para te passar.
Grato!
Desculpa serafim, mas ainda não consegui identificar a causa do seu problema, pois já fiz diversos testes no meu cenário, e tudo ocorre perfeitamente. Talvez eu esteja desconsiderando as possibilidades mais óbvias, então vou pedir que me passe uma descrição mais completa do seu cenário para tentarmos identificar o que possa der repente estar trazendo alguma diferença.
Vou precisar que:
- Me diga qual é a versão do Windows Server que está instalado o seu AD;
- Qual a distribuição e versão do Linux (Se Ubuntu, Kubuntu, Debian, etc... E a respectiva versão);
- Se estar utilizando realmente uma conta de usuário do domínio para ingressar a estação com o cid;
- Que verifique no seu servidor AD quais são as permissões de segurança do compartilhamento NETLOGON. Certifique-se de que "todos os usuários" tenham no mínimo permissão de "leitura";
- Logue na sua estação Linux com um usuário local do sistema, certifique-se que o "NETLOGON" NÃO esteja montado em "/mnt/.netlogon" com um simples comando "mount" (irá exibir os volumes montados no momento); se estiver montado, desmonte-o com o "umount"; em seguida certifique-se de que não haja absolutamente nada em /mnt/.netlogon com um ls -la /mnt/.netlogon; Caso exista a pasta scripts_cid neste diretório sem o NETLOGON está montado nele, remova esta pasta com um rm -rf /mnt/.netlogon/scripts_cid; Em seguida, use o "mount -a" e certifique de que o NETLOGON agora tenha sido realmente montado (use mount novamente), logo importe a pasta "scripts_cid" padrão que vem na instalação do cid no diretório "/usr/lib/cid/scripts_cid" com um "cp -rfv /usr/lib/cid/scripts_cid /mnt/.netlogon;
Por enquanto aguardarei que realize estes procedimentos, e que me dê um retorno, pois em caso de persistir o problema pensarei em possíveis novas soluções para te passar.
Grato!
[12] Comentário enviado por removido em 28/09/2014 - 22:56h
Ah! Pensei também em uma outra possibilidade que possa estar testando de imediato também!
Modifique os valores de "file_mode", e "dir_mode" na entrada referente a montagem do NETLOGON em /etc/fstab,
DE
file_mode=0775,dir_mode=0775
PARA
file_mode=0777,dir_mode=0777
Ah! Pensei também em uma outra possibilidade que possa estar testando de imediato também!
Modifique os valores de "file_mode", e "dir_mode" na entrada referente a montagem do NETLOGON em /etc/fstab,
DE
file_mode=0775,dir_mode=0775
PARA
file_mode=0777,dir_mode=0777
[13] Comentário enviado por serafim.fabio em 29/09/2014 - 20:49h
Boa noite Moraes, obrigado, não foi necessário nenhuma modificação e deu certo, é que estava testando com um usuário do grupo admin, mas com usuário comum deu certo, consegui bloquear as usb, acho que o próximo passo é aplicar a regra por grupo.
Um abraço
Boa noite Moraes, obrigado, não foi necessário nenhuma modificação e deu certo, é que estava testando com um usuário do grupo admin, mas com usuário comum deu certo, consegui bloquear as usb, acho que o próximo passo é aplicar a regra por grupo.
Um abraço
[14] Comentário enviado por removido em 30/09/2014 - 10:52h
Ufa! Que alívio! (rsrsrs)
Bom, quanto a limitação de regras por grupo no ".logon_(root).sh", ou "logon.sh" pode ser feito utilizando uma condicional (if). Geralmente eu faço:
if [ "`groups | grep -w GRUPO_DO_DOMÍNIO`" != "" ]; then
.
.
.
elif [ "`groups | grep -w OUTRO_GRUPO`" != "" ]; then
.
.
.
fi
Traduzindo:
if = Condicional "Se";
groups = Comando que lista os grupos ao qual o usuário atual pertence
grep -w GRUPO_DO_DOMÍNIO`" != "" = O grep filtrará a saída do comando "groups" verificando através da expressão regular seguinte que informa o grupo ao qual deseja verificar se este usuário possa pertencer. != "" informa se a saída for diferente de "nada" (ou seja, se o usuário de fato pertencer a tal grupo) que execute as seguintes instruções. Daí você pode colocar o comando que quiser que o usuário execute durante o logon. Lembrando que alterações ou comandos que necessite de privilégios ou o UID do root (0) no sistema devem ser então colocadas no script .logon_(root).sh.;
elif = Serve para que outras condições sejam colocadas numa mesma condicional, ou num mesmo "if". Logo se a primeira condição não for atendida (se o usuário não pertencer ao tal grupo), o shell testará a segunda condição, e assim sucessivamente até o final da condicional demarcada pelo "fi".
Boa sorte!
Valeu pelo retorno!
Ufa! Que alívio! (rsrsrs)
Bom, quanto a limitação de regras por grupo no ".logon_(root).sh", ou "logon.sh" pode ser feito utilizando uma condicional (if). Geralmente eu faço:
if [ "`groups | grep -w GRUPO_DO_DOMÍNIO`" != "" ]; then
.
.
.
elif [ "`groups | grep -w OUTRO_GRUPO`" != "" ]; then
.
.
.
fi
Traduzindo:
if = Condicional "Se";
groups = Comando que lista os grupos ao qual o usuário atual pertence
grep -w GRUPO_DO_DOMÍNIO`" != "" = O grep filtrará a saída do comando "groups" verificando através da expressão regular seguinte que informa o grupo ao qual deseja verificar se este usuário possa pertencer. != "" informa se a saída for diferente de "nada" (ou seja, se o usuário de fato pertencer a tal grupo) que execute as seguintes instruções. Daí você pode colocar o comando que quiser que o usuário execute durante o logon. Lembrando que alterações ou comandos que necessite de privilégios ou o UID do root (0) no sistema devem ser então colocadas no script .logon_(root).sh.;
elif = Serve para que outras condições sejam colocadas numa mesma condicional, ou num mesmo "if". Logo se a primeira condição não for atendida (se o usuário não pertencer ao tal grupo), o shell testará a segunda condição, e assim sucessivamente até o final da condicional demarcada pelo "fi".
Boa sorte!
Valeu pelo retorno!
[15] Comentário enviado por tjferreira em 01/03/2016 - 14:05h
Segui teu tutorial usando a versão Cid 6.7 num cliente Mint 17 e não tive sucesso nos mapeamentos. Percebi que o script fez as alterações no fstab e no rc.local mas nada de pasta mapeada.
Utilizei esses volumes no shares.xml:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/tmp/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777" />
Onde posso estar vacilando?
Valeu!
Segui teu tutorial usando a versão Cid 6.7 num cliente Mint 17 e não tive sucesso nos mapeamentos. Percebi que o script fez as alterações no fstab e no rc.local mas nada de pasta mapeada.
Utilizei esses volumes no shares.xml:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/tmp/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777" />
Onde posso estar vacilando?
Valeu!
[16] Comentário enviado por removido em 01/03/2016 - 17:23h
É provável que esteja sendo mapeado, porém os mapeamentos que não são realizados dentro de algum subdiretório no home do usuário não aparecem na estrutura de pastas do perfil do usuário do "nemo" (ou nautilus no caso do Ubuntu). Para verificar se realmente foi montado ou não execute o comando "mount" no terminal e veja na saída padrão se ele não aparece entre os volumes montados do sistema. Detalhe, não precisa ser root.
Caso realmente não esteja montando, tente acrescentando na tag volume do arquivo shares.xml o parâmetro workgroup dentre as opções deixando-o da seguinte forma:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/tmp/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777,workgroup=[NOME_DO_DOMÍNIO]" />
E para que apareça dentro do nemo você deve apontar seu mapeamento para dentro do Home do usuário da seguinte forma:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/home/%(USER)/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777,workgroup=[NOME_DO_DOMÍNIO]" />
Verifique também após logar com um usuário do domínio se o arquivo "/etc/security/pam_mount.conf.xml" está igual ao arquivo shares.xml do netlogon do seu servidor de domínio.
Caso persista o problema, ou consiga resolver com essas dicas, favor, dê um retorno!
Agradecido, abraço e boa sorte!
É provável que esteja sendo mapeado, porém os mapeamentos que não são realizados dentro de algum subdiretório no home do usuário não aparecem na estrutura de pastas do perfil do usuário do "nemo" (ou nautilus no caso do Ubuntu). Para verificar se realmente foi montado ou não execute o comando "mount" no terminal e veja na saída padrão se ele não aparece entre os volumes montados do sistema. Detalhe, não precisa ser root.
Caso realmente não esteja montando, tente acrescentando na tag volume do arquivo shares.xml o parâmetro workgroup dentre as opções deixando-o da seguinte forma:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/tmp/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777,workgroup=[NOME_DO_DOMÍNIO]" />
E para que apareça dentro do nemo você deve apontar seu mapeamento para dentro do Home do usuário da seguinte forma:
<volume icase="no" user="*" fstype="cifs" server="172.16.10.254" path="PUBLICO" mountpoint="/home/%(USER)/PUBLICO" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0777,dir_mode=0777,workgroup=[NOME_DO_DOMÍNIO]" />
Verifique também após logar com um usuário do domínio se o arquivo "/etc/security/pam_mount.conf.xml" está igual ao arquivo shares.xml do netlogon do seu servidor de domínio.
Caso persista o problema, ou consiga resolver com essas dicas, favor, dê um retorno!
Agradecido, abraço e boa sorte!
[17] Comentário enviado por tjferreira em 03/03/2016 - 13:47h
O mapeamento funcionou seguindo tuas orientações passo a passo no que diz respeito ao ponto de montagem dentro da home do usuário. Valeu Eduardo!
O mapeamento funcionou seguindo tuas orientações passo a passo no que diz respeito ao ponto de montagem dentro da home do usuário. Valeu Eduardo!
[18] Comentário enviado por tjferreira em 17/03/2016 - 15:59h
Consegui fazer o mapeamento Público perfeitamente, no mapeamento por Grupo/Setor mapeou a pasta(no caso DTI) mas aparentemente não com as permissões devidas. Por exemplo, mesmo com um usuário do grupo autorizado não consigo alterar a pasta, não tenho permissão de escrita.
Aqui a definição do volume:
<!-- TESTE 01: MAPEAMENTO GRUPO DTI-->
<volume icase="no" sgrp="DTI" fstype="cifs" server="172.16.10.254" path="DTI" mountpoint="/home/%(USER)/DTI" options="uid=%(USER),gid=%(USERUID),iocharset=utf8,file_mode=0770,dir_mode=0770, workgroup=SMB4TESTE" />
No servidor de arquivos a pasta do mapeamento está como permissão 775, tentei definir 770 mas daí nem mapeia e monta o pasta no cliente linux.
Uso servidor SMB4 e um cliente Linux Mint.
Consegui fazer o mapeamento Público perfeitamente, no mapeamento por Grupo/Setor mapeou a pasta(no caso DTI) mas aparentemente não com as permissões devidas. Por exemplo, mesmo com um usuário do grupo autorizado não consigo alterar a pasta, não tenho permissão de escrita.
Aqui a definição do volume:
<!-- TESTE 01: MAPEAMENTO GRUPO DTI-->
<volume icase="no" sgrp="DTI" fstype="cifs" server="172.16.10.254" path="DTI" mountpoint="/home/%(USER)/DTI" options="uid=%(USER),gid=%(USERUID),iocharset=utf8,file_mode=0770,dir_mode=0770, workgroup=SMB4TESTE" />
No servidor de arquivos a pasta do mapeamento está como permissão 775, tentei definir 770 mas daí nem mapeia e monta o pasta no cliente linux.
Uso servidor SMB4 e um cliente Linux Mint.
[19] Comentário enviado por removido em 17/03/2016 - 16:30h
Olá Tiago,
Pelo que entendi as informações do seu cenário são as seguintes:
Nome do Grupo: DTI
Servidor de Arquivos: 172.16.10.254
Nome do Compartilhamento: DTI
Nome do domínio: SMB4TESTE
Sendo essas as informações a tag de montagem deve ficar da seguinte forma:
<volume icase="no" sgrp="DTI" fstype="cifs" server="172.16.10.254" path="DTI" mountpoint="/home/%(USER)/DTI" options="uid=%(USER),gid=DTI,iocharset=utf8,file_mode=0770,dir_mode=0770, workgroup=SMB4TESTE" />
Perceba que eu só mudei o parâmetro "gid". Isso forçará a gravação de novos arquivos com o "gid" do grupo especificado, pois caso contrário ele poderá ser gravado com gid de um outro grupo que determinado usuário pertença e que por ventura os outros não, logo esse arquivo/diretório só poderá ser rescrito modificado pelo usuário que o criou dentro do compartilhamento.
Provavelmente alguns arquivos estão sobre as permissões de um grupo diferente do DTI dentro desse compartilhamento. Isso pode ser verificado com um "ls -la" no diretório do compartilhamento onde serão listados os arquivos com as informações, dentre outras, do usuário dono e o grupo. Constatando essa situação você deve alterar recursivamente o grupo de todos os arquivos e/ou subdiretórios desse compartilhamento com o comando "chgrp -R DTI [caminho_do_diretório]". Lembrando que os comandos devem ser executados diretamente do seu servidor de arquivos, ou seja, no sistema de arquivo local do seu servidor, e não numa estação cliente através do mapeamento desse compartilhamento nessa estação.
Outra dica é, para garantir que o usuário em questão tem realmente acesso total (leitura,escrita e execução) aos arquivos desse compartilhamento, você pode logar com esse usuário na sua estação Mint, e mapear o compartilhamento no nemo (gerenciador de arquivos do Mint, equivalente ao Nautilus do Ubuntu e outros, ou Explorer do Windows) usando "gvfs". Para isso basta digitar na barra de endereços o seguinte caminho:
smb://172.16.10.254/DTI
Devem ser solicitadas as credenciais do usuário. Logo após mapeado você testa o acesso aos arquivos do compartilhamento e verifica se condiz com as permissões dadas em seu servidor de arquivos. Se o compartilhamento não for mapeado você deve verificar se o usuário realmente faz parte do grupo em questão no seu servidor de domínio, ou se as permissões tão realmente configuradas corretamente no servidor de arquivos.
Na estação cliente também é possível verificar os grupos que o usuário logado pertence com qualquer um dos comandos abaixo:
id -Gn
groups
getent group | grep "$USER" | cut -d ":" -f 1
Até mais!
Olá Tiago,
Pelo que entendi as informações do seu cenário são as seguintes:
Nome do Grupo: DTI
Servidor de Arquivos: 172.16.10.254
Nome do Compartilhamento: DTI
Nome do domínio: SMB4TESTE
Sendo essas as informações a tag de montagem deve ficar da seguinte forma:
<volume icase="no" sgrp="DTI" fstype="cifs" server="172.16.10.254" path="DTI" mountpoint="/home/%(USER)/DTI" options="uid=%(USER),gid=DTI,iocharset=utf8,file_mode=0770,dir_mode=0770, workgroup=SMB4TESTE" />
Perceba que eu só mudei o parâmetro "gid". Isso forçará a gravação de novos arquivos com o "gid" do grupo especificado, pois caso contrário ele poderá ser gravado com gid de um outro grupo que determinado usuário pertença e que por ventura os outros não, logo esse arquivo/diretório só poderá ser rescrito modificado pelo usuário que o criou dentro do compartilhamento.
Provavelmente alguns arquivos estão sobre as permissões de um grupo diferente do DTI dentro desse compartilhamento. Isso pode ser verificado com um "ls -la" no diretório do compartilhamento onde serão listados os arquivos com as informações, dentre outras, do usuário dono e o grupo. Constatando essa situação você deve alterar recursivamente o grupo de todos os arquivos e/ou subdiretórios desse compartilhamento com o comando "chgrp -R DTI [caminho_do_diretório]". Lembrando que os comandos devem ser executados diretamente do seu servidor de arquivos, ou seja, no sistema de arquivo local do seu servidor, e não numa estação cliente através do mapeamento desse compartilhamento nessa estação.
Outra dica é, para garantir que o usuário em questão tem realmente acesso total (leitura,escrita e execução) aos arquivos desse compartilhamento, você pode logar com esse usuário na sua estação Mint, e mapear o compartilhamento no nemo (gerenciador de arquivos do Mint, equivalente ao Nautilus do Ubuntu e outros, ou Explorer do Windows) usando "gvfs". Para isso basta digitar na barra de endereços o seguinte caminho:
smb://172.16.10.254/DTI
Devem ser solicitadas as credenciais do usuário. Logo após mapeado você testa o acesso aos arquivos do compartilhamento e verifica se condiz com as permissões dadas em seu servidor de arquivos. Se o compartilhamento não for mapeado você deve verificar se o usuário realmente faz parte do grupo em questão no seu servidor de domínio, ou se as permissões tão realmente configuradas corretamente no servidor de arquivos.
Na estação cliente também é possível verificar os grupos que o usuário logado pertence com qualquer um dos comandos abaixo:
id -Gn
groups
getent group | grep "$USER" | cut -d ":" -f 1
Até mais!
[20] Comentário enviado por aguinaldo_sis em 30/03/2016 - 16:49h
Boa tarde nobre colega, primeiramente quero parabeniza-lo pelo ótimo artigo, esta sendo muito útil.
Estou na seguinte situação, tenho alguns grupos aqui que devem carregar mais de uma unidade, quando coloco os trechos que deveriam subir as unidades, somente a primeira sobre, por exemplo:
<!-- Carrega o compartilhamento do grupo Dp (SPC) (DPessoal)-->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="DPessoal" mountpoint="/home/%(USER)/DPessoal" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0770,dir_mode=0770" />
<!-- Carrega o compartilhamento do grupo Dp (SPC) (Impressao)-->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="Impressao" mountpoint="/home/%(USER)/Impressao" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0770,dir_mode=0770" />
Quando coloco desse jeito, eu esperava que aparecesse duas unidades, uma com o nome de Dpessoal e outra com o nome de Impressao, porém só aparece a DPessal, seu eu mudar a ordem e colocar a Impressao primeiro, aparece só ela.
Saberia me dizer porque acontece isso ou se tem uma outra forma de resolver isso?
Grato desde já pela atenção.
Boa tarde nobre colega, primeiramente quero parabeniza-lo pelo ótimo artigo, esta sendo muito útil.
Estou na seguinte situação, tenho alguns grupos aqui que devem carregar mais de uma unidade, quando coloco os trechos que deveriam subir as unidades, somente a primeira sobre, por exemplo:
<!-- Carrega o compartilhamento do grupo Dp (SPC) (DPessoal)-->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="DPessoal" mountpoint="/home/%(USER)/DPessoal" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0770,dir_mode=0770" />
<!-- Carrega o compartilhamento do grupo Dp (SPC) (Impressao)-->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="Impressao" mountpoint="/home/%(USER)/Impressao" options="uid=%(USERUID),gid=%(USERGID),iocharset=utf8,file_mode=0770,dir_mode=0770" />
Quando coloco desse jeito, eu esperava que aparecesse duas unidades, uma com o nome de Dpessoal e outra com o nome de Impressao, porém só aparece a DPessal, seu eu mudar a ordem e colocar a Impressao primeiro, aparece só ela.
Saberia me dizer porque acontece isso ou se tem uma outra forma de resolver isso?
Grato desde já pela atenção.
[21] Comentário enviado por removido em 30/03/2016 - 18:40h
Olá caro Aguinaldo!
Fico muito grato pelo prestígio!
Refaça suas definições de mapeamentos da seguinte forma:
<!-- Grupo: Dp (SPC) / Compartilhamento: DPessoal -->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="DPessoal" mountpoint="/home/%(USER)/DPessoal" options="uid=%(USER),gid=Dp (SPC),iocharset=utf8,file_mode=0770,dir_mode=0770"/>
<!-- Grupo: Dp (SPC) / Compartilhamento: DPessoal -->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="Impressao" mountpoint="/home/%(USER)/Impressao" options="uid=%(USER),gid=Dp (SPC),iocharset=utf8,file_mode=0770,dir_mode=0770"/>
Teste e me dê um retorno. Caso não dê certo habilite o debug do pam_mount na tag: "<debug enable="1"/>", e após logar com um usuário desse grupo na estação, recupere no log de autenticação em "/var/log/auth.log" a parte que corresponde a autenticação desse usuário e poste aqui para eu analisar.
Abraço e boa sorte!
Olá caro Aguinaldo!
Fico muito grato pelo prestígio!
Refaça suas definições de mapeamentos da seguinte forma:
<!-- Grupo: Dp (SPC) / Compartilhamento: DPessoal -->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="DPessoal" mountpoint="/home/%(USER)/DPessoal" options="uid=%(USER),gid=Dp (SPC),iocharset=utf8,file_mode=0770,dir_mode=0770"/>
<!-- Grupo: Dp (SPC) / Compartilhamento: DPessoal -->
<volume icase="no" sgrp="Dp (SPC)" fstype="cifs" server="192.168.1.10" path="Impressao" mountpoint="/home/%(USER)/Impressao" options="uid=%(USER),gid=Dp (SPC),iocharset=utf8,file_mode=0770,dir_mode=0770"/>
Teste e me dê um retorno. Caso não dê certo habilite o debug do pam_mount na tag: "<debug enable="1"/>", e após logar com um usuário desse grupo na estação, recupere no log de autenticação em "/var/log/auth.log" a parte que corresponde a autenticação desse usuário e poste aqui para eu analisar.
Abraço e boa sorte!
[22] Comentário enviado por andreicp44 em 11/04/2016 - 16:42h
Boa tarde, minha empresa começou a utilizar linux no server Windows recentemente e nos ocorreu o seguinte problema:
Fora feita a configuração do pam_mount pra montar várias pastas conforme as permissões de usuário, até aí tudo ok. Ele monta os diretórios, concede as permissões de acordo com o AD, porém as pastas das quais este usuário não tem acesso também estão aparecendo junto com as permitidas.
Por exemplo: o código tem o mapeamento de 10 pastas, o usuário só tem acesso a 3 delas. Porém quando ele faz o logon, as outras 7 pastas aparecem no meio sem nada dentro, como pastas vazias e sem permissões de uso dentro delas.
Gostaria de saber como fazer pra essas pastinhas extras não aparecerem pros usuários que não podem ter acesso a elas.
Segue a configuração que utilizo para todas elas:
<!-- INFORMAÇÕES GERENCIAIS -->
<volume options="nodev,nosuid,dir_mode=0700"
fstype="cifs"
server="192.168.0.253"
path="inf_gerenciais$"
mountpoint="/home/INTRANET/%(USER)/PASTA_REDE/inf_gerencias"
pgrp="domain users"
/>
Boa tarde, minha empresa começou a utilizar linux no server Windows recentemente e nos ocorreu o seguinte problema:
Fora feita a configuração do pam_mount pra montar várias pastas conforme as permissões de usuário, até aí tudo ok. Ele monta os diretórios, concede as permissões de acordo com o AD, porém as pastas das quais este usuário não tem acesso também estão aparecendo junto com as permitidas.
Por exemplo: o código tem o mapeamento de 10 pastas, o usuário só tem acesso a 3 delas. Porém quando ele faz o logon, as outras 7 pastas aparecem no meio sem nada dentro, como pastas vazias e sem permissões de uso dentro delas.
Gostaria de saber como fazer pra essas pastinhas extras não aparecerem pros usuários que não podem ter acesso a elas.
Segue a configuração que utilizo para todas elas:
<!-- INFORMAÇÕES GERENCIAIS -->
<volume options="nodev,nosuid,dir_mode=0700"
fstype="cifs"
server="192.168.0.253"
path="inf_gerenciais$"
mountpoint="/home/INTRANET/%(USER)/PASTA_REDE/inf_gerencias"
pgrp="domain users"
/>
[23] Comentário enviado por removido em 12/04/2016 - 09:57h
Se todas as tags de mapeamento tiver como parâmetro pgrp="domain users", todos os mapeamentos serão mapeados por qualquer usuário, pois por padrão todos os usuários pertence ao grupo "domain users".
O mais correto seria você criar grupos distintos para compartilhamentos, mudar o parâmetro pgrp para sgrp=[nome_do_grupo] e atribuir os usuários que terão acesso a determinado compartilhamento ao respectivo grupo.
Se todas as tags de mapeamento tiver como parâmetro pgrp="domain users", todos os mapeamentos serão mapeados por qualquer usuário, pois por padrão todos os usuários pertence ao grupo "domain users".
O mais correto seria você criar grupos distintos para compartilhamentos, mudar o parâmetro pgrp para sgrp=[nome_do_grupo] e atribuir os usuários que terão acesso a determinado compartilhamento ao respectivo grupo.
[24] Comentário enviado por andreicp44 em 12/04/2016 - 14:15h
Puts, que erro bobo da minha parte. Valeu pela ajuda, colega, agora está rodando filé.
Puts, que erro bobo da minha parte. Valeu pela ajuda, colega, agora está rodando filé.
[25] Comentário enviado por removido em 13/04/2016 - 15:29h
Ok meu caro! Acontece...
Eu que agradeço pelo retorno, e disponha sempre que precisar!
Ok meu caro! Acontece...
Eu que agradeço pelo retorno, e disponha sempre que precisar!
[26] Comentário enviado por cmah em 15/04/2016 - 13:05h
Muito obrigado pelo software e artigos, cinco estrelas.
Tudo a funcionar com AD e pastas partilhadas em Samba 4.2 e Desktop com Mint 17.3.
Um abraço dos Açores, Portugal.
Muito obrigado pelo software e artigos, cinco estrelas.
Tudo a funcionar com AD e pastas partilhadas em Samba 4.2 e Desktop com Mint 17.3.
Um abraço dos Açores, Portugal.
[27] Comentário enviado por removido em 15/04/2016 - 23:46h
Os agradecimentos são todos meus meu caro, pelo prestígio e apoio!
Abraços!
Os agradecimentos são todos meus meu caro, pelo prestígio e apoio!
Abraços!
[28] Comentário enviado por cmah em 06/05/2016 - 08:24h
Olá novamente!
Com o objetivo de ter UIDs e GIDs iguais para o mesmo utilizador em todos os desktops Linux ligados ao nosso domínio Samba4 fizemos:
- Ligar o RFC2307 no controlador de domínio.
- Instalar as NIS extensions no controlador de domínio.
(Seguimos as instruções em https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD)
Depois alterei o smb.conf nos desktops Linux para ficar deste modo:
# Modified by cid
# By Eduardo Moraes <emoraes25@gmail.com>
# -------------------------------------------------
[global]
workgroup = NOSSODOMINIO
realm = NOSSODOMINIO.PT
security = ADS
winbind reconnect delay = 0
winbind refresh tickets = Yes
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind offline logon = Yes
idmap config *:backend = tdb
idmap config *:range = 2000-9999
idmap config NOSSODOMINIO:backend = ad
idmap config NOSSODOMINIO:schema_mode = rfc2307
idmap config NOSSODOMINIO:range = 10000-99999
winbind nss info = rfc2307
----------------------------------------------------------------------------
Funcionou, o mesmo utilizador entrando em computadores diferentes fica sempre com o mesmo UID e GID.
Deixo aqui esta informação por dois motivos:
- Para quem quiser fazer esta alteração.
- Para perguntar ao Eduardo se ele vê algum possível problema com as alterações que fiz (algum conflito com outras partes dos scripts dele).
E já agora, seria interessante numa próxima versão do CID ter a opção de usar o RFC2307 :)
Abraço!
Olá novamente!
Com o objetivo de ter UIDs e GIDs iguais para o mesmo utilizador em todos os desktops Linux ligados ao nosso domínio Samba4 fizemos:
- Ligar o RFC2307 no controlador de domínio.
- Instalar as NIS extensions no controlador de domínio.
(Seguimos as instruções em https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD)
Depois alterei o smb.conf nos desktops Linux para ficar deste modo:
# Modified by cid
# By Eduardo Moraes <emoraes25@gmail.com>
# -------------------------------------------------
[global]
workgroup = NOSSODOMINIO
realm = NOSSODOMINIO.PT
security = ADS
winbind reconnect delay = 0
winbind refresh tickets = Yes
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind offline logon = Yes
idmap config *:backend = tdb
idmap config *:range = 2000-9999
idmap config NOSSODOMINIO:backend = ad
idmap config NOSSODOMINIO:schema_mode = rfc2307
idmap config NOSSODOMINIO:range = 10000-99999
winbind nss info = rfc2307
----------------------------------------------------------------------------
Funcionou, o mesmo utilizador entrando em computadores diferentes fica sempre com o mesmo UID e GID.
Deixo aqui esta informação por dois motivos:
- Para quem quiser fazer esta alteração.
- Para perguntar ao Eduardo se ele vê algum possível problema com as alterações que fiz (algum conflito com outras partes dos scripts dele).
E já agora, seria interessante numa próxima versão do CID ter a opção de usar o RFC2307 :)
Abraço!
[29] Comentário enviado por removido em 06/05/2016 - 18:51h
Olá meu caro!
Muito obrigado pela contribuição!
Já estou há algumas semanas trabalhando numa nova versão do cid, onde inclusive estou trazendo essa filosofia de permitir ao administrador definir configurações diferentes para o script de ingresso da estação num domínio.
Já havia conhecido a solução há um bom tempo atrás, antes mesmo de começar a desenvolver o cid, tanto que não me lembro se já tinha padronização para isso na época... achei interessante, no entanto descartei completamente a possibilidade de integrar isso ao cid, pois a ideia era criar algo que não obrigasse qualquer tipo de alteração no servidor de domínio, que a solução fosse totalmente autônoma, e se assemelhasse ao máximo possível da forma como as estações Windows funcionam dentro deste contexto de domínio, justamente porque tinha receio das pessoas descartarem de cara a solução por ter a necessidade de fazer qualquer ajuste adicional no servidor.
Mas agora o cenário é outro, a minha forma de pensar também mudou, e acho que com essa nova filosofia onde o software dá opção do administrador escolher entre uma forma de ingresso padrão, sem exigir quaisquer esforço ou conhecimento avançado, e uma outra forma onde o administrador molde essa integração de acordo a sua necessidade e/ou seu ambiente, só faz enriquecer ainda mais a aplicação. Com isso, o quero dizer meu caro é sim... com certeza eu vou estudar e implementar a solução na próxima versão do cid. Versão essa que já estava pronta, até agora, mas que eu ainda não disponibilizei por conta de um bug nas novas versões do pacote samba (2:4.3.8+dfsg & 2:4.3.9+dfsg), cujo Ubuntu 16.04 tem em disponibilidade no seu repositório, que dentre outros, não está montando volumes via pam_mount com diretivas de controle de grupo secundário (<sgrp>).
Vou tentar entrar em contato com os mantenedores de ambos os pacotes para tentar obter uma solução. Por uma lado foi bom, porque já posso aproveitar para implementar a solução citada pelo nobre amigo na nova versão, por outro é ruim, pois a aplicação depende da resolução do bug dessas aplicações para poder funcionar de forma estável, sendo que já saiu uma nova versão do pacote samba, porém este bug ao qual me refiro não foi corrigido.
Abraço!
Olá meu caro!
Muito obrigado pela contribuição!
Já estou há algumas semanas trabalhando numa nova versão do cid, onde inclusive estou trazendo essa filosofia de permitir ao administrador definir configurações diferentes para o script de ingresso da estação num domínio.
Já havia conhecido a solução há um bom tempo atrás, antes mesmo de começar a desenvolver o cid, tanto que não me lembro se já tinha padronização para isso na época... achei interessante, no entanto descartei completamente a possibilidade de integrar isso ao cid, pois a ideia era criar algo que não obrigasse qualquer tipo de alteração no servidor de domínio, que a solução fosse totalmente autônoma, e se assemelhasse ao máximo possível da forma como as estações Windows funcionam dentro deste contexto de domínio, justamente porque tinha receio das pessoas descartarem de cara a solução por ter a necessidade de fazer qualquer ajuste adicional no servidor.
Mas agora o cenário é outro, a minha forma de pensar também mudou, e acho que com essa nova filosofia onde o software dá opção do administrador escolher entre uma forma de ingresso padrão, sem exigir quaisquer esforço ou conhecimento avançado, e uma outra forma onde o administrador molde essa integração de acordo a sua necessidade e/ou seu ambiente, só faz enriquecer ainda mais a aplicação. Com isso, o quero dizer meu caro é sim... com certeza eu vou estudar e implementar a solução na próxima versão do cid. Versão essa que já estava pronta, até agora, mas que eu ainda não disponibilizei por conta de um bug nas novas versões do pacote samba (2:4.3.8+dfsg & 2:4.3.9+dfsg), cujo Ubuntu 16.04 tem em disponibilidade no seu repositório, que dentre outros, não está montando volumes via pam_mount com diretivas de controle de grupo secundário (<sgrp>).
Vou tentar entrar em contato com os mantenedores de ambos os pacotes para tentar obter uma solução. Por uma lado foi bom, porque já posso aproveitar para implementar a solução citada pelo nobre amigo na nova versão, por outro é ruim, pois a aplicação depende da resolução do bug dessas aplicações para poder funcionar de forma estável, sendo que já saiu uma nova versão do pacote samba, porém este bug ao qual me refiro não foi corrigido.
Abraço!
[30] Comentário enviado por cmah em 10/05/2016 - 13:03h
Nós estamos no Mint 17.3 que usa os repositórios do Ubuntu (14.04.4) e também já atualizou para o 2:4.3.9+dfsg. Os shares gerais continuam a montar mas realmente os sgrp deixaram de funcionar.
Temos dois PCs em testes mas são para utilizadores que apenas usam o share geral.
Mas de futuro, quando tivermos outros utilizadores no Mint, vamos ter que testar bem os updates antes de os passar para todas as máquinas.
Reportei o bug em https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1580237
Foi o meu primeiro bug report, espero ser suficiente a informação que disponibilizei.
O Eduardo (e outros utilizadores do CID) podem ir ao link acima e reportar que também estão afetados de modo a dar mais visibilidade ao bug.
Abraço!
Nós estamos no Mint 17.3 que usa os repositórios do Ubuntu (14.04.4) e também já atualizou para o 2:4.3.9+dfsg. Os shares gerais continuam a montar mas realmente os sgrp deixaram de funcionar.
Temos dois PCs em testes mas são para utilizadores que apenas usam o share geral.
Mas de futuro, quando tivermos outros utilizadores no Mint, vamos ter que testar bem os updates antes de os passar para todas as máquinas.
Reportei o bug em https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1580237
Foi o meu primeiro bug report, espero ser suficiente a informação que disponibilizei.
O Eduardo (e outros utilizadores do CID) podem ir ao link acima e reportar que também estão afetados de modo a dar mais visibilidade ao bug.
Abraço!
[31] Comentário enviado por joaoafricano em 29/05/2016 - 16:44h
Otimo trabalho Eduardo.
Só tenho uma questão que não estou conseguindo resolver.
Em um cliente que esta passando algumas estações de windows para Linux e no caso o Ubuntu 16 Lts, tem um compartilhamento que alguem com conhecimentos avançados de informatica simplesmente compartilhou o diretório, exatamente com o nome do diretório que no caso é "IMAGENS DIGITALIZADAS" com o espaço, e com isso não estou copnseguindo montar esse diretório. Tem alguam forma de contornar isso ou vou ter que renomear o compartilhamento para poder mountar esse compartilhamento?
Desde já agradeço a sua atenção e continue o bom trabalho.
Otimo trabalho Eduardo.
Só tenho uma questão que não estou conseguindo resolver.
Em um cliente que esta passando algumas estações de windows para Linux e no caso o Ubuntu 16 Lts, tem um compartilhamento que alguem com conhecimentos avançados de informatica simplesmente compartilhou o diretório, exatamente com o nome do diretório que no caso é "IMAGENS DIGITALIZADAS" com o espaço, e com isso não estou copnseguindo montar esse diretório. Tem alguam forma de contornar isso ou vou ter que renomear o compartilhamento para poder mountar esse compartilhamento?
Desde já agradeço a sua atenção e continue o bom trabalho.
[32] Comentário enviado por removido em 29/05/2016 - 17:28h
Bom... Normalmente é possível sim montar esse compartilhamento desde que ele esteja exatamente da forma como você citou, ou seja, entre aspas (" "). No entanto, se o problema ao qual você se refere é na montagem automática via "pam_mount" com o cid, você deve verificar se o compartilhamento está com as devidas permissões de acesso para o grupo primário dos usuários do domínio, pois pode ser que o problema seja o fato desse "bug" novo nos novos pacotes do samba disponíveis nos repositórios do Ubuntu versão 14.04 até a atual 16.04 que não está mapeando compartilhamentos cuja permissão para acesso seja de um grupo secundário do usuário no domínio, como já foi citado nos comentários anteriores acima.
Tente fazer o teste montando o compartilhamento da forma que está manualmente no terminal com o comando "mount", e se obtiver êxito, observe as questões de permissão.
Uma outra dica é, já que está usando uma estação Ubuntu para fazer esse compartilhamento através do samba, nas opções de montagem, tanto no teste, quanto na própria configuração do arquivo shares.xml para o pam_mount, utilize o parâmetro "workgroup=[NOME_DO_DOMÍNIO]".
Desde já agradeço pelo prestígio e apoio, e fico a disposição sempre que precisar!
Abraço!
Bom... Normalmente é possível sim montar esse compartilhamento desde que ele esteja exatamente da forma como você citou, ou seja, entre aspas (" "). No entanto, se o problema ao qual você se refere é na montagem automática via "pam_mount" com o cid, você deve verificar se o compartilhamento está com as devidas permissões de acesso para o grupo primário dos usuários do domínio, pois pode ser que o problema seja o fato desse "bug" novo nos novos pacotes do samba disponíveis nos repositórios do Ubuntu versão 14.04 até a atual 16.04 que não está mapeando compartilhamentos cuja permissão para acesso seja de um grupo secundário do usuário no domínio, como já foi citado nos comentários anteriores acima.
Tente fazer o teste montando o compartilhamento da forma que está manualmente no terminal com o comando "mount", e se obtiver êxito, observe as questões de permissão.
Uma outra dica é, já que está usando uma estação Ubuntu para fazer esse compartilhamento através do samba, nas opções de montagem, tanto no teste, quanto na própria configuração do arquivo shares.xml para o pam_mount, utilize o parâmetro "workgroup=[NOME_DO_DOMÍNIO]".
Desde já agradeço pelo prestígio e apoio, e fico a disposição sempre que precisar!
Abraço!
[33] Comentário enviado por tiago2001 em 05/06/2016 - 14:21h
Para quem está enfrentando o problema de não conseguir mapear, no smb.conf, utilize a seguinte linha:
winbind expand groups = 1
Reinicie a máquina e voltará a funcionar.
Para quem está enfrentando o problema de não conseguir mapear, no smb.conf, utilize a seguinte linha:
winbind expand groups = 1
Reinicie a máquina e voltará a funcionar.
[34] Comentário enviado por removido em 05/06/2016 - 23:14h
Confirmo a informação do amigo "tiago2001".
Segundo informações oficiais de atualizações do samba 4 (https://wiki.samba.org/index.php/Samba_4.2_Features_added/changed#Winbindd.2FNetlogon_improvements) o parâmetro que nas versões anteriores tinha como padrão o valor 1 (winbind expand groups = 1) agora este valor é 0 (winbind expand groups = 0);
Esta atualização já está sendo implementada no projeto "cid 7.0".
Muito agradecido Tiago!
Confirmo a informação do amigo "tiago2001".
Segundo informações oficiais de atualizações do samba 4 (https://wiki.samba.org/index.php/Samba_4.2_Features_added/changed#Winbindd.2FNetlogon_improvements) o parâmetro que nas versões anteriores tinha como padrão o valor 1 (winbind expand groups = 1) agora este valor é 0 (winbind expand groups = 0);
Esta atualização já está sendo implementada no projeto "cid 7.0".
Muito agradecido Tiago!
[35] Comentário enviado por tiago2001 em 06/06/2016 - 16:23h
Utilizo o seguinte cenário:
PDC: Windows Server 2008
Servidor de Arquivos: Debian
Vou começar a utilizar o MINT 17.3 e está configurado da seguinte maneira o pam_mount.conf.xml:
<volume icase="no" sgrp="ti" fstype="cifs" server="192.168.1.6" path="ti" mountpoint="/home/%(USER)/TI options="uid=%(USER),gid=ti,iocharset=utf8, file_mode=0770,dir_mode=0770"
Problemas:
- 1º Não está funcionando o file_mode e o dir_mode, fica como 0750 quando eu crio algum diretório novo.
- 2º Toda configuração que faço no pam_mount.conf.xml ele volta a configuração original, preciso então toda vez que for alterar dar um chattr, se eu esquecer de travar eu perco todas minhas configurações.
Agradeço
Utilizo o seguinte cenário:
PDC: Windows Server 2008
Servidor de Arquivos: Debian
Vou começar a utilizar o MINT 17.3 e está configurado da seguinte maneira o pam_mount.conf.xml:
<volume icase="no" sgrp="ti" fstype="cifs" server="192.168.1.6" path="ti" mountpoint="/home/%(USER)/TI options="uid=%(USER),gid=ti,iocharset=utf8, file_mode=0770,dir_mode=0770"
Problemas:
- 1º Não está funcionando o file_mode e o dir_mode, fica como 0750 quando eu crio algum diretório novo.
- 2º Toda configuração que faço no pam_mount.conf.xml ele volta a configuração original, preciso então toda vez que for alterar dar um chattr, se eu esquecer de travar eu perco todas minhas configurações.
Agradeço
[36] Comentário enviado por franzegurgel em 08/06/2016 - 11:31h
Bom dia,
Utilizei o sistema CID no ubuntu 14.04 e loga perfeito no AD 2008.
Só que não estou conseguindo criar um usuário padrão, pois antes isso eu conseguia no Ubuntu 12.04 da seguinte maneira:
Inseria o ubuntu no domínio windows 2008, depois logava com usuário do AD. Depois eu colocava um papel de parede padrão para todos os usuários, criava atalhos dos aplicativos na área de trabalho e bloqueava alguns programas para nenhum usuário desconfigurar o sistema. Instalava o gnome tweak e o ubuntu ficava com a cara do windows 7.
Logo apos copiava toda essa configuração do usuário do AD logado no ubuntu e colava no /skel.
A partir dai, todo login com usuário do AD no ubuntu carregava todas as configurações e aparências
do usuário padrão.
Mas infelizmente copio toda configuração para /skel e não replica para demais usuários.
Você sabe alguma dica?
Aguardo
Bom dia,
Utilizei o sistema CID no ubuntu 14.04 e loga perfeito no AD 2008.
Só que não estou conseguindo criar um usuário padrão, pois antes isso eu conseguia no Ubuntu 12.04 da seguinte maneira:
Inseria o ubuntu no domínio windows 2008, depois logava com usuário do AD. Depois eu colocava um papel de parede padrão para todos os usuários, criava atalhos dos aplicativos na área de trabalho e bloqueava alguns programas para nenhum usuário desconfigurar o sistema. Instalava o gnome tweak e o ubuntu ficava com a cara do windows 7.
Logo apos copiava toda essa configuração do usuário do AD logado no ubuntu e colava no /skel.
A partir dai, todo login com usuário do AD no ubuntu carregava todas as configurações e aparências
do usuário padrão.
Mas infelizmente copio toda configuração para /skel e não replica para demais usuários.
Você sabe alguma dica?
Aguardo
[37] Comentário enviado por removido em 14/06/2016 - 20:27h
Olá meu caro!
Primeiramente gostaria de pedir desculpa pela demora no retorno. Estive muito ocupado os últimos dias, mas espero que ainda possa ser útil.
Eu queria saber de você se não está replicando por conta dos arquivos do usuário padrão não está sendo copiado do /etc/skel para o home dos demais usuários ou se copia, mas não surte efeito?
Se não estiver copiando, você pode tentar colocar a pasta de arquivos do usuário padrão no compartilhamento NETLOGON do seu servidor de domínio, e colocar no script de logon "logon.sh" que fica na pasta "scripts_cid" deste compartilhamento um comando para copiar automaticamente essa pasta para o home dos usuários durante o logon:
Comando: cp -rfv $NETLOGON/[pasta_de_configurações_do_usuário_padrão] $HOME/
Obs: A variável NETLOGON só funciona na versão 7.0 do cid, e a variável HOME substitui o diretório home do usuário.
Não tenho certeza, mas acho também que no Ubuntu 14.04 as configurações do perfil do usuário não são mais armazenadas em arquivos, e sim no backend Dconf (https://wiki.gnome.org/Projects/dconf). Para configurá-lo você pode utilizar dentro dos scritpts de logon o "gsettings", que é um utilitário de linha de comando que altera o valor das chaves das propriedades configuráveis de cada esquema padrão ou criados no Dconf. Para ter uma visão melhor dos esquemas, chaves, e valores do Dconf você pode utilizar o Dconf-editor, que é uma espécie de Front-end em modo gráfico que lista e permite alterar também essas configurações. Normalmente o dconf-editor é instalado automaticamente quando o cid é instalado via terminal com o script "INSTALL.sh"
Olá meu caro!
Primeiramente gostaria de pedir desculpa pela demora no retorno. Estive muito ocupado os últimos dias, mas espero que ainda possa ser útil.
Eu queria saber de você se não está replicando por conta dos arquivos do usuário padrão não está sendo copiado do /etc/skel para o home dos demais usuários ou se copia, mas não surte efeito?
Se não estiver copiando, você pode tentar colocar a pasta de arquivos do usuário padrão no compartilhamento NETLOGON do seu servidor de domínio, e colocar no script de logon "logon.sh" que fica na pasta "scripts_cid" deste compartilhamento um comando para copiar automaticamente essa pasta para o home dos usuários durante o logon:
Comando: cp -rfv $NETLOGON/[pasta_de_configurações_do_usuário_padrão] $HOME/
Obs: A variável NETLOGON só funciona na versão 7.0 do cid, e a variável HOME substitui o diretório home do usuário.
Não tenho certeza, mas acho também que no Ubuntu 14.04 as configurações do perfil do usuário não são mais armazenadas em arquivos, e sim no backend Dconf (https://wiki.gnome.org/Projects/dconf). Para configurá-lo você pode utilizar dentro dos scritpts de logon o "gsettings", que é um utilitário de linha de comando que altera o valor das chaves das propriedades configuráveis de cada esquema padrão ou criados no Dconf. Para ter uma visão melhor dos esquemas, chaves, e valores do Dconf você pode utilizar o Dconf-editor, que é uma espécie de Front-end em modo gráfico que lista e permite alterar também essas configurações. Normalmente o dconf-editor é instalado automaticamente quando o cid é instalado via terminal com o script "INSTALL.sh"
[38] Comentário enviado por removido em 14/06/2016 - 20:37h
Aviso!
A nova versão do cid (7.0) já foi disponibilizada em https://sourceforge.net/projects/c-i-d/. Nessa versão, além de melhorias nas funcionalidades já existentes, uma série de novas funcionalidades foram implementadas.
Vale a pena conferir a documentação, pois essa trás uma melhor visão dessas funcionalidades, bem como alguns exemplos e dicas interessantes.
Link da documentação: https://sourceforge.net/projects/c-i-d/files/Documentacao/UserManual.pdf/download
Aviso!
A nova versão do cid (7.0) já foi disponibilizada em https://sourceforge.net/projects/c-i-d/. Nessa versão, além de melhorias nas funcionalidades já existentes, uma série de novas funcionalidades foram implementadas.
Vale a pena conferir a documentação, pois essa trás uma melhor visão dessas funcionalidades, bem como alguns exemplos e dicas interessantes.
Link da documentação: https://sourceforge.net/projects/c-i-d/files/Documentacao/UserManual.pdf/download
[39] Comentário enviado por tiago2001 em 21/06/2016 - 15:07h
Estou utilizando o Lubuntu 16.04, as pastas compartilhadas as vezes não sobem.
Quando tem um outro usuário já logado não tem jeito, as pastas do usuário seguinte não funciona de jeito nenhum.
Alguma solução?
Obrigado
Estou utilizando o Lubuntu 16.04, as pastas compartilhadas as vezes não sobem.
Quando tem um outro usuário já logado não tem jeito, as pastas do usuário seguinte não funciona de jeito nenhum.
Alguma solução?
Obrigado
[40] Comentário enviado por removido em 21/06/2016 - 15:48h
Na verdade Tiago, quando há duas seções simultâneas em q ambos os usuários mapeiam os mesmos compartimentos, somente no primeiro que esses mapeamentos são exibidos como unidades de rede pelo gerenciador de arquivos (nautilus, por exemplo), na seção do segundo usuário em diante realmente ñ mostra, mas o mapeamento é feito, tanto que se vc acessar o ponto de montagem no perfil desse usuário verá q os arquivos compartilhados estarão lá. Pode conferir também com o comando mount no terminal desse usuário. Esse problema parece ser uma limitação dos próprios gerenciadores de arquivos do Linux. No Nemo, por exemplo, também ocorre. Infelizmente ñ sei se existe solução ou se existe uma configuração específica q resolva, mas pelo menos os mapeamentos são sim realizados.
Na verdade Tiago, quando há duas seções simultâneas em q ambos os usuários mapeiam os mesmos compartimentos, somente no primeiro que esses mapeamentos são exibidos como unidades de rede pelo gerenciador de arquivos (nautilus, por exemplo), na seção do segundo usuário em diante realmente ñ mostra, mas o mapeamento é feito, tanto que se vc acessar o ponto de montagem no perfil desse usuário verá q os arquivos compartilhados estarão lá. Pode conferir também com o comando mount no terminal desse usuário. Esse problema parece ser uma limitação dos próprios gerenciadores de arquivos do Linux. No Nemo, por exemplo, também ocorre. Infelizmente ñ sei se existe solução ou se existe uma configuração específica q resolva, mas pelo menos os mapeamentos são sim realizados.
[41] Comentário enviado por rodrigotn em 05/10/2016 - 14:30h
Boa tarde!
Antes de mais nada, é preciso lhe parabenizar pelo artigo e pela iniciativa. Parabéns!
Estou começando a descobrir agora esse mundo Linux e me deparei com a necessidade em ingressar máquinas com Ubuntu em ambiente com AD.
Meu cenário:
- Active Directory e Domain Controler com Windows Server 2008 R2
- Ubuntu 16.04
- CiD 7.1
O CiD é instalado sem nenhum erro, conforme o manual. É possível efetuar login com usuários do domínio sem nenhum problema também - funciona bem!
Minha dificuldade começa quando tento mapear unidades públicas de rede e as pastas particulares do usuário.
Notei que a pasta "scripts_cid" não foi criada automaticamente na pasta netlogon do DC, mas colocando manualmente, percebo que a estação de trabalho irá importar esse arquivo, e irá sobrescrever o arquivo xml de configuração do pam_mount (/etc/security/pam_mount.conf.xml).
Entretanto, não acontece a situação abaixo (que você comentou no início dos comentários):
"
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
"
Estes arquivos não foram alterados, então alteramos manualmente, mas sem sucesso também.
Tem mais alguma dica, algum detalhe que passou despercebido?
O meu muito obrigado,
Rodrigo Toledo
Boa tarde!
Antes de mais nada, é preciso lhe parabenizar pelo artigo e pela iniciativa. Parabéns!
Estou começando a descobrir agora esse mundo Linux e me deparei com a necessidade em ingressar máquinas com Ubuntu em ambiente com AD.
Meu cenário:
- Active Directory e Domain Controler com Windows Server 2008 R2
- Ubuntu 16.04
- CiD 7.1
O CiD é instalado sem nenhum erro, conforme o manual. É possível efetuar login com usuários do domínio sem nenhum problema também - funciona bem!
Minha dificuldade começa quando tento mapear unidades públicas de rede e as pastas particulares do usuário.
Notei que a pasta "scripts_cid" não foi criada automaticamente na pasta netlogon do DC, mas colocando manualmente, percebo que a estação de trabalho irá importar esse arquivo, e irá sobrescrever o arquivo xml de configuração do pam_mount (/etc/security/pam_mount.conf.xml).
Entretanto, não acontece a situação abaixo (que você comentou no início dos comentários):
"
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
"
Estes arquivos não foram alterados, então alteramos manualmente, mas sem sucesso também.
Tem mais alguma dica, algum detalhe que passou despercebido?
O meu muito obrigado,
Rodrigo Toledo
[42] Comentário enviado por removido em 05/10/2016 - 17:28h
[41] Comentário enviado por rodrigotn em 05/10/2016 - 14:30h
Boa tarde!
Antes de mais nada, é preciso lhe parabenizar pelo artigo e pela iniciativa. Parabéns!
Estou começando a descobrir agora esse mundo Linux e me deparei com a necessidade em ingressar máquinas com Ubuntu em ambiente com AD.
Meu cenário:
- Active Directory e Domain Controler com Windows Server 2008 R2
- Ubuntu 16.04
- CiD 7.1
O CiD é instalado sem nenhum erro, conforme o manual. É possível efetuar login com usuários do domínio sem nenhum problema também - funciona bem!
Minha dificuldade começa quando tento mapear unidades públicas de rede e as pastas particulares do usuário.
Notei que a pasta "scripts_cid" não foi criada automaticamente na pasta netlogon do DC, mas colocando manualmente, percebo que a estação de trabalho irá importar esse arquivo, e irá sobrescrever o arquivo xml de configuração do pam_mount (/etc/security/pam_mount.conf.xml).
Entretanto, não acontece a situação abaixo (que você comentou no início dos comentários):
"
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
"
Estes arquivos não foram alterados, então alteramos manualmente, mas sem sucesso também.
Tem mais alguma dica, algum detalhe que passou despercebido?
O meu muito obrigado,
Rodrigo Toledo
Boa tarde Rodrigo!
Primeiramente eu gostaria de agradecer pelo prestígio e apoio, pois é sempre um incentivo para continuidade do projeto.
As linhas de configuração às quais você se referiu já não são mais válidas na atual versão do CID. A configuração no /etc/fstab era utilizada em versões anteriores para mapear o NETLOGON na estação Linux, para que um determinado script do cid "chamasse" a execução dos scripts de logon dentro dessa pasta, porém dessa forma era necessário manter um arquivo com as credenciais do usuário administrador que ingressou a estação no domínio salvo na estação para que fosse possível montar o compartilhamento automaticamente. Atualmente isso não é mais necessário, pois um mapeamento do NETLOGON é realizado primeiramente pelo próprio pam_mount, e após a execução dos scripts de logon, e após a montagem dos possíveis compartilhamentos mapeados no arquivo shares.xml.
Se você alterou um desses arquivos, aconselho que refaça as configurações anteriores, pois estas já não são mais válidas, e principalmente no arquivo /etc/pam.d/common-session, que pode ocasionar algum conflito ou mau funcionamento.
Como você mencionou que a pasta scripts_cid não foi exportada automaticamente para o NETLOGON, desconfio que o problema pode estar na montagem desse compartilhamento pela estação Linux, que pode ser desde uma questão de permissão, ou falha de comunicação com o serviço na rede. Para descobrirmos a real causa vou precisar que faça alguns testes e me mande os resultados:
- Certificar se o arquivo de configuração do pam_mount está igual ao arquivo shares.xml: Como explicado na documentação do CID, o arquivo shares.xml nada mais é uma cópia do arquivo de configuração do pam_mount mantida no compartilhamento de rede para que todas as estações da rede possam ter a mesma versão desse arquivo no seu ficheiro local. Portanto quando o procedimento de configuração automática durante o logon do usuário funciona, ao final do logon o arquivo "/etc/security/pam_mount.conf.xml" deve está igual ao arquivo shares.xml.
- Desativar a desmontagem automática do NETLOGON após logon do usuário: Por questões de segurança um dos scripts do CID desmonta o compartilhamento NETLOGON após os scripts de logon serem executados. Na versão atual do CID o script responsável por essa ação é "/usr/lib/cid/exec/logon_commonUser.sh". Se você comentar a linha "sudo umount /mnt/.netlogon" desse script, você perceberá que após o próximo logon de um usuário do domínio o compartilhamento NETLOGON permanecerá montado no sistema em /mnt/.netlogon, caso ele realmente tenha sido montado sem problemas durante o logon.
- Acesse o sistema com o usuário criado na instalação do Ubuntu e tente montar o compartilhamento NETLOGON com o comando mount: Esse teste também já serve para ter uma pista da razão pela qual o compartilhamento não esteja sendo mapeado. Na sua estação Linux utilize o comando mount com a seguinte sintaxe:
sudo mount -t cifs //meudominio.com.br/netlogon /mnt/.netlogon -o user=DOMAINUSER
Substitua o DOMAINUSER por uma conta de usuário do domínio que tenha a senha, pois ela será solicitada.
Caso o compartilhamento não seja montado com êxito é importante observar a saída do comando, pois será uma pista para identificar a causa do problema. Do contrário provavelmente o mapeamento no logon também deverá estar funcionando normalmente, mas isso só poderá ser confirmado verificando os passos anteriores.
Se quiser postar também as configurações de mapeamento que foram feitas no arquivo shares.xml para que eu verifique se der repente não há algum erro de sintaxe... Creio que seja interessante.
Aguardo retorno, e disponha sempre!
[41] Comentário enviado por rodrigotn em 05/10/2016 - 14:30h
Boa tarde!
Antes de mais nada, é preciso lhe parabenizar pelo artigo e pela iniciativa. Parabéns!
Estou começando a descobrir agora esse mundo Linux e me deparei com a necessidade em ingressar máquinas com Ubuntu em ambiente com AD.
Meu cenário:
- Active Directory e Domain Controler com Windows Server 2008 R2
- Ubuntu 16.04
- CiD 7.1
O CiD é instalado sem nenhum erro, conforme o manual. É possível efetuar login com usuários do domínio sem nenhum problema também - funciona bem!
Minha dificuldade começa quando tento mapear unidades públicas de rede e as pastas particulares do usuário.
Notei que a pasta "scripts_cid" não foi criada automaticamente na pasta netlogon do DC, mas colocando manualmente, percebo que a estação de trabalho irá importar esse arquivo, e irá sobrescrever o arquivo xml de configuração do pam_mount (/etc/security/pam_mount.conf.xml).
Entretanto, não acontece a situação abaixo (que você comentou no início dos comentários):
"
2 - Outra situação é verificar se no arquivo /etc/fstab existe a seguinte entrada:
# --- < 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
e se no arquivo /etc/pam.d/common-session existe:
session optional pam_exec.so debug quiet /bin/mount -a
"
Estes arquivos não foram alterados, então alteramos manualmente, mas sem sucesso também.
Tem mais alguma dica, algum detalhe que passou despercebido?
O meu muito obrigado,
Rodrigo Toledo
Boa tarde Rodrigo!
Primeiramente eu gostaria de agradecer pelo prestígio e apoio, pois é sempre um incentivo para continuidade do projeto.
As linhas de configuração às quais você se referiu já não são mais válidas na atual versão do CID. A configuração no /etc/fstab era utilizada em versões anteriores para mapear o NETLOGON na estação Linux, para que um determinado script do cid "chamasse" a execução dos scripts de logon dentro dessa pasta, porém dessa forma era necessário manter um arquivo com as credenciais do usuário administrador que ingressou a estação no domínio salvo na estação para que fosse possível montar o compartilhamento automaticamente. Atualmente isso não é mais necessário, pois um mapeamento do NETLOGON é realizado primeiramente pelo próprio pam_mount, e após a execução dos scripts de logon, e após a montagem dos possíveis compartilhamentos mapeados no arquivo shares.xml.
Se você alterou um desses arquivos, aconselho que refaça as configurações anteriores, pois estas já não são mais válidas, e principalmente no arquivo /etc/pam.d/common-session, que pode ocasionar algum conflito ou mau funcionamento.
Como você mencionou que a pasta scripts_cid não foi exportada automaticamente para o NETLOGON, desconfio que o problema pode estar na montagem desse compartilhamento pela estação Linux, que pode ser desde uma questão de permissão, ou falha de comunicação com o serviço na rede. Para descobrirmos a real causa vou precisar que faça alguns testes e me mande os resultados:
- Certificar se o arquivo de configuração do pam_mount está igual ao arquivo shares.xml: Como explicado na documentação do CID, o arquivo shares.xml nada mais é uma cópia do arquivo de configuração do pam_mount mantida no compartilhamento de rede para que todas as estações da rede possam ter a mesma versão desse arquivo no seu ficheiro local. Portanto quando o procedimento de configuração automática durante o logon do usuário funciona, ao final do logon o arquivo "/etc/security/pam_mount.conf.xml" deve está igual ao arquivo shares.xml.
- Desativar a desmontagem automática do NETLOGON após logon do usuário: Por questões de segurança um dos scripts do CID desmonta o compartilhamento NETLOGON após os scripts de logon serem executados. Na versão atual do CID o script responsável por essa ação é "/usr/lib/cid/exec/logon_commonUser.sh". Se você comentar a linha "sudo umount /mnt/.netlogon" desse script, você perceberá que após o próximo logon de um usuário do domínio o compartilhamento NETLOGON permanecerá montado no sistema em /mnt/.netlogon, caso ele realmente tenha sido montado sem problemas durante o logon.
- Acesse o sistema com o usuário criado na instalação do Ubuntu e tente montar o compartilhamento NETLOGON com o comando mount: Esse teste também já serve para ter uma pista da razão pela qual o compartilhamento não esteja sendo mapeado. Na sua estação Linux utilize o comando mount com a seguinte sintaxe:
sudo mount -t cifs //meudominio.com.br/netlogon /mnt/.netlogon -o user=DOMAINUSER
Substitua o DOMAINUSER por uma conta de usuário do domínio que tenha a senha, pois ela será solicitada.
Caso o compartilhamento não seja montado com êxito é importante observar a saída do comando, pois será uma pista para identificar a causa do problema. Do contrário provavelmente o mapeamento no logon também deverá estar funcionando normalmente, mas isso só poderá ser confirmado verificando os passos anteriores.
Se quiser postar também as configurações de mapeamento que foram feitas no arquivo shares.xml para que eu verifique se der repente não há algum erro de sintaxe... Creio que seja interessante.
Aguardo retorno, e disponha sempre!
[43] Comentário enviado por soueulukas em 25/11/2017 - 17:13h
Recentemente tenho conseguido implementar o CID, para utilizar no domínio do Windows 2008 R2. O Linux está entrando cada vez mais em nossa cultura. Gostaria de saber se existe uma forma de montagem de compartilhamentos alocados em um servidor Freenas, sem utilizar autenticação do AD. Já estou testando uma forma de utilizar a autenticação do domínio no Freenas. Mas gostaria de ter as duas opções. Obs:. Nosso Freenas tem usuário e senha cadastrados para cada setor nele próprio, sem qualquer ligação com o AD.
Parabéns pelo artigo.
Recentemente tenho conseguido implementar o CID, para utilizar no domínio do Windows 2008 R2. O Linux está entrando cada vez mais em nossa cultura. Gostaria de saber se existe uma forma de montagem de compartilhamentos alocados em um servidor Freenas, sem utilizar autenticação do AD. Já estou testando uma forma de utilizar a autenticação do domínio no Freenas. Mas gostaria de ter as duas opções. Obs:. Nosso Freenas tem usuário e senha cadastrados para cada setor nele próprio, sem qualquer ligação com o AD.
Parabéns pelo artigo.
[44] Comentário enviado por removido em 27/11/2017 - 17:51h
[43] Comentário enviado por soueulukas em 25/11/2017 - 17:13h
Recentemente tenho conseguido implementar o CID, para utilizar no domínio do Windows 2008 R2. O Linux está entrando cada vez mais em nossa cultura. Gostaria de saber se existe uma forma de montagem de compartilhamentos alocados em um servidor Freenas, sem utilizar autenticação do AD. Já estou testando uma forma de utilizar a autenticação do domínio no Freenas. Mas gostaria de ter as duas opções. Obs:. Nosso Freenas tem usuário e senha cadastrados para cada setor nele próprio, sem qualquer ligação com o AD.
Parabéns pelo artigo.
Acredito que seja possível se você usar o comando de montagem desses compartilhamentos num script (logon_root.sh por exemplo) passando como parâmetro de opções o usuário e senha cadastrado em seu servidor Freenas com acesso ao respectivo compartilhamento. Com o pam_mount creio que não, pois ele usa automaticamente a autenticação do usuário que está abrindo a sessão, ou seja, precisaria que o seu servidor Freenas repassasse o processo de autenticação para seu controlador de domínio. Só funcionaria se esse compartilhamento fosse público em seu servidor de arquivos, sendo assim qualquer usuário poderia ter acesso independentemente da autenticação. Se você estiver usando SMB em seu Freenas, o comando de montagem do compartilhamento poderia ficar da seguinte forma: mount.cifs //ENDEREÇO_DO_FREENAS/COMPARTILHAMENTO PONTO_DE_MONTAGEM -o user=USUÁRIO_DA_BASE_FREENAS pass=SENHA.
Grato pelo prestígio!
[43] Comentário enviado por soueulukas em 25/11/2017 - 17:13h
Recentemente tenho conseguido implementar o CID, para utilizar no domínio do Windows 2008 R2. O Linux está entrando cada vez mais em nossa cultura. Gostaria de saber se existe uma forma de montagem de compartilhamentos alocados em um servidor Freenas, sem utilizar autenticação do AD. Já estou testando uma forma de utilizar a autenticação do domínio no Freenas. Mas gostaria de ter as duas opções. Obs:. Nosso Freenas tem usuário e senha cadastrados para cada setor nele próprio, sem qualquer ligação com o AD.
Parabéns pelo artigo.
Acredito que seja possível se você usar o comando de montagem desses compartilhamentos num script (logon_root.sh por exemplo) passando como parâmetro de opções o usuário e senha cadastrado em seu servidor Freenas com acesso ao respectivo compartilhamento. Com o pam_mount creio que não, pois ele usa automaticamente a autenticação do usuário que está abrindo a sessão, ou seja, precisaria que o seu servidor Freenas repassasse o processo de autenticação para seu controlador de domínio. Só funcionaria se esse compartilhamento fosse público em seu servidor de arquivos, sendo assim qualquer usuário poderia ter acesso independentemente da autenticação. Se você estiver usando SMB em seu Freenas, o comando de montagem do compartilhamento poderia ficar da seguinte forma: mount.cifs //ENDEREÇO_DO_FREENAS/COMPARTILHAMENTO PONTO_DE_MONTAGEM -o user=USUÁRIO_DA_BASE_FREENAS pass=SENHA.
Grato pelo prestígio!
[45] Comentário enviado por fabiogleao em 30/07/2018 - 08:42h
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
[46] Comentário enviado por galiann em 12/09/2018 - 11:02h
[45] Comentário enviado por fabiogleao em 30/07/2018 - 08:42h
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
Opa Fábio bom dia, olha outro coveiro aqui rss…
Onde você colocou a informação : domain=meu.domínio
e outra coisa
teve algum avanço nas pesquisas 1- e 2
Se puder coloca algum script que já tenha, estou tentando fazer a integração.
Pastas compartilhadas para todos entou conseguindo, mas pastas especificas com permissão de acesso não..
desde já grato.
Tenho um 2008 server AD com Ubuntu 18.04 fazendo integração com o LDAP
desde já grato por qualquer ajuda
[45] Comentário enviado por fabiogleao em 30/07/2018 - 08:42h
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
Opa Fábio bom dia, olha outro coveiro aqui rss…
Onde você colocou a informação : domain=meu.domínio
e outra coisa
teve algum avanço nas pesquisas 1- e 2
Se puder coloca algum script que já tenha, estou tentando fazer a integração.
Pastas compartilhadas para todos entou conseguindo, mas pastas especificas com permissão de acesso não..
desde já grato.
Tenho um 2008 server AD com Ubuntu 18.04 fazendo integração com o LDAP
desde já grato por qualquer ajuda
[47] Comentário enviado por galiann em 12/09/2018 - 11:08h
Outra coisa que queria comentar Moraes..
Simplesmente FANTÁSTICO seu artigo cara, parabéns mesmo.
Muito bem explicado, didático e o intuito da criação foi realmente para ajudar a integração Linux em empresas e assim aumentar a comunidade
Outra coisa que queria comentar Moraes..
Simplesmente FANTÁSTICO seu artigo cara, parabéns mesmo.
Muito bem explicado, didático e o intuito da criação foi realmente para ajudar a integração Linux em empresas e assim aumentar a comunidade
[48] Comentário enviado por removido em 13/09/2018 - 19:44h
[47] Comentário enviado por galiann em 12/09/2018 - 11:08h
Outra coisa que queria comentar Moraes..
Simplesmente FANTÁSTICO seu artigo cara, parabéns mesmo.
Muito bem explicado, didático e o intuito da criação foi realmente para ajudar a integração Linux em empresas e assim aumentar a comunidade
Muito obrigado, meu caro!
Sem dúvidas, essas palavras de incentivo são os maiores combustíveis para os motores do projeto, e propõe que ele continue crescendo e se aperfeiçoando cada vez mais!
[47] Comentário enviado por galiann em 12/09/2018 - 11:08h
Outra coisa que queria comentar Moraes..
Simplesmente FANTÁSTICO seu artigo cara, parabéns mesmo.
Muito bem explicado, didático e o intuito da criação foi realmente para ajudar a integração Linux em empresas e assim aumentar a comunidade
Muito obrigado, meu caro!
Sem dúvidas, essas palavras de incentivo são os maiores combustíveis para os motores do projeto, e propõe que ele continue crescendo e se aperfeiçoando cada vez mais!
[49] Comentário enviado por removido em 13/09/2018 - 19:55h
[46] Comentário enviado por galiann em 12/09/2018 - 11:02h
[45] Comentário enviado por fabiogleao em 30/07/2018 - 08:42h
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
Opa Fábio bom dia, olha outro coveiro aqui rss…
Onde você colocou a informação : domain=meu.domínio
e outra coisa
teve algum avanço nas pesquisas 1- e 2
Se puder coloca algum script que já tenha, estou tentando fazer a integração.
Pastas compartilhadas para todos entou conseguindo, mas pastas especificas com permissão de acesso não..
desde já grato.
Tenho um 2008 server AD com Ubuntu 18.04 fazendo integração com o LDAP
desde já grato por qualquer ajuda
Na versão mais recente do CID a correção do nome NetBIOS do domínio já é realizada de forma automática quando esse é diferente do nome do "curto" domínio. Portanto não é mais necessário declarar a variável "domain" no /etc/cid/cid.conf.
Quanto a montagem do compartilhamento restrito a um grupo específico, verifique se as permissões do compartilhamento foram configuradas corretamente para o grupo, isso é, tanto as permissões do compartilhamento, quanto do sistema de arquivo no diretório (pasta) do seu servidor que está sendo compartilhada. Você pode também fazer um teste na sua estação Linux tentando mapear esse compartilhamento manualmente com o comando mount.cifs, informando no parâmetro "user" uma conta de usuário que teoricamente deva ter acesso ao compartilhamento.
As configurações de proxy do sistema pode variar um pouco a depender da distribuição que esteja usando. Tenho um script para o Linux Mint, mas é perfeitamente ajustável para o Ubuntu. Se quiser, pode me contactar por e-mail que te passo com as devidas orientações para que você possa adaptá-lo ao seu cenário. Também pretendo fazer um vídeo no Youtube falando a respeito dessas e outras configurações das quais já tive experiências utilizando os scripts de logon do CID. Devo postar o link aqui assim que o fizer.
Abraço!
[46] Comentário enviado por galiann em 12/09/2018 - 11:02h
[45] Comentário enviado por fabiogleao em 30/07/2018 - 08:42h
Coveiro do ano aqui hein! rsrsrs
para ter sucesso eu tive que incluir nas opções (domain=meu.dominio)
demorei pra achar um outro artigo com esta informação.
utilizo um servidor Ubuntu 16 com Samba4 como DC-DNS
Agora vou pesquisar para que no login:
1- ele crie os atalhos no desktop dos usuários
2- pegue configurações de proxy
Opa Fábio bom dia, olha outro coveiro aqui rss…
Onde você colocou a informação : domain=meu.domínio
e outra coisa
teve algum avanço nas pesquisas 1- e 2
Se puder coloca algum script que já tenha, estou tentando fazer a integração.
Pastas compartilhadas para todos entou conseguindo, mas pastas especificas com permissão de acesso não..
desde já grato.
Tenho um 2008 server AD com Ubuntu 18.04 fazendo integração com o LDAP
desde já grato por qualquer ajuda
Na versão mais recente do CID a correção do nome NetBIOS do domínio já é realizada de forma automática quando esse é diferente do nome do "curto" domínio. Portanto não é mais necessário declarar a variável "domain" no /etc/cid/cid.conf.
Quanto a montagem do compartilhamento restrito a um grupo específico, verifique se as permissões do compartilhamento foram configuradas corretamente para o grupo, isso é, tanto as permissões do compartilhamento, quanto do sistema de arquivo no diretório (pasta) do seu servidor que está sendo compartilhada. Você pode também fazer um teste na sua estação Linux tentando mapear esse compartilhamento manualmente com o comando mount.cifs, informando no parâmetro "user" uma conta de usuário que teoricamente deva ter acesso ao compartilhamento.
As configurações de proxy do sistema pode variar um pouco a depender da distribuição que esteja usando. Tenho um script para o Linux Mint, mas é perfeitamente ajustável para o Ubuntu. Se quiser, pode me contactar por e-mail que te passo com as devidas orientações para que você possa adaptá-lo ao seu cenário. Também pretendo fazer um vídeo no Youtube falando a respeito dessas e outras configurações das quais já tive experiências utilizando os scripts de logon do CID. Devo postar o link aqui assim que o fizer.
Abraço!
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Como renomear arquivos de letras maiúsculas para minúsculas
Imprimindo no formato livreto no Linux
Vim - incrementando números em substituição
Efeito "livro" em arquivos PDF
Como resolver o erro no CUPS: Unable to get list of printer drivers
Tópicos
SysAdmin ou DevOps: Qual curso inicial pra essa área? (3)
É cada coisa que me aparece! - não é só 3% (3)
Melhorando a precisão de valores flutuantes em python[AJUDA] (5)
Top 10 do mês
-
Xerxes
1° lugar - 67.106 pts -
Fábio Berbert de Paula
2° lugar - 50.740 pts -
Buckminster
3° lugar - 18.024 pts -
Mauricio Ferrari
4° lugar - 15.771 pts -
Alberto Federman Neto.
5° lugar - 14.673 pts -
Diego Mendes Rodrigues
6° lugar - 13.342 pts -
Daniel Lara Souza
7° lugar - 12.873 pts -
edps
8° lugar - 11.445 pts -
Andre (pinduvoz)
9° lugar - 11.095 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 11.074 pts
Scripts
[Python] Automação de scan de vulnerabilidades
[Python] Script para analise de superficie de ataque
[Shell Script] Novo script para redimensionar, rotacionar, converter e espelhar arquivos de imagem
[Shell Script] Iniciador de DOOM (DSDA-DOOM, Doom Retro ou Woof!)
[Shell Script] Script para adicionar bordas às imagens de uma pasta
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
