[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!

0 0

[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!

0 0

[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.

0 0

[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!

0 0

[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!

0 0

[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

0 0

[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

0 0

[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!

0 0

[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.

0 0

[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

0 0

[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!

0 0

[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

0 0

[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

0 0

[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!

0 0

[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!

0 0

[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!

0 0

[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!

0 0

[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.

0 0

[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!

0 0

[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.

0 0

[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!

0 0

[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"
/>

0 0

[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.

0 0

[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é.

0 0

[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!

0 0

[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.

1 0

[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!

0 0

[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!

0 0

[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!

0 0

[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!

0 0

[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.

0 0

[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!

0 0

[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.

0 0

[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!

0 0

[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

0 0

[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

0 0

[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"

0 0

[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

0 0

[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

0 0

[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.

0 0

[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

0 0

[42] Comentário enviado por removido em 05/10/2016 - 17:28h



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!

1 0

[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.

0 0

[44] Comentário enviado por removido em 27/11/2017 - 17:51h



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!

0 0

[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

0 0

[46] Comentário enviado por galiann em 12/09/2018 - 11:02h



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

0 0

[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

0 0

[48] Comentário enviado por removido em 13/09/2018 - 19:44h



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!

0 0

[49] Comentário enviado por removido em 13/09/2018 - 19:55h



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!

0 0