Scripts de logon não se aplicam aos usuários comuns
Insert and manage Linux computers in AD
Brought to you by:
emoraes25
Menu
▾
▴
Boa noite Eduardo!Segui os procedimentos de instalação do CID conforme README. Instalei as dependências do Debian. Instalei a versão cid_1.07. Juntei ao domínio: Banspa.mb com o usuário administrator. Na hora de logar com usuário do domínio, não aparece as pastas mapeadas, a qual, o usuário faz parte. Observei que o arquivo /etc/security/pam_mount.xml não consta os dados do arquivo shares.xml da pasta NETLOGON do servidor baenspadc.banspa.mb ( SERVIDOR AD DC). O servidor fileserver baenspafs é um outro servidor. Este servidor de arquivo, ele não é um DC. Porém, quando é efetuado login com o usuário administrator, uma cópia do conteúdo do sheres.xml é copiado para etc/security/pam_mount.xml e neste mesmo login os compartilhamentos são montados e o wallpapers é carregado pelo script de login (root.sh). Portanto, ao reiniciar a estação, o pam_mount.xml que recebeu a atualização por causa do login do administrador do domínio continua em funcionamento. E, agora qualquer outro usuário do domínio consegue efetuar login e ter o mapeamento montado. Somente o papel de parede não carrega. Enfim, o sistema verifica se o usuário pertence aquele grupo durante o login. Mas este usuário não tem acesso ao NETLOGON. Pois, se atualizar o arquivo sheres.xml não modifica em etc/security/pam_mount.xml.
Att, André
Enviado do Yahoo Mail no Android
Se o seu DC for Linux com Samba4, execute o seguinte comando em seu terminal e poste aqui o resultado:
ls -laZ $(testparm --section-name=netlogon -s | grep -wi path | awk '{print $3}')
naonao
O comando deve ser executado no terminal do servidor (Controlador de Domínio), não na estação.
Bom dia! O meu servidor não possuia este comando instalado fiz a instalação do pacote samba4-common. A execução do comando testparm ele faz alguma alteração no sistema? Realizei o comando conforme indicado na imagem abaixo.
Não. Na verdade, o comando era só para vê como estão setadas as permissões no diretório do compartilhamento Netlogon em seu servidor. Havia desconfiado que pudesse ter relação com os modelos de permissões Unix ou contexto SELinux, mas pelo resultado, é difícil dizer se há algum problema relacionado a essas permissões.
Recomendo que, se possível, verifique as ACLs do compartilhamento e seus subdiretórios a partir de um sistema Windows para que possamos ter mais pistas do que pode está acontecendo (veja os anexos).
Last edit: Eduardo Moraes 2020-05-25
Boa tarde Eduardo, verifiquei as ACLs, as permissões estão idênticas com seus arquivos de imagens. Estou enviando o meu smb.conf caso seja necessário.
Faça os seguintes testes:
Acesse uma estação Linux com um usuário que seja administrador do domínio, ou o usuário administrador local do sistema (geralmente criado durante a instalação da distro Linux);
Em seguida, tente montar o netlogon com o comando mount autenticando com uma conta de usuário comum do domínio. De preferência a mesma em que você notou os problemas dos mapeamentos e da aplicação do papel de parede. Use os comandos abaixo:
Caso consiga montar, troque de usuário no terminal gráfico (não encerre a sessão) e logue com a conta desse mesmo usuário. Veja se consegue ter acesso aos arquivos do diretório /tmp/mnt e se consegue abrir o arquivo de imagem que está tentando aplicar ao papel de parede desse usuário. Use o gestor de arquivos gráfico da sua distribuição (nautilus no Ubuntu, por exemplo);
Se continuar sem ter acesso, coloque temporariamente esse usuário que foi testado no grupo de administradores do domínio em seu AD. Reinicie a estação Linux e tente logar com esse usuário de novo. Veja se as rotinas dos scripts de logon foram implementadas;
Se isso funcionar, certamente deverá ser um problema de permissão no acesso ao netlogon para os demais usuários não administradores do domínio. Então será preciso descobrir onde exatamente essa permissão precisa ser ajustada, uma vez que, aparentemente, tantos as ACLs do Windows quanto as permissões Unix parecem estar corretamente setadas no diretório do compartilhamento Netlogon em seu DC.
Last edit: Eduardo Moraes 2020-05-26
Boa noite Eduardo, realizei o procedimento de mapeamento do netlogon para o usuario comum do dominio. O mapeamento funcionou. Alternei para o usuario do dominio e teve permissao para abrir o papel de parede. Coloquei o usuario no grupo de administradores, mas infelizmente nao carregou o script de logon. Sera que o problema nao esta desde o inicio que passei a utilizar o CID de forma errada (no procedimento de instalacao que fazia sem todas as dependencias instaladas). Comecei com o CID 1.03 e quando fazia a instalacao da dependencia so instalava apenas libpam-mount, neste momento da instalacao a pasta script_cid foi criada em NETLOGON... Editei o shares.xml... Mas, o mapeamento nao carregava nos clientes, sem antes utilizar um programa de inserir/retirar a estacao no dominio. Somente desta forma conseguia que o administrator buscasse os meu volumes criados no shares.xml. Dai, desde entao, somente o administrator tem acesso ao NETLOGON. Se apagar a pasta script_cid do NETLOGON todos os cliente perderao o acesso. Se esse for o motivo e fizer uma nova instalacao do CID sera criado um novo diretorio em NETLOGON do CID? E apos esse procedimento terei que remigrar todos os computadores?
Last edit: Eduardo Moraes 2020-06-08
André, não consegui entender bem o seu texto, mas é o seguinte:
A pasta scripts_cid, caso ela ainda não exista, é exportada para o Netlogon quando uma máquina é inserida no domínio através do CID e não durante a sua instalação. Se você apagar a pasta agora do Netlogon, basta inserir (ou reinserir) um novo computador no domínio através do CID, que uma nova pasta será criada no Netlogon com todos os seus arquivos-modelos (logon.sh, logon_root.sh e shares.xlm).
Segundo ponto é, se você estiver usando Ubuntu ou uma de suas derivadas, você deve instalar o CID utilizando o pacote do repositório PPA, pois assim todas as dependências são instaladas automaticamente sem a necessidade de realizar o processo de forma manual e correr o risco de deixar alguma coisa de fora. Recomendo que veja até o final o vídeo que eu fiz sobre a instalação do CID, pois lá eu explico em detalhes como realizar a instalação do CID nessas distribuições.
Terceiro ponto, não entendi direito o que quis dizer com "...Mas, o mapeamento nao carregava nos clientes, sem antes utilizar um programa de inserir/retirar a estacao no dominio...". De todo jeito, para que os scripts do CID possam funcionar nos clientes Linux é necessário que eles sejam inseridos no domínio através do CID, pois é durante este processo que o CID realiza as devidas configurações no sistema para viabilizar essas funcionalidades. Não tenho certeza se só o fato de recriar a pasta scripts_cid no Netlogon resolva seu problema, pois realmente me parece uma questão de permissões inadequadas nesse compartilhamento, mas você pode tentar. De qualquer forma, se alguma máquina tenha sido inserida no domínio sem utilizar as funções dentro do CID, com certeza você terá que reinseri-la usando o CID para ter isso funcionando.
Last edit: Eduardo Moraes 2020-06-08
Boa tarde prezado Eduardo, envio anexo o arquivo de log gerado pelo servidor AD DC. Realizei os procedimentos de acordo com o seu vídeo de instalação parte 2. Após colocar a máquina no domínio loguei como administrator, não está carregando os compartilhamentos do grupo, somente carregando o papel de parede. E os membros do domínio, logam mais não carregam as pastas do grupo e nem o papel de parede.
O teste foi realizado hoje dia 03 de junho para acompanhamento do anexo.
Desde já agradeço pela compreensão e o apoio sempre. Desculpe pelo texto anterior.
Abraços.
Last edit: Eduardo Moraes 2020-06-08
Boa noite Eduardo, estou enviando mais um log gerado logo após o ingresso da máquina no domínio. Agora tem um cenário diferente, o papel de parede não carregou e tem a msg de acordo com arquivo anexo. Parte do log: "get_referred_path: |NETLOGON| in dfs path \baenspadc.banspa.mb\NETLOGON is not a dfs root."
ATT,
Esse erro é provavelmente porque o cliente está tentando acessar o Netlogon sem usar o caminho da raiz DFS, que normalmente é o nome do domínio apenas. Perceba que parece que ele tenta acessar usando o FQDN do seu controlador de domínio, o que é estranho porque o CID configura o pam_mount justamente para usar o nome do domínio para montar o Netlogon. Poderia me enviar o conteúdo do arquivo "/var/lib/cid/mount_netlogon.xml" dessa estação?!
Olá Eduardo, o log completo segue anexo.
Att,
Boa noite!
Bom dia Eduardo! Estou lhe enviando o meu arquivo "/var/lib/cid/mount_netlogon.xml" desta estação.
Agradeço pela ajuda! Bom final de semana!
O arquivo está correto e o erro que aparece no seu log me parece ser um bug do Samba, mas que não impede que o compartilhamento seja acessado. Ativei o log em um servidor de teste que criei e percebi as mesmas mensagens, no entanto, todas as rotinas dos scripts de logon do CID são executadas sem problemas, assim como a cópia do shares.xml é realizada em todos os logons, independente do usuário (administrador ou não).
A única ressalva que eu faria sobre seu arquivo de log, onde eu percebi que difere do meu, é com relação a conta DTI-18$, que, pelo sifrão no final, deduzo ser a conta da máquina que usou, e aparentemente ela está desabilitada, conforme sugere as seguintes mensagens encontradas em seu log:
Verifica no seu AD se está tudo certo mesmo com essa conta. Se preciso, use o CID para remover e reingressar essa máquina novamente em seu domínio.
Se o problema persistir, peço que poste aqui os seus arquivos logon.sh, logon_root.sh e shares.xml da pasta scripts_cid em seu Netlogon, assim como o log de scripts do CID (/var/log/cid/scripts.log) para que eu possa também analisá-los.
Boa noite Eduardo! Quanto ao smb.conf do servidor controlador de domínio, você vê necessidade de adicionar aa seguintes linhas:
domain master = yes
domain logons = yes
local master = yes
preferred master = yes
Já que as estações windows tem o funcionamento normal da gpo para todos os usuários membros do domínio.
E pesquisando na internet sobre o erro da falha de login spnego. Observei a possibilidade de inserir no smb.conf do desktop linux a seguinte linha:
client use spnego = yes
domain master = no
Estranho que são todos os desktop Linux Ubuntu18.04 LTS que estão com esse problema de não carregar o script de logon.sh e o shares.xml. A senha é trocada normalmente do usuário pelo cid...
Agradeço pelo esforço em tentar me ajudar!
Você precisa verificar a que funcionalidade corresponde cada parâmetro desse no smb.conf. Geralmente as configurações padrões são adequadas ao contexto de funcionamento cujo servidor Samba está inserido, e certamente não é isso que está causando problema. O mesmo é válido para as estações clientes.
Boa tarde Eduardo, estou enviando os arquivos solicitados.
Aproveitando para tirar mais algumas dúvidas, antes de ingressar a máquina no domínio preciso configurar os arquivos /etc/ntp.conf , /etc/hosts e o /etc/resolv.conf.
Att,
Não é necessária nenhuma configuração! O CID já faz isso!
O ntpd não é mais necessário na versão atual do CID. Ao invés dele, o CID usa um daemon do systemd (systemd-timesyncd) para realizar a sincronização de horário com os DCs da rede.
O resolv.conf você provavelmente não precisa editar, a menos que sua estação não esteja recebendo os parâmetros corretos dos servidores DNS da sua rede, ou de um servidor DHCP, ou via configuração estática no gestor de configuração de rede da sua distribuição. Se a máquina estiver resolvendo os nomes do seu domínio corretamente, certamente nenhuma configuração será necessária. Você pode testar isso usando, por exemplo, o seguinte comando em sua estação:
nslookup NOME_DO_DOMÍNIOLast edit: Eduardo Moraes 2020-06-15
Pelo seu log, os scripts estão sendo executados corretamente! Não vi onde está o erro.
Bom dia, será permissão na própria estação de trabalho?
Não sei dizer. Isso só seria possível dizer tendo acesso ao computador, mas aparentemente está tudo funcionando dentro do esperado, veja:
Essas linhas em seu log sugere que, tanto o arquivo de configuração do pam_mount está sendo substituído pelo shares.xml, quanto as rotinas do logon.sh estão sendo executadas sem erro.
Tente logar nessa mesma máquina com um usuário comum do domínio (não administrador) e veja se não terá o mesmo resultado. Se possível, poste aqui o log novamente após esse teste.
Boa tarde! Eduardo, houve um progresso na descoberta. Há alguma configuração ainda a ser feita. Fiz um teste criando um novo usuário e coloquei esse usuário na OU=User, funcionou normal. Como faço para que funcione na OU=usuarios, OU=ban-xx.
Mais uma dúvida o meu smb.conf possui uma linha " ldap server require strong auth = no "para que meus usuários do glpi se autentique via ldap. Atrapalha no funcionamento do CID?
Outra questão, os usuários já existentes precisam ser recriados? Envio também um anexo do erro de tentativa de login dos usuário ja existentes.
Att,
Não vejo razão para não funcionar com os usuários das demais OU's do seu domínio, a menos que haja uma política aplicadas a essas OU's que esteja criando algum tipo de restrição nessas contas, mas sinceramente acho pouco provável. Assim como não acho que seja necessário recriar qualquer usuário. Se quiser realmente confirmar isso, basta mover então uma dessas contas de usuários para o container User e testá-la!
Quanto a configuração no smb.conf do seu servidor, ela não interfere no CID, até porque se interferisse você não teria tido êxito com a conta de administrador e com a conta nova que mencionou.
Quanto a imagem, isso indica que o usuário está logando com as credenciais salvas em cache local do sistema ao invés de consultar seus controladores de domínio. Isso acontece normalmente por alguma falha na rede e/ou pelo fato de seus DCs não poderem ser contactados pela sua estação. Durante o logon em cache, os scripts de logon do CID não são executados!