INTEGRAÇÃO ZABBIX E GLPI

Essa atualização é em consequência de pedidos vindo dos gringos e também a pedido da Zabbix SIA por ser o 4.º conteúdo mais popular no recém criado https://share.zabbix.com/ e o 1.º entre os brasileiros. Para conferir a lista dos mais populares, acesse https://share.zabbix.com/popula

Há um tempo que eu queria desenvolver algo para integrar o Zabbix a algum outro sistema. Esse ano surgiu uma oportunidade de implementação de alguns sistemas de inventário e gerenciamento de chamados. Logo pensei em fazer uma integração para abertura e fechamento automático dostickets quando ocorresse algum problema que o Zabbix identificasse.

Porém, o meu entusiasmo foi logo caindo quando eu percebi que não era uma coisa tão trivial de se fazer. Pesquisei várias fontes em busca de informações a respeito dessa integração, porém não passavam de tutoriais ensinando como abrir tickets no GLPI enviando um e-mail. Estudando mais um pouco o GLPI, percebi que não era possível fazer o fechamento do ticket por outro e-mail. Num dos fóruns que eu participo, surgiu a idéia de tentar fazer essa integração atráves do plugin Webservicesque tem disponível para o GLPI. Em outra mensagem, uma pessoa enviou um link onde foi feito a integração do GLPI com a ferramenta Nagios utilizando esse plugin. Foi aí que eu ressolvi atacar e comecei a estudar como essa integração foi feita para que eu pudesse desenvolver para integrar com o Zabbix.

A partir desse momento surgiram várias dúvidas e também a necessidade de utilização de outros recursos, como a API do Zabbix. Pois, além da abertura do ticket, eu queria reconhecer o evento gerado pelo Zabbix de forma automática. Sendo assim, esse projeto iniciou com os seguintes propósitos:

• Identificar uma trigger com status PROBLEM no Zabbix e executar uma ação.
• Disparar a execução de um script PHP para abrir o ticket no GLPI usando o plugin Webservices.
• Enviar o número de evento gerado pela ação juntamente com o identificador da trigger e o nome do host onde o problema aconteceu. Essas informações serão gravadas no ticket criado no GLPI.
• Reconhecer o evento no Zabbix executando um script Python que faz uso da API do próprio Zabbix.
• Identificar uma trigger com status OK no Zabbix e disparar a execução de um script PHP para fechar o ticket no GLPI, além de incluir um followup no ticket informando que o problema foi resolvido.
• Utilizar o recurso de notificação de chamados disponível no GLPI.

Para seguir este tutorial, você deverá ter o Zabbix e o GLPI instalados. Não vou comentar sobre a instalação desses dois sistemas. Existem muitos tutoriais de instalação na web. Porém, os que eu recomendo são:

https://www.zabbix.com/documentation/2.2

http://zabbixbrasil.org/?page_id=7

http://www.glpi-project.org/spip.php?rubrique18

http://www.thiagopassamani.com.br/tags/glpi

As seguintes versões de software foram usadas nesta integração:

• Zabbix 2.2
• GLPI 0.84.3
• Python 2.6.6
• MySQL 5.1.69
• PHP 5.3.3
• Plugin Webservices 1.4

Creio não ter problemas de funcionar com a versão do Zabbix 2.x, pois a biblioteca Python API foi desenvolvida para funcionar a partir da versão 1.8. Mas quem vai querer usar versão anterior depois do lançamento da 2.2? A única dependência para o zabbix-glpi funcionar é a versão do GLPI e do plugin Webservices, que devem ser no mínimo as versões listadas acima.

Instalando o plugin Webservices no GLPI.

Antes de instalarmos o plugins, devemos suprir as dependências instalando os seguintes pacotes:

• php-soap
• php5-xmlrpc

Obs.: Se o Zabbix estiver instalado em servidor separado do GLPI, você deverá instalar o pacote php5-xmlrpc também no servidor do Zabbix.

• apt-get install php-soap php-xmlrpc -y
• service apache2 reload

Baixar e descompactar o plugin webservices dentro do diretório plugins do GLPI.

• cd /var/www/html/glpi/plugins
• wget https://forge.indepnet.net/attachments/download/1623/glpi_webservices-1.4.0.tar.gz
• tar xf glpi_webservices-1.4.0.tar.gz

Ajustar as permissões do diretório que foi descompactado.

• chown -R apache.apache webservices

Acessar o menu Configurar > Plugins na interface web do GLPI, aparecerá a tela conforme figura abaixo:

Após, clique no botão Instalar e em seguida no botão Habilitar.

O próximo passo é realizar a configuração do plugin, no qual fazemos acessando o menu Plugins > Web Services.

Será exibida apenas uma configuração com o nome Local. Clique no link para abrir a configuração, conforme tela abaixo:

Aqui, só precisamos informar o IP ou faixa de IP que terá acesso ao Webservice. No campo IPv4 address range, informe o IP do servidor Zabbix. Altere o campo Nome para Zabbix, apenas para ficar mais organizado.

Observando a imagem acima, você verá que eu coloquei a range 192.168.0.169-192.168.0.170. Isto porque eu utilizo servidores separados para o Zabbix e o GLPI. Se você utiliza apenas um único servidor, informe apenas o IP desse servidor nos dois campos.

O restante dos campos pode ficar sem alteração.

zabbix-glpi - Instalação e configuração

Baixe os scripts de intregração disponíveis em https://github.com/janssenlima/zabbix-glpi

Recomendo a instalação do pacote git para clonar o repositório.

# apt-get install git

Após, clone o repositório:

# cd /tmp/

# git clone https://github.com/janssenlima/zabbix-glpi.git

Mova os scripts para o diretório externalscripts da instalação do Zabbix (ou um diretório de sua preferência).

# mv *zabbix* /opt/zabbix/externalscripts/

Ajuste a permissão para o usuário zabbix e dê permissão de execução para os scripts.

chown zabbix.zabbix /opt/zabbix/externalscripts/*

# chmod +x /opt/zabbix/externalscripts/*

O conteúdo do diretório ficará assim:

# tree /opt/zabbix/externalscripts/

/opt/zabbix/externalscripts/

├── ack_zabbix_glpi.py

└── tickets_zabbix_glpi.php

Onde:

ack_zabbix_glpi.py é o script que faz o reconhecimento do evento no Zabbix via API.

tickets_zabbix_glpi.php é o script que faz abertura e fechamento de tickets no GLPI utilizando o plugin Webservices.

Instale a API Zabbix com o seguinte comando:

pip install zabbix-api

Agora, está faltando criarmos as ações para disparar a abertura e fechamento dos tickets.

Acesse o menu Configuração > Ações na interface web do Zabbix.

Criaremos duas ações. A primeira para abrir o ticket. Clique no botão Criar ação. Na tela seguinte dê o nome da ação. Vou chamá-la "Abrir Chamado". Na aba Ação não é preciso alterar os demais campos. Na aba Condições, podemos deixar como está, pois já vai satisfazer o que precisamos. Vale lembrar que a condição Valor da trigger = PROBLEMA é obrigatória. Na aba Ações criaremos uma nova operação com os seguintes dados:

• Duração padrão do passo da operação: 60
• Tipo da opração: Comando remoto
• Lista alvo: Host: Zabbix server 
• Tipo: Script personalizado
• Executar em: Agent Zabbix
• Comandos: php /opt/zabbix/externalscripts/tickets_zabbix_glpi.php eventhost="{HOSTNAME}" event="DOWN" state="{TRIGGER.STATUS}" hostproblemid=0 lasthostproblemid=0 servico="{TRIGGER.NAME}" triggerid="{TRIGGER.ID}" eventzabbix="{EVENT.ID}"

Algumas observações das configurações acima: A lista alvo deverá ser o host onde os scripts de integração se encontram; Não altere os parâmetros do campo comando, com exceção do caminho onde você gravou o script.

Crie outra ação com o nome "Fechar chamado". As únicas configurações que você precisa fazer são:

• Na aba Condições, remova a condição de problema da trigger e inclua Valor da trigger = OK.
• Altere o comando na aba Ações para: php /opt/zabbix/externalscripts/tickets_zabbix_glpi.php eventhost="{HOSTNAME}" event="UP" state="{TRIGGER.STATUS}" hostproblemid=1 lasthostproblemid=1 servico="{TRIGGER.NAME}" triggerid="{TRIGGER.ID}" eventzabbix="{EVENT.ID}"Novamente. Não altere os parâmetros do comando, apenas o caminho do script no seu servidor, caso for diferente do que está.

Dica: Clone a ação para não precisar fazer tudo novamente, já que são apenas duas alterações a fazer, além de trocar o nome da ação.

Neste primeiro momento não se preocupe com as condições. Vá testanto aos poucos. Uma dica é você filtrar por grupo de hosts. Por exemplo, você deseja abrir chamados automaticamente apenas dos servidores, impressoras e roteadores, deixando fora equipamentos como desktop.

O parâmetro EnableRemoteCommands do arquivo zabbix_agentd.conf deve estar com o valor 1, que habilita a execução de comandos remotos.

Toda a configuração para fazer a integração entre o Zabbix e o GLPI foi realizada. 

Isso funciona mesmo?

O teste que eu vou fazer é forçar a parada do serviço SSH do próprio servidor do Zabbix. A imagem foi tirada da tela de Dashboard após o Zabbix identificar a que o serviço parou.

Observe na figura que após o incidente ser reconhecido, ele já executou uma ação e foi reconhecido. Isso significa que o ticket foi aberto. Temos outras formas de verificar o evento através do menu Monitoramento > Eventos. Clicando na data e horário do evento, obtemos informações detalhadas sobre o mesmo, conforme pode ser visualizado na figura abaixo:

Agora, vamos verificar o ticket criado no GLPI.

A figura acima exibe o ticket de ID 5 aberto e com status de novo e a descrição do problema com o número do evento gerado no Zabbix. É através desse número que o script ack_zabbix_glpi.py faz o reconhecimento do evento no Zabbix via API.

Ao abrirmos o ticket, podemos verificar outros campos, tais como a descrição do problema que exibe informações como nome do host, ID da trigger e seu status. Outra informação importante é a Origem da requisição, onde informa que este ticket foi criado por Webservices. Observe na figura abaixo:

Agora vamos iniciar o serviço SSH para o ticket ser fechado automaticamente. Acesse o menuMonitoramento > Eventos no Zabbix e verifique que o serviço já está OK.

Voltamos para o GLPI e verificamos que o ticket foi fechado.

Observe na coluna Status que mudou para Solucionado.

Clicando no ticket, veremos que o Followup foi inserido no registro após o seu fechamento automático. Observe a figura abaixo:

E assim a integração está realizada. Você poderá verificar os tickets abertos automaticamente quando uma trigger for disparada e ser fechado quando a trigger voltar ao normal. Existe um pluginde relatórios que podemos ver de forma gráfica a quantidade de registros que foram abertos e solucionados via Webservices. Mas isso é um assunto para outro post.

A respeito do recurso de notificação por e-mail, já está incluído e funcionando. Se você utiliza esse recurso do GLPI mas não quer receber os e-mails dos tickets abertos via Webservice, deverá comentar a linha no código do arquivo tickets_zabbix_glpi.php. Quando eu automatizar a instalação essa opção poderá ser escolhida no momento da instalação.

O próximo passo será empacotar o zabbix-glpi nos formatos RPM e DEB e automatizar a instalação. Atualizações e correções de erros serão informadas em posts neste blog.

Eu gostaria muito da opinião de vocês para que possamos manter esse projeto sempre atualizado, buscando melhorias de qualidade e performance, alterando opções que são geradas automaticamente etc. Para isso, preciso do feedback, tanto de crítica como de sugestões.

FONTE:

http://blog.janssenlima.com/2013/11/integracao-zabbix-glpi.html

https://github.com/janssenlima/zabbix-glpi

http://blog.janssenlima.com/2014/08/atualizacao-zabbix-glpi.html

GERENCIANDO LAN (LAN HOUSE OU CYBER-CAFÉ) COM SOFTWARE LIVRE (OPENASB)

Uma funcionária responsável por uma biblioteca pediu-me uma solução para seu problema:

Dentro de uma biblioteca, existem 6 máquinas disponíveis para acesso a internet, sendo assim, estudantes que necessitam fazer pesquisas podem usá-los, desde que, utilizem por apenas 30 minutos e; não possuam permissões dentro do sistema operacional para alterar qualquer item do mesmo. As máquinas funcionam com Ubuntu para não ter problemas com "vírus".

Com o intuito de descascar esse abacaxi, pesquisei diversas forma de criação de script (em ShellScript) que encerrasse a sessão do usuário. Mas, deparei-me com a possibilidade de atrapalhar algum cadastro de algum visitante, pois encerrando a sessão, todos aplicativos iram fechar automaticamente. Em outra tentativa, fiz um script que bloqueasse a sessão do usuário. Contudo, outro problema surgiu: como estabelecer o tempo de acesso, corretamente para cada estudante.

Foi então que conheci o OpenASB, um aplicativo para Lan House, de código livre, desenvolvido em Gambas3 (linguagem de programação). Desta forma, conseguimos suprir nossas principais necessidades, estabelecendo o tempo de acesso, apresentando uma página de bloqueio que pode ser personalizada, possui ainda, diversas formas de bloqueio para usuário comum. Contudo, outras opções de segurança tivemos que fazer manualmente, como: bloquear acesso terminal (usermod -s /bin/false usuário); retirar a permissão de sudoers do usuário corrente (gpasswd -d  usuário sudo); bloquear papel de parede para manter o mesmo padronizado para todas as máquinas, até porque usuário comum adora modificar (chmod 555 -R ~/.config/dconf).

OpenASB Servidor:

O OpenASB precisa de um servidor para controlar as demais máquinas, esse mesmo servidor precisa estar configura com as seguintes características:

- IP fixo;

- Ubuntu 15.04 (no 14.10 não funcionou direito);

- Gambas3 (o OpenASB só funciona com o Gambas3 instalado);

- Xvnc (para acesso remoto).

OpenASB Client:

O módulo cliente terá que ser configurado com as seguintes características:

- OpenASB apontar para o Servidor;

- Ubuntu 15.04;

- Gambas3;

- Xvnc;

- O cliente precisa de dois usuários, um para permissão de "sudo" e outro com permissão padrão ou remover do grupo de sudoers (gpasswd -d usuário sudo);

- Bloquear acesso terminal (usermod -s /bin/false usuário);

- Para manter um trabalho com um bom acabamento, foi padronizado os papeis de paredes das máquinas dos clientes, e em seguida bloqueado (chmod 555 -R ~/.config/dconf). 

Referências:

www.openasb.com/

CORRIGIR "ERRO DE SISTEMA 85" - NÃO CARREGA CORRETAMENTE PERFIL DO USUÁRIO DO DOMÍNIO

Ao logar com meu usuário do AD, não consegui as permissões liberada para mim por exemplo: todos os usuários do meu setor estão com permissões para acessar o youtube. Contudo, no perfil não foi possível.

Para resolução deste problema foi executado os seguintes procedimento:

1º - Corrigir o "o erro de sistema 85"

Esse comportamento é causado por uma configuração de 1 na seguinte valor do registro:

HKLM\System\CurrentControlSet\Control\SessionManager\ProtectionMode

Se a configuração for 1, o problema ocorre. Se você alterar a configuração para 0 e reinicie o servidor, o problema desaparece.

2º - Forçar a atualização do perfil do usuário:

Abra o CMD e digite:

gpupdate /force

COMO INGRESSAR LINUX (UBUNTU 15.04) NO AD

Precisei ingressar meu Ubuntu 15.04 no AD, como sei que vou precisar desse artigo de vez em quando, estou postando no meu blog, mas todo conteúdo é do VIVAOLINUX, o endereço completo desse artigo encontra-se nas referencias deste post

PRÉ-REQUISITOS E FINALIDADE DE CADA UM PARA O TRABALHO

Antes de começar a trabalhar, é necessário saber quais são os serviços que o desktop com o sistema GNU/Linux precisa ter rodando para ingressar no domínio. Abaixo descrevo os serviços:

• Kerberos
• Winbind
• Samba

Kerberos é um protocolo de rede usado para autenticação de usuários e/ou serviços de rede, como o Active Directory. utilizando um sistema criptografado, permitindo comunicações seguras e identificadas em redes, fazendo uso de tickets (chaves criptografadas).

O Active Directory faz uso deste serviço para autenticação em rede, logo, as máquinas clientes terão que ter informações do KDC (Centro de Distribuição de Chaves) para autenticar-se no Active Directory.

O Winbind é um daemon usado pelo PAM, NSSWITCH, Samba e podendo ser usado por outros serviços de rede e/ou sistema, fazendo a interface entre o PDC e o computador cliente rodando o serviço Winbindd, permitindo que máquinas com o sistema GNU/Linux comuniquem-se com DC Active Directory.

O Samba até a versão 3, que é a que será usada nesse artigo, é um serviço cuja principal função é disponibilizar recursos compartilhados em uma rede, tais como arquivos e impressoras. Mas será usado para autenticação de usuários no servidor onde está rodando devido o winbind depender do mesmo.

O mesmo faz uso de dois serviços, são NMB e SMB.

O serviço NMB tem a principal finalidade de resolução de nomes NetBIOS para que o servidor Samba possa enxergar e ser enxergado pelas outras máquinas. Então, este serviço permite a navegação pela rede, usando os hostnames das máquinas e o acesso às mesmas em rede.

O serviço SMB permite compartilhar tais recursos e autenticar os usuários no servidor Samba local, ou repassa as solicitações de autenticação para outro computador, como um servidor controlador de domínio com o Active Directory.

CONSIDERAÇÕES DE AMBIENTE DE REDE

No ambiente proposto no artigo, já existem os servidores DNS em execução na rede, pois, para a autenticação ser feita, é necessário o uso do DNS e o servidor com Active Directory configurado como controlador de domínio principal já instalado e funcionando.

Veja a disposição dos servidores na rede para explicação do artigo:

• Domínio → adm.pi.empresa.br
• Servidor DNS primário → 10.0.0.2
• Servidor DNS Secundário → 10.0.0.13
• Servidor DHCP → 10.0.0.2
• Servidor controlador de domínio → 10.0.0.2 adm.pi.empresa.br

Como os clientes serão configurados pelo serviço DHCP, só especificarei o nome da máquina cliente:

• Desktop cliente → ubuntu

======================================================

Agora será abordada a parte técnica do trabalho.

ARQUIVO /ETC/HOSTS, INSTALAÇÃO DE PRÉ-REQUISITOS E KERBEROS

ARQUIVO /ETC/HOSTS

Nesta parte iremos editar o arquivo /etc/hosts incluindo uma alias para o endereço do controlador de domínio e alterar o hostname do desktop cliente (mintvirt), acrescentando o fqdn, ou seja, o nome do domínio junto ao hostname da máquina cliente.

No entanto, substitua os nomes abaixo pelos correspondentes na sua rede.

# vim /etc/hosts

Conteúdo a ser acrescentado:

127.0.0.1 ubuntu.adm.pi.empresa.br localhost ubuntu 
10.0.0.2 server

Observe que "server" é nome do controlador de domínio usado no artigo, troque pelo nome do controlador de domínio de sua rede. Execute o comando abaixo para ver o nome da máquina completo, ou seja, o hostname com o nome do domínio da máquina cliente:

# hostname -f

INSTALAÇÃO DE PACOTES NECESSÁRIOS

Para que o desktop GNU/Linux possa migrar no domínio, é necessário fazer a instalação dos seguintes pacotes descritos a seguir, lembrando que os pacotes abaixo, são para distros Debian like:

# apt-get install krb5-user krb5-config winbind samba samba-common smbclient cifs-utils libpam-krb5 libpam-winbind libnss-winbind

Durante a instalação do kerberos, vai ser apresentado algumas telas com perguntas referentes ao KDC, mas pode dá um ENTER e seguir com a instalação dos pacotes, pois a configuração do kerberos será abordada mais a frente.

SERVIÇO NTP - SICRONIZANDO DATA E HORA COM O SERVIDOR

Para que a máquina cliente possa comunicar-se sem problemas com o controlador de domínio Windows Server, é necessário que o horário e data de ambas as máquinas estejam sincronizadas. Para isso, teremos que configurar o cliente NTP para atualizar data e hora pelo servidor Active Directory.

Edite o arquivo de configuração do serviço NTP usando o Vim:

# vim /etc/ntp.conf

Nas linhas do arquivo onde o conteúdo começa com a palavra "server", comente estas linhas com uma cerquilha "#", e adicione o seguinte conteúdo:

# Controlador de domínio #

server 10.0.0.2

restrict 10.0.0.2

Veja que ambos os endereços são do controlador de domínio. Agora, reinicie o serviço de data e hora:

# /etc/init.d/ntp stop

# /etc/init.d/ntp start

O Ubuntu usa o Upstart, então, para reiniciar o serviço é diferente. Para uma leitura mais abrangente, leia o conteúdo desse link:

Upstart e a configuração dos serviços no Ubuntu « www.hardware.com.br

O ambiente proposto pelo artigo, existe um servidor DHCP, então, não é necessário configurar o DNS, já que esse trabalho é feito pelo serviço DHCP. No entanto, se não estiver usando um serviço DHCP, edite o arquivo /etc/resolv.conf indicando os endereços dos servidores de nome, como mostrado abaixo:

# vim /etc/resolv.conf

search adm.pi.empresa.br

nameserver 10.0.0.2

nameserver 10.0.0.13

Substitua os endereços acima e o nome do domínio informado pelos endereços de seus servidores DNS e o nome do seu domínio na rede onde está configurando a máquina cliente.

KERBEROS

Para um usuário autenticar-se no Active Directory, é necessário editar o arquivo /etc/krb5.conf e incluir informações sobre o servidor KDC (controlador de domínio kerberos). Nesse caso, o controlador de domínio com o Active Directory possui um KDC. Use o Vim para editar o arquivo e inclua as seguintes linhas no arquivo:

# vim /etc/krb5.conf

Conteúdo acrescentado:

[libdefaults]

default_realm = PI.EMPRESA.BR

[realms]

PI.EMPRESA.BR = {

kdc = winactive.pi.empresa.br

default_domain = PI.EMPRESA.BR

admin_server = winactive.pi.empresa.br

}

[domain_realm]

.adm.pi.empresa.br = ADM.PI.EMPRESA.BR

EXPLICAÇÃO DA CONFIGURAÇÃO

Este arquivo é organizado em seções. As seções inclusas para autenticação no domínio são listadas abaixo junto com suas sub-seções:

[libdefaults] → Seção que contém valores padrão para o Kerberos V5, nessa seção só deixei uma única sub-seção, explicada a seguir.

default_realm → Esta sub-seção identifica o domínio padrão a ser usado pelo cliente kerberos.

[realms] → O kerberos divide a rede em domínios seguros, chamados de "realms", então esta seção contém sub-seções informando nomes de "realms" do Kerberos, informando onde encontrar os servidores Kerberos para domínios seguros específicos e outras informações.

Neste caso, criei uma sub-seção chamada de "ADM.PI.EMPRESA.BR", que é referente ao domínio seguro no qual a máquina irá ingressar. E dentro, criei as seguintes sub-seções:

kdc → Aqui se configura o nome da máquina que está executando o controlador de domínio do kerberos mestre, como o controlador de domínio rodando o Active Directory está executando o KDC, então inclui o nome completo da máquina aqui.

default_domain → Nesta sub-seção se especifica o domínio seguro padrão.

admin_server → Esta sub-seção identifica o host onde o servidor que faz administração do kerberos está sendo executado.

[domain_realm] → Seção que indica os mapas de domínios e sub-domínios.

Depois de configurar o kerberos, vamos testar a comunicação entre o servidor e desktop. Execute o comando abaixo, no exemplo estou usando o nome "fulando", que é um usuário do domínio criado, mas substitua pelo nome do usuário que estiver cadastrado no servidor.

# kinit fulano

Se o comando não retornar nenhuma saída, é porque a comunicação está sendo realizada com sucesso. Agora vamos listar o ticket obtido nessa comunicação usando o comando:

# klist

O comando klist deverá retornar uma saída como a que está abaixo:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: fulano@pi.empresa.br

Valid             starting    Expires                        Service principal
13-11-2012  15:48:35  14-11-2012 01:49:08   krbtgt/ADM.PI.EMPRESA.BR@ADM.PI.EMPRESA.BR
renew until 16-11-2012 15:48:35

======================================================

CONFIGURANDO SAMBA, INGRESSANDO MÁQUINA NO DOMÍNIO E ARQUIVO /ETC/NSSWITCH.CONF

CONFIGURANDO O SAMBA

Antes de colocar a máquina no domínio, é necessário configurar o Samba para que seja possível à máquina ingressar no domínio. Toda configuração é feita no /etc/samba/smb.conf, o Winbind não precisa configurar pois o mesmo é um daemon usado pelo Samba. Edite o arquivo /etc/samba/smb.conf com Vim: # vim /etc/samba/smb.conf Inclua as seguintes linhas no arquivo "smb.conf", caso algumas dessas linhas já estejam dentro do arquivo, edite e deixa-as como está abaixo. O arquivo está bem comentado com explicações dos principais parâmetros:

[global]

security = ads # O modo de operação ADS faz com que o Samba se comporte como um membro (cliente) de um domínio Windows

realm= ADM.PI.EMPRESA.BR # Informa o domínio que controlador de domínio Kerberos que será usado

workgroup = ADM # Informa o grupo de trabalho, nesse caso informa o domínio

idmap uid = 10000-15000 # Especifica o intervalo de IDs de usuários que serão mapeados para o sistema local, coloquei um intervalo de cinco mil, mas pode colocar menor ou maior número

idmap gid = 10000-15000 # Especifica o intervalo de GIDs de grupos que serão mapeados para o sistema local
winbind enum users = yes # Permiti o winbind enumerar usuários

winbind enum groups = yes # Permiti o winbind enumerar grupos

template homedir = /home/%D/%U # Informa aonde será criado o diretório home de cada usuário após logar no sistema, o parâmetro %D informa o nome do domínio e %U o nome do usuário

template shell = /bin/bash # Informa qual shelll será atribuído ao usuário, você pode incluir /bin/false para impedir que o usuário faça uso do shell, mas irá ser usado por todos usuários do domínio

client use spnego = yes # Este parâmetro controla se smbclient irá usar negociação simples e protegido na autenticação, essa opção permite usar o Kerberos

winbind use default domain = yes # Parâmetro usado para não incluir o nome do domínio a ser usado junto ao nome do usuário no sistema, por exemplo: DOMINIO\usuário. Habilitando esse parâmetro, somente o nome do usuário será usado para identificar o mesmo

restrict anonymous = 2

winbind refresh tickets = yes # Este parâmetro é usado para controlar se o winbind deve atualizar os tickets do Kerberos usando o módulo pam_winbind

Observe que nem todos os parâmetros são necessários para ingressar a máquina no domínio. Depois de editar, salve as alterações e reinicie os serviços do Samba e Winbind.

# service winbind restart

# service samba restart

No Ubuntu, reinicie da seguinte forma:

# service winbind restart

# restart smbd

# restart nmbd

INGRESSANDO A MÁQUINA NO DOMÍNIO

Depois de configurar o Samba, é hora de ingressar a máquina no domínio com o comando net. Execute o comando abaixo como root:

# net ads join -U Administrador

Veja que usei a opção "-U" no comando net, seguido do nome do usuário com permissão de ingressar máquinas no domínio, o usuário Administrador foi usado. Após a execução do comando, deverá retornar uma mensagem como que está abaixo:

Using short domain name - ADM
Joined 'UBUNTU' to realm 'ADM.PI.EMPRESA.BR'

Agora, faça o teste e liste os grupos e usuários do domínio com o comando wbinfo. Para listar usuários execute:

# wbinfo -u

Para listar os grupos execute:

# wbinfo -g

Caso não retorne nenhum nome de usuário ou grupo, reinicie o Winbind.

ARQUIVO NSSWITCH.CONF

Depois ingressar a máquina no domínio, vamos configurar o arquivo /etc/nsswitch.conf para que o sistema possa saber onde buscar informações de login dos usuários que estão se autenticando. É neste arquivo que iremos comunicar ao sistema que ele deve procurar nossas informações de login usando o Winbind. Edite o arquivo usando o Vim e deixando as linhas abaixo como demonstrado. Em seguida, salve as alterações:

# vim /etc/nsswitch.conf

Conteúdo alterado:

passwd: compat winbind

group: compat winbind

Veja que, como estamos lidando com usuários, grupos e senhas, apenas alteramos as linhas que correspondem aos mesmos, estamos informando ao sistema que ele deve procurar nossas informações de login usando o Winbind nas linhas:

"passwd: compat" para senha

"group: compat" para group

======================================================

CONCLUINDO O TRABALHO

ALGUNS DETALHES E ESCLARECIMENTOS

Muitos howtos encontrados na Internet mostram configurações adicionais desnecessárias, fazendo alterações em vários arquivos de autenticação do PAM. Mas a maioria destas configurações não são necessárias, pois ao instalar os pacotes Winbind e o pacote que contém as bibliotecas do kerberos, o próprio sistema se encarrega de alterar os arquivos sem qualquer intervenção dos usuários, com exceção de um arquivo.

O único arquivo que se faz necessário a intervenção do usuário é o /etc/pam.d/common-session (em distros Debian like).

Então, edite o arquivo /etc/pam.d/common-session e após linha abaixo:

session required pam_unix.so

Inclua esta:

session required pam_mkhomedir.so umask=0022 skel=/etc/skel

A linha mencionada anteriormente faz o diretório home de cada usuário ser criado automaticamente no inicio de cada sessão após a autenticação do usuário, setando as permissões para os arquivos e diretórios com a "umask 0022" e obtendo do diretório /etc/skel seus sub-diretórios e arquivos padrões. Caso esta linha não esteja adicionada, provavelmente será apresentado a seguinte mensagem após o login:

SOLUCIONANDO O PROBLEMA AO TROCAR SENHAS DURANTE O LOGIN NO UBUNTU

Todo o trabalho feito até então fará os usuários logarem nos desktops GNU/Linux sem problemas nas distros Debian e Linux Mint Debian Edition. No Ubuntu 12.04, no entanto, haverá um problema quando for solicitado para o usuário trocar a senha no momento do login. Normalmente o administrador da rede mantém um diretiva interna que indica o tempo que uma senha será válida, após esse período, a senha expira. As imagens abaixo indicam onde acontece o erro quando se tenta trocar a senha na tela de login. Quando digita-se a senha, o gerenciador de login pede para repetir a senha atual e em seguida, pede a repetição da senha atual. Depois de digitar e dar um ENTER, não é pedido para entrar com a nova senha e a mesma não é trocada, e volta em seguida para tela de login.

A solução para poder alterar senha quando solicitada e autenticar-se, é editar o arquivo /etc/pam.d/common-account alterando as duas linhas abaixo:

account[sucess=2new_authtok_reqd=donedefault=ignore]pam_unix.so account[sucess=1new_authtok_reqd=donedefault=ignore]pam_winbind.so

Deixando-as assim:

account[sucess=2new_authtok_reqd=donedefault=ignore]pam_winbind.so account[sucess=1new_authtok_reqd=donedefault=ignore]pam_unix.so

Veja que somente inverti a ordem dos módulos, colocando o módulo "pam_winbind.so" antes do módulo "pam_unix.so". Assim, após a alteração da senha e confirmação da autenticação, a classe de módulos "account" irá primeiro consultar o módulo "pam_winbind.so", permitindo o acesso e não dando o erro de antes. Veja nas imagens abaixo como fica a solicitação de alteração de senha. Digitando nome de usuário senha atual:

Solicitando a repetição da senha atual:

Pedindo para repetir outra vez a senha atual:

Solicitando a nova senha:

Pedindo para confirmar a nova senha:

TELA DE LOGIN NO UBUNTU

Uma dica para quem usa o Ubuntu, é alterar a tela de login do mesmo fazendo com que seja possível logar com qualquer usuário, e não somente o usuário criado na instalação do sistema, informando nome e senha. Para isso, edite o arquivo /etc/lightdm/lightdm.conf incluindo as alterações mencionadas abaixo, no final do arquivo. OBS:. No ubuntu versão 15.04 crie o arquivo, pois o mesmo não se encontra no path informado acima.

[SeatDefaults]

allow-guest=false

greeter-show-manual-login=true

greeter-hide-users=true

Depois de todas estas etapas, reinicie a máquina e ao logar, use somente o nome do usuário cadastrado no domínio. Este detalhe é interessante por causa da configuração usada no arquivo /etc/samba/smb.conf, não é necessário colocar o nome do domínio junto com o nome do usuário que irá logar no domínio, coloque somente o nome de usuário e informe a senha.

REFERÊNCIAS

• AutenticandoAD - Ubuntu Brazil « wiki.ubuntu-br.org
• O Kerberos não é um cachorro de 3 cabeças! [Artigo]
• Ubuntu 12.04 - Ingressando no AD pela Tela de Login [Dica]
• http://www.vivaolinux.com.br/artigo/Ingressar-desktop-GNU-Linux-no-dominio-Active-Directory-do-Windows-Server-2008?pagina=1

INSTALAR E CONFIGURAR O X11VNC PARA UBUNTU

1º – Para instalar use o comando:

sudo apt-get install x11vnc

2º – Para criar a senha:

sudo x11vnc -storepasswd A_SUA_PASSWORD /etc/x11vnc.pass

3º – Para dar permissão ao arquivo de senha:

sudo chmod 744 /etc/x11vnc.pass

4º – O comando a seguir vai rodar o X11vnc:

 sudo x11vnc -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -rfbauth /etc/x11vnc.pass -forever -bg -rfbport 5900 -o /tmp/x11vnc.log

Bom, até aí o aplicativo vai funcionar direitinho. Contudo, após reiniciar a máquina ele não mais estará rodando. Para fazer com que o programa inicie com o Sistema Operacional, será necessário criar um script dentro de /etc/init.d/, dar permissão de execução e executar o comando "update-rc.d" para fazer com que isso aconteça.

Passos:

Criar o arquivo:
=====================================================
# vim /etc/init.d/vnc-server

adicionar as linhas de comando dentro do arquivo:

#!/bin/bash

 

start() {

    echo "Iniciando VNC-Server..."

    x11vnc -env FD_XDM=1 -display :0 -forever -rfbauth /root/.vncpasswd &>> /var/log/vnc-server.log &

    echo "[OK]"

}

 

stop() {

    echo "Desligando VNC-Server..."

    killall x11vnc &>> /var/log/vnc-server.log

    echo "[OK"]

}

    case "$1" in

    start) start

    ;;

    stop) stop

    ;;

    restart) stop; start

    ;;

    *) echo "Uso correto: (start|stop|restart)"

    ;;

esac

- See more at: http://www.aprendendolinux.com/x11vnc-o-vnc-do-linux/#sthash.n3AoC9ho.dpuf

#!/bin/bash

start() {
   echo "Inciar VNC..."
   x11vnc -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -rfbauth  /etc/x11vnc.pass -forever -bg -rfbport 5900 -o ~/.Log-x11vnc.log
   echo"VNC Funcionando..."
}

stop() {
    echo "Parando o VNC..."
    killall x11vnc &>> ~/.Log-vnc-server.log
    echo "VNC parado..."
}
    case "$1" in
    start) start
    ;;
    stop) stop
    ;;
    restart) stop; start
    ;;
    *) echo "Uso correto: (start|stop|restart)"
    ;;

esac
========================================================
Para dar permissão de execução para ao script:

# chmod +x /etc/init.d/vnc-server

Agora, vamos temos que colocar o script para iniciar com o sistema:

# cd /etc/init.d/
# update-rc.d vnc-server defaults

OK. O x11vnc já está configurado para iniciar com o sistema e você pode fazer o STOP e START com os comandos abaixo:

Exemplos:
# /etc/init.d/vnc-server start
# /etc/init.d/vnc-server stop
# /etc/init.d/vnc-server restart

Caso você não precise mais que ele suba junto com o sistema operacional, faça o comando abaixo:

# cd /etc/init.d/
# update-rc.d -f vnc-server remove


OBS.: A porta padrão de execução do VNC é a 5900

# vim /etc/init.d/vnc-server
Deixe-o assim:

# vim /etc/init.d/vnc-server
Deixe-o assim: