Gerenciamento Centralizado de Servidor com OpenLDAP e Interface GOsa

ISSN 2316-2872 T.I.S. São Carlos, v. 3, n. 1, p. 69-79, jan-abr 2014 Tecnologias, Infraestrutura e Software Gerenciamento Centralizado de Servidor com OpenLDAP e Interface GOsa Resumo: A existência de diversos serviços de internet, com seus próprios sistemas de autenticação e configuração, exige do administrador muito trabalho e tempo para configurar e administrar um servidor. Com o serviço de diretório, que tem a capacidade de armazenar informações de vários tipos e é otimizado para leitura, é possível criar um banco de dados único para armazenamento desses dados e, com o uso de interfaces como o GOsa, facilmente interagir com esses serviços. Neste sentido, este trabalho apresenta uma forma de configurar um serviço de diretório em um ambiente Linux e, com o uso do gerenciador de pacotes apt-get e da interface GOsa, permitir a instalação e administração centralizada de um servidor, de uma forma simples e funcional, com a criação de usuários e de configurações de alguns destes serviços Palavras-Chave: openldap, gosa, autenticação centralizada, gerenciamento centralizado, ftp, proxy Server Centralized management with OpenLDAP and GOsa interface Abstract: The existence ofvarious internet services, with their own authentication and system configuration, demands from the administrator a lot ofwork and time to set up and manage a server. With the directory service, which can store various types ofinformation and is optimized for reading, it is possible to create a single database to store these data and to easily interact with these services using interfaces like GOsa. This paper presents a way of configuring a directory service in a Linux environment and using the apt-get package manager and GOsa interface, allowing installing and centralizing the server administration in a simple and functional way with user creation and configuration ofsome ofthese services Keywords: openldap, gosa, centralized authentication, centralized administration, ftp, proxy I. INTRODUÇÃO Os vários serviços de internet oferecidos por provedores, empresas e instituições de ensino (como universidades) necessitam de autenticação. Seus usuários, ao verificarem emails, copiarem arquivos de um servidor FTP ou identificarse para ter acesso à rede corporativa de terminais Windows, são obrigados a fornecer uma identificação, geralmente composta por um nome e uma senha. A tarefa de autenticar usuários em diferentes sistemas operacionais, como Windows, Linux ou Unix, onde estes serviços são instalados, é bastante complexa, pois geralmente cada um desses serviços possui seu próprio mecanismo de armazenamento de informações dos usuários. Se todos eles pudessem realizar a autenticação em um único banco de dados, o trabalho do administrador seria minimizado. O serviço de diretório possui a capacidade de centralizar essas informações, não só autenticando dados de usuário, mas também armazenando configurações dos serviços, como zonas DNS, sub-redes DHCP, certificados digitais, arquivos binários, dentre outras informações. Para facilitar o trabalho do administrador, a atualização dos pacotes instalados em um servidor deve ser feita da forma mais simples e funcional possível. Para isso, vários sistemas operacionais possuem suas próprias ferramentas. O sistema operacional Ubuntu, utilizado neste trabalho, possui a ferramenta apt-get que, além de facilitar a instalação dos pacotes, também analisa e resolve as dependências necessárias para a instalação. O apt-get permite também a atualização simples e rápida dos aplicativos já instalados, garantindo a segurança do servidor. O administrador deve contar com interfaces fáceis de serem operadas e que, comunicando-se com os diferentes serviços instalados, permita a criação rápida e simples de usuários, grupos e demais configuração do servidor. Neste trabalho é verificado a viabilidade de utilização da interface GOsa, que é um conjunto de scripts PHP com diversos plugins para gerenciar todas essas informações armazenadas no serviço de diretório (GONICUS, 2012), fazendo a intermediação entre os dados armazenados e os serviços em operação e criando um ponto de gerenciamento centralizado. Departamento de Computação - Universidade Federal de São Carlos (UFSCar) Caixa Postal 676 13.565-905 São Carlos SP Brasil Autor para correspondência: : lhcarrara@gmail.com, mbellezi@gmail.com

Este trabalho apresenta a configuração/implementação de um serviço de diretório, o OpenLDAP, para centralizar a autenticação de usuários, além de armazenar informações de outros serviços de um servidor, como zonas DNS e sub-redes DHCP. Diferente de outros trabalhos encontrados nas referências (TRIGO, 2007; SUNGAILA, 2008), este será configurado através do novo método cn=config. Porém, ele não tratará de outras funcionalidades disponíveis neste aplicativo, como autenticação segura utilizando SASL com TLS, replicação entre servidores LDAP e nem indexação de atributos para aumentar a velocidade da pesquisa, já que não se trata de um ambiente de produção. Além disso, diferente de algumas implementações encontradas nas referências (SUNGAILA, 2008; ACHACA, 2012), onde as instalações são feitas através da compilação de pacotes e resolução de uma série de dependências, ou então realizada através da modificação de repositórios originais, o objetivo é utilizar o mecanismo nativo de instalação e de atualização de pacotes do sistema operacional (apt-get), com a intenção de diminuir a dificuldade do administrador em instalar e manter o sistema atualizado. Este trabalho apresenta também a constatação de viabilidade técnica da interface GOsa em permitir a criação rápida e fácil de usuários para autenticação em serviço de FTP e Squid, além do armazenamento de informações de configuração para DNS e DHCP. Não será o foco deste trabalho as outras funcionalidades do GOsa, especialmente as que são oferecidas por seus vários plug-ins, uma vez que estaria fora do contexto deste trabalho. II. F UNDAMENTOS Segundo Trigo (2007), um diretório é um serviço de armazenamento hierárquico de informações com o objetivo principal de facilitar a pesquisa e a recuperação destas informações. O Serviço de Diretório (SD) consiste em um repositório, uma espécie de banco de dados especializado para armazenar informações, ordenadas e de vários tipos, sobre objetos. Em um exemplo simples, informações sobre impressoras (os objetos) podem ser armazenadas, como sua localização (uma cadeia formatada de caracteres), sua velocidade máxima de impressão em páginas por minuto (um valor numérico) e seu driver (um binário) (TUTTLE, 2004). Um diretório possuiu uma estrutura em árvore conhecida como DIT (Directory Information Tree Árvore de Informação do Diretório). No início, para refletir a estrutura regional das organizações, o primeiro protocolo DAP (X.500) representava no topo da árvore os países (c country). Logo abaixo vinham os estados (st state). Depois vinham as organizações (o organization) e suas unidades organizacionais (ou organizational unit), que representam os departamentos de uma empresa. Nelas estão ligadas as pessoas e suas informações (TRIGO, 2007). A estrutura da árvore de diretório no estilo do protocolo X.500 é ilustrada pela Figura 1. Figura 1. DIT no estilo X.500 (TRIGO, 2007) No diretório, uma determinada pessoa é identificada de forma única através de seu DN (Distinguished Name Nome Único). Ele indica o caminho da base até a folha da árvore onde estão as informações da pessoa e é representado, levando em consideração a árvore apresentada na Figura 1, como cn=clodonil Trigo, ou=vendas, o=iae, st=são Paulo, c=br. Outra interpretação possível de uma árvore de diretório é a de componente de domínio de internet (dc Domain Component), refletindo a estrutura do DNS. Desta forma, os primeiros níveis do diretório representam o nome de domínio da empresa, na mesma ordem de leitura de um servidor DNS (TRIGO, 2007). A estrutura da árvore de diretório no estilo do DNS é ilustrada pela Figura 2. Figura 2. DIT no estilo DNS (TRIGO, 2007) Neste caso, o DN do usuário, identificado nesta estrutura pelo atributo uid, é representado por uid=clodonil, ou=usuários, dc=exemplo, dc=com. Na maioria das vezes, o atributo uid é utilizado pelos serviços para identificar o nome do usuário utilizado. Um protocolo de acesso a diretorio (DAP - Directory Access Protocol) estabelece as regras de comunicação entre um cliente e um serviço de diretório. O primeiro deles foi o X.500, desenvolvido pela ITU Telecommunication. No entanto, o X.500 foi baseado no modelo de referência OSI 70

Gerenciamento centralizado de servidor com OpenLDAP e interface GOsa (Open Systems Interconnection), muito utilizado antes do advento da internet e que, dentre outros problemas, era bastante difícil de ser implementado corretamente, resultando em aplicações complexas e lentas. Com o advento da internet, o modelo TCP/IP passou a ser utilizado como referência para o desenvolvimento de aplicações de rede. Assim, o protocolo leve de acesso a diretório LDAP (Lightweight Directory Access Protocol) foi desenvolvido e padronizado em julho de 1993, na RFC 1487 da IETF (Internet Engineering Task Force Força-Tarefa de Engenharia da Internet). Embora esteja na terceira versão, denominada LDAPv3 e padronizada pela RFC 4510, ele foi criado originalmente como uma alternativa de acesso aos serviços de diretório do X.500 (TRIGO, 2007). Com o passar dos anos, várias aplicações começaram a dar suporte de acesso a diretórios. Lozano (2002) apud Trigo (2007) ressalta a integração do LDAP com outros serviços, complementando a infraestrutura de redes, fornecendo novos recursos e, especialmente, maior integração, diferentemente de outros protocolos e linguagens estabelecidos como SNMP, HTTP, SMTP, IMAP ou SQL. No LDAP, a recuperação de informações é iniciada pela raiz da árvore e o dispositivo de busca vai percorrendo os nós até encontrar o elemento desejado. A raiz e os ramos da árvore são diretórios. Cada diretório pode conter outros diretórios ou elementos que são chamados de entradas; cada entrada possui um ou mais atributos que, por sua vez, podem ter um ou mais valores associados a eles, todos de acordo com um tipo de dados predefinido (TRIGO, 2007). O OpenLDAP é uma implementação do protocolo LDAP, desenvolvida pela Universidade de Michigan. É um software de código aberto e pode ser executado em vários sistemas operacionais, dentre eles BSD, Solaris, Windows e distribuições Linux. Em ambiente Linux, é executado através do serviço slapd. Segundo Ubuntu (2012), desde a versão 8.10 deste sistema operacional, o daemon do OpenLDAP é projetado para ser configurado por uma DIT separada. Esse banco de dados de configuração consiste de uma coleção de arquivos texto LDIF localizados no diretório /etc/ldap/slapd.d. Este método de configuração é conhecido como slapd-config ou cn=config. A configuração tradicional por arquivo, fazendo uso do slapd.conf, ainda pode ser utilizada, mas não é recomendada, pois esta funcionalidade será extinta futuramente no Ubuntu. Alguns esquemas clássicos vêm embutidos na instalação do slapd, como o cosine, o nis, o inetorgperson e um esquema core, prérequisito para todos os outros esquemas. O processo de instalação configura duas DITs: uma para slapd-config e uma para o domínio utilizado (dc=home,dc=com), no caso deste trabalho. A Figura 3 ilustra a aparência do banco de dados slapdconfig, armazenado na forma de arquivos LDIF, localizados no diretório /etc/ldap/slapd.d. Os diferentes arquivos de schema são organizados através de números entre chaves seguidos dos seus respectivos nomes. Os quatro apresentados fazem parte da configuração padrão do OpenLDAP instalado no Ubuntu 12.04.1. Figura 3. Arquivos LDIF de configuração (UBUNTU, 2012) A inserção dos dados na base LDAP é feita através de arquivos LDIF (LDAP Data Interchange Format), de texto puro, e que permitem a importação e alteração de dados, o backup e a replicação do diretório. Outra maneira de manipular o diretório é a utilização de interfaces gráficas, que podem ser aplicativos instalados ou scripts de páginas dinâmicas. Uma dessas interfaces, conhecida como GOsa, que é o foco deste trabalho, que permite a criação de usuários, grupos e outras configurações de serviços do servidor, como zonas DNS e sub-redes DHCP, armazenando as informações utilizando diferentes schemas carregados por ela. Normalmente, um diretório é descrito como um banco de dados, mas ele possui características que o diferenciam dos bancos de dados relacionais e de propósito geral. Uma característica especial dos diretórios é que eles são acessados (leitura/busca) muito mais rapidamente do que são atualizados (escrita). Como o foco de um diretório é o armazenamento de informações estáticas, ou seja, que dificilmente são modificadas, seu algoritmo de busca é otimizado e as informações são lidas de uma maneira muito mais rápida (TUTTLE, 2004). Desta forma, como os diretórios suportam grande número de requisições de leitura, são ideais para um serviço de autenticação onde milhares de usuários são cadastrados, já que suas informações raramente serão alteradas (nome, endereço, nome de usuário, senha, endereço de e-mail, etc.). Sungaila (2008) diz que, os servidores de Diretório normalmente não têm suporte a métodos avançados para controle de transações ou esquemas de roll-back, sendo a baixa performance em escrita seu ponto fraco, pois têm como base que as informações armazenadas dificilmente serão alteradas. Assim, um serviço de diretório não é ideal para armazenar informações que mudam constantemente. Os bancos de dados relacionais são mais indicados para este tipo de necessidade. Como neste trabalho o foco é autenticação através de informações que raramente serão modificadas, esta característica não necessariamente é uma desvantagem para esta implementação. Para expandir a capacidade de armazenamento de informações do serviço de diretório, os schemas devem ser 71

adicionados às configurações do OpenLDAP. Schemas são patronizados por RFCs e definem quais classes de objetos (objectclass) podem existir no diretório, os atributos que cada classe pode ter e que tipo de informação pode ser armazenada em cada atributo (TRIGO, 2007). Todas as entradas de um diretório são padronizadas, ou seja, cada entrada pertence a uma ou mais classes de objetos que identificam quais dados podem ser armazenados naquela entrada. A classe de objetos especifica atributos obrigatórios e atributos opcionais que podem ser associados a cada entrada daquela classe (SUNGAILA, 2008). Os schemas possuem as definições de classes de objetos (objectclass) e de tipos de atributos (attributetype), que se inter-relacionam através de identificadores, conhecidos como OID (Object Identifiers Identificadores de Objeto). Segundo Sungaila (2008), OID são atributos pertencentes a todos os objetos de um diretório, definidos de acordo com os padrões LDAP e X.500, e que são escritos em uma notação decimal pontuada. Na Figura 4 são apresentadas duas classes de objetos e alguns de seus parâmetros. Figura 4. Exemplos de classes de objetos, adaptado de (SUNGAILA, 2008) No exemplo da Figura 4, a classe com o nome organizationalperson possui o OID 2.5.6.7 e, em seu nível hierárquico na árvore de diretório (DIT), está conectada abaixo da classe person, conforme indica a diretiva SUP person STRUCTURAL. A diretiva MAY indica quais atributos podem conectar-se a esta classe de objeto. A classe com o nome person possui o OID 2.5.6.6 e, em seu nível hierárquico, está conectada abaixo da classe top, que representa a raiz da árvore de diretório. A diretiva MUST indica quais atributos devem conectar-se a esta classe de objeto. A Figura 5 representa graficamente o relacionamento entre as classes de objetos apresentadas na Figura 4, acrescida de outra classe organization, que também possui como classe superior a top. Figura 5. Exemplo de DIT (SUNGAILA, 2008) Os tipos de atributos definem quais dados essas diretrizes irão armazenar, como seu tipo (booleano, string, numérico, octetos, dentre outros), seu nome, se são sensíveis a maiúsculas ou minúsculas, etc. Um exemplo de declaração de atributos é mostrado na Figura 6. Figura 6. Exemplos de tipos de atributos, adaptado de (SUNGAILA, 2008) No exemplo mostrado na Figura 6, dois tipos de atributos são apresentados. O atributo cujo nome é name possui OID 2.5.4.41 e não difere maiúsculas de minúsculas, conforme a diretiva EQUALITY caseignorematch. Já a SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 indica que o valor armazenado é uma string Unicode. O atributo cujo nome é cn ou commonname possui OID 2.5.4.3 e está conectado abaixo do atributo name, conforme indica a diretiva SUP name. Para a expansão da árvore de diretório e suporte a diferentes serviços, seus respectivos schemas devem ser adicionados ao OpenLDAP através do comando ldapadd. GOsa é o acrônimo para GOnicus System Administration. Segundo Gonicus (2012), este sistema oferece uma estrutura poderosa para gerenciamento de contas em sistemas utilizando bancos de dados LDAP. Permite que os administradores gerenciem usuários e grupos, telefones, faxes, listas de e-mail, e diversos outros parâmetros. Proporciona um único ponto, baseado em LDAP, para administração de ambientes grandes e pequenos. GOsa possui dois tipos de empacotamento: o core, que apresenta somente os arquivos essenciais para o funcionamento da estrutura, que pode ser acrescida pelos plug-ins, separados por funcionalidades em arquivos independentes, e o empacotamento combined, que possui os arquivos core com os plug-ins já embutidos. III. ESTUDO DE CASO O sistema GOsa é um conjunto de scripts escritos basicamente em PHP e que, para sua utilização, necessita do Apache com suporte à essa linguagem, além de várias dependências. Ele interage com o serviço de diretório através de uma conta com privilégio de gravação. Para a expansão de suas funcionalidades, plug-ins podem ser adicionados ao conjunto de arquivos básico do GOsa. Estes plug-ins manipulam seus respectivos conjuntos de atributos, que podem ser adicionados ao OpenLDAP, expandindo sua capacidade de armazenamento. Neste estudo de caso propõese a implementação de um sistema GOsa como interface de 72

Gerenciamento centralizado de servidor com OpenLDAP e interface GOsa um serviço de diretório OpenLDAP para o gerenciamento centralizado de um servidor de teste, com a criação de usuários que autenticarão em dois serviços instalados: FTP e proxy. Além disso, GOsa será utilizado para armazenar as informações de configuração de dois outros serviços a serem instalados: DNS e DHCP. Para a sua execução, uma série de passos foram necessários para a correta instalação e configuração dos serviços e da interface GOsa. Na Figura 7 é mostrado o fluxo dos procedimentos para facilitar o entendimento do processo. Neste trabalho foi utilizado o sistema operacional Ubuntu 12.04.1 LST x86_64, totalmente atualizado. A escolha deste sistema operacional deveu-se ao fato da desenvolvedora do sistema GOsa, Gonicus, trazer em sua documentação os passos para instalação em duas distribuições principais, a Debian/Ubuntu e a RedHat/Fedora. Somou-se a esta decisão a documentação trazida nas publicações utilizadas nas referências deste trabalho, cuja maioria faz uso do sistema operacional Ubuntu. A implementação ocorreu utilizando uma máquina virtual, onde o Ubuntu recebeu o IP 192.168.180.84. O nome do host foi definido como tcc-01.home.com e portanto, o domínio foi home.com. Todos os serviços foram instalados neste mesmo sistema. Para testes diversos, outra máquina virtual foi utilizada, onde o Windows 7 recebeu o IP 192.168.180.82. O nome do host foi definido com win7-01.home.com e, portanto, o domínio também foi home.com. Instalação da interface GOsa O GOsa, por ser um conjunto de scripts escritos basicamente em PHP, necessita da instalação do Apache2 com suporte a PHP5, além de uma série de módulos desta linguagem como dependência. Segundo Gonicus (2012), e com base em Trigo (2012), o comando utilizado para instalação é mostrado na Figura 8. Figura 8. Instalação dos pacotes para a interface GOsa Após a instalação dos pacotes necessários, foram feitas as configurações para dar suporte à execução da interface. Segundo Trigo (2012), e com base em Gonicus (2012), a configuração dos parâmetros do PHP é mostrada na Figura 9. Figura 9. Configuração do PHP5 Gonicus (2012) instrui que no arquivo de configuração do Apache2 (/etc/apache2/sites-enabled/000-default) deve ser adicionado um apelido na sessão Alias do contêiner <VirtualHost></VirtualHost>, conforme mostrado na Figura 10. Figura 10. Configuração do Apache2 A versão core do GOsa foi utilizada neste trabalho, acrescida dos plug-ins de DNS, DHCP e Systems, no diretório de trabalho /usr/share/gosa, conforme configuração definida no Apache2. A Figura 11 representa os passos para download e instalação da interface e seus plug-ins no sistema de arquivos do Ubuntu. Eles estão organizados em blocos e identificados ao lado para melhor entendimento. Figura 7. Procedimentos para execução do estudo de caso 73

Figura 11. Passos para instalação da interface GOsa e plug-ins No primeiro bloco, realizou-se a criação do diretório de trabalho, o download e a instalação dos arquivos core do GOsa. No segundo bloco, executou-se o download dos plugins necessários para este trabalho, a extração de seus arquivos e a cópia deles para o diretório de plug-ins do GOsa, localizado em /usr/share/gosa/plug-ins. No terceiro bloco foram configurados como usuário e grupo proprietários dos arquivos o www-data, uma vez que o acesso a eles será feito pelo Apache2, que tem esse usuário como seu manipulador. É necessária a criação de dois diretórios, o /etc/gosa e o /var/spool/gosa, este último deve ter seu proprietário alterado, tanto usuário quando o grupo, para o manipulador do Apache2, o www-data, utilizando o comando chown. inserida uma senha para o usuário administrativo, que possui privilégios totais. A DN deste usuário é cn=admin,dc=home,dc=com e a senha utilizada foi 123456. Estas credenciais (DN e a senha) foram utilizadas na configuração da interface GOsa e em todos os outros serviços que necessitavam de autenticação no serviço de diretório. A inclusão dos schemas básicos na DIT do OpenLDAP, necessários para a correta configuração e correto funcionamento da interface GOsa, é mostrada na Figura 12. Instalação do OpenLDAP Segundo Ubuntu (2012), o servidor OpenLDAP e os seus tradicionais utilitários de gerenciamento são encontrados nos pacotes slapd e ldap-utils, respectivamente. A instalação do slapd criará uma configuração de trabalho utilizando uma instância de banco de dados. A base DN é criada com o mesmo nome do domínio contido no arquivo /etc/hosts. Para este trabalho, o domínio lido pela instalação do slapd foi home.com. O comando para a instalação do OpenLDAP e suas ferramentas de gerenciamento foi o apt-get install slapd ldap-utils. Durante a instalação do slapd, o sistema solicita que seja Figura 12. Inclusão de schemas no OpenLDAP Para este trabalho, também foi preciso a inclusão de outros dois schemas, o dnszone.ldif e o dhcp.ldif, disponíveis no 74

Gerenciamento centralizado de servidor com OpenLDAP e interface GOsa endereço http://acacha.org/~sergi/gosa/gosa-2.7-ldifs.tar.gz (ACHACA, 2012). Após o arquivo ser descompactado, foi necessário preparar os arquivos LDIF para serem adicionados ao OpenLDAP. Segundo Ubuntu (2012), foi preciso editá-los e modificar a 1ª e 3ª linhas dos dois arquivos, retirando o par de chaves, além de adicionar o domínio cn=schema,cn=config, conforme mostra a Figura 13. na árvore de diretório do OpenLDAP através do comando ldapadd. Os comandos necessários para esta inclusão são mostrados na Figura 14. Figura 14. Inclusão de outros schemas no OpenLDAP Configuração da interface GOsa Após a instalação da interface, através do endereço http:// http://192.168.180.84/gosa, segundo Gonicus (2012) têm-se acesso à FAI (Fully Automatic Installation Instalação Totalmente Automática). A FAI verifica se as dependências do PHP5 foram instaladas, conforme mostra a Figura 15, e solicita as credenciais do usuário administrativo do OpenLDAP (DN e senha, que neste trabalho foram definidos como cn=admin,dc=home,dc=com e 123456, respectivamente). Figura 13. Preparação dos arquivos LDIF Ubuntu (2012) também instrui que sejam retiradas as sete últimas linhas dos dois arquivos, as que se iniciam com os parâmetros structuralobjectclass, entryuuid, creatorsname, createtimestamp, entrycsn, modifiersname e modifytimestamp. Após esses procedimentos, os arquivos foram embutidos Figura 15. Checagem das dependências pela FAI do GOsa A FAI também faz a checagem se os schemas básicos foram carregados corretamente no serviço de diretório, conforme mostra a Figura 16. Ajusta a raiz do diretório LDAP para o correto funcionamento do GOsa, verifica as permissões no banco de dados LDAP, cria um usuário administrativo para a interface (foi definido neste trabalho o usuário admin e a senha 123456), solicita informações de feedback e, por último, disponibiliza para download o arquivo de configuração, chamado gosa.conf, que deve ser copiado para o diretório /etc/gosa. Este arquivo deve ter seus proprietários modificados através do comando chown. Tanto para o usuário quanto para o grupo, o proprietário deve ser o 75

www-data. Também deve ter suas permissões de leitura, escrita e execução modificadas, utilizando o comando chmod, para 640. Figura 16. Checagem dos schemas pela FAI do GOsa Outra alteração foi feita na configuração para que a interface pudesse disparar a criação dos diretórios home dos usuários. Para isso, o GOsa possui a funcionalidade de executar scripts quando um determinados plug-in é chamado. Desta forma, dois arquivos foram criados no diretório /etc/gosa com os nomes create_user.sh e del_user.sh. Foi dado a eles permissão de execução para usuário e grupo. O conteúdo deles é mostrado na Figura 17. Para que o Apache tenha permissão de executar esses scripts, através do PHP, foi necessário acionar a linha wwwdata ALL=(ALL) NOPASSWD:ALL no sudo através do comando visudo. Também foi preciso que o sistema operacional reconhecesse os usuários cadastrados no serviço de diretório para que pudesse manipular o uid e gid de arquivos e diretórios. Para isso, o NSS (Name Service Switch Seletor de Nome de Serviço), que é um serviço que permite a mudança do tipo de autenticação do Linux, teve que ser configurado para consultar o OpenLDAP. O suporte a LDAP para o NSS é oferecido pelo pacote libnss-ldap, e foi instalado através do comando apt-get install libnss-ldap. Durante sua instalação, várias informações são solicitadas, dentre elas o endereço do servidor LDAP (ldap://192.168.180.84), o DN utilizado (dc=home,dc=com), a versão do LDAP (versão 3), se a senha será armazenada localmente (Yes), se a base LDAP requer login (No), o usuário administrador do serviço de diretório (cn=admin,dc=home,dc=com) e a senha deste usuário (123456). O arquivo de configuração desse mecanismo é o /etc/nsswitch.conf, onde as linhas mostradas na Figura 19 foram modificadas. Figura 19. Configuração do arquivo /etc/nsswitch.conf Figura 17. Scripts para criação e remoção do diretório home, adaptado de (TRIGO, 2012) As chamadas para esses scripts foram inseridas no arquivo /etc/gosa/gosa.conf, acionadas pelos parâmetros postcreate e postremove. As linhas mostradas na Figura 18 devem ser colocadas logo abaixo da linha <section name="administration">. Figura 18. Modificação do arquivo gosa.conf (TRIGO, 2012) Retornando para a interface GOSa, foi criada a configuração do servidor que hospedará os serviços atrelados a ele. Para tanto, clicou-se em Systems e no botão Action escolheu-se a opção Create -> Server. No campo Server name foi definido tcc-01 e fornecido o endereço da placa de rede da máquina tcc-01.home.com (00:0c:29:6a:20:75) no campo MAC-address. Clicou-se no botão OK. Desta forma foi criada a configuração de um servidor no GOsa, onde serão inseridos os serviços de DNS e DHCP. Um usuário foi adicionado para os testes de alguns serviços instalados no servidor. Para isso, após acessar a interface do GOsa, clicou-se em Users, depois em Actions e Create -> User. Na aba Generic da página de criação de usuários, inseriu-se em Last name Carrara, em First name Luis Henrique e em Login henrique. Na aba POSIX, onde estão os parâmetros referentes ao sistema de login do Linux/UNIX, clicou-se no botão Add POSIX settings e inseriu-se no campo Home directory o valor /home/henrique. Clicou-se no botão OK. Neste momento é executado o script /etc/gosa/create_user.sh, que captura o valor do Home directory para criar o diretório do usuário, além de alterar os proprietários, tanto usuário e grupo, para o valor de Login (henrique), além do sistema pedir a senha do usuário, onde foi utilizado a 123456. Serviço DNS O servidor DNS utilizado neste trabalho foi o bind9, além 76

Gerenciamento centralizado de servidor com OpenLDAP e interface GOsa do aplicativo ldap2zone. Segundo Die.net (2012), esta ferramenta permite a conversão das informações armazenadas no esquema dnszone, na base LDAP, em arquivos de configuração do bind9. Este dois pacotes foram instalados através do comando apt-get install bind9 ldap2zone. Uma alteração teve quer ser feita em um dos arquivos instalados pelo pacote ldap2zone. Seu arquivo de configuração criado por padrão era o /etc/default/ldap2zone/default, porém o ldap2zone lê o arquivo /etc/defaul/ldapzone. O conteúdo do primeiro arquivo foi copiado para o segundo. As informações mostradas na Figura 20 foram modificadas no arquivo /etc/default/ldap2zone. Figura 22. Checagem do DNS com o nslookup Figura 20. Configuração do ldap2zone Desta forma, tanto o domínio quanto o host criados através da interface GOsa passaram a operar no servidor de DNS. O conteúdo mostrado na Figura 21 foi modificado no arquivo /etc/ldap/ldap.conf. Serviço DHCP O servidor de DHCP utilizado neste trabalho foi o desenvolvido pelo ISC (Internet Systems Consortium). Além do aplicativo principal, também se fez necessário o módulo que permite a consulta ao serviço de diretório. O comando utilizado para a instalação foi o apt-get install isc-dhcp-server isc-dhcp-server-ldap. Segundo Trigo (2012), adaptado para este trabalho, no arquivo de configuração do DHCP, o /etc/dhcp/dhcpd.conf, devem ser incluídas as linhas mostradas na Figura 23. Figura 21. Configuração do arquivo /etc/ldap/ldap.conf As informações extraídas da base LDAP são armazenadas em um arquivo, que deve ser chamado na sessão include do /etc/bind/named.conf por include "/etc/bind/named.conf.ldap2zone";. Para criar as configurações do DNS, a interface GOsa foi acessada, clicou-se em Systems e depois no servidor já configurado (tcc-01), na aba Services e no botão Actions escolhe-se a opção Create -> DNS Service. Utilizou-se o botão Add e em Zone name foi inserido o domínio home.com, em Network address 192.168.180.0, em Net mask foi escolhida a opção 255.255.255.0 (Class C), em Primary DNS server for this zone o IP 192.168.180.84 e em Mail address o endereço root@home.com. Clicou-se no botão New entry, onde foi definido o endereço tcc01.home.com como registro do tipo A, com o IP 192.168.180.84. As informações armazenadas no serviço de diretório foram transferidas para a configuração do bind9 com a execução do comando ldap2bind e entraram em operação com o reinício do bind9 através do comando service bind9 restart. O teste de operação do DNS foi feito utilizando-se o nslookup e pode ser conferido na Figura 22. Figura 23. Configuração do DHCP Também se fez necessário a criação do arquivo /var/log/dhcp-ldap-startup.log, além da mudança dos proprietários deste arquivo, tanto do usuário quanto do grupo, para o manipulador do DHCP, o dhcpd. O parâmetro ldapmethod possui duas variações: na static, o servidor DHCP só lê as informações armazenadas no serviço de diretório ao ser iniciado; na dynamic, o servidor lê as informações armazenadas no SD toda vez que chegar uma requisição de um cliente. Para criar as configurações do DHCP, a interface GOsa foi acessada, clicou-se em Systems e depois no servidor já configurado (tcc-01), na aba Services e no botão Actions escolhe-se a opção Create -> DHCP Service. Na linha de Global options, clicou-se Insert new DHCP section, escolheu77

se a opção Subnet no combo Section e clicou-se em Create. Na tela de configuração do DHCP foi inserido em Network address o endereço 192.168.180.0, em Router o valor 192.168.180.1 (gateway da rede), em Net mask foi utilizado 255.255.255.0, em Broadcast address foi inserido 192.168.180.255, foi habilitada a opção Range for dynamic address assignment e entrou-se com o range 192.168.180.80 192.168.180.82, em Domain foi inserido o home.com e foi adicionado em DNS server o IP 192.168.180.84. Ao reiniciar o serviço do DHCP através do comando service isc-dhcp-server restart, as configurações criadas na interface GOsa aparecem no arquivo de log, visualizado pelo comando tail -f /var/log/dhcp-ldap-startup.log, e são apresentadas na Figura 24. A ativação do módulo LDAP foi realizada no arquivo /etc/proftpd/modules.conf, com a adição da linha LoadModule mod_ldap.c. A configuração de acesso à base LDAP foi feita através do arquivo /etc/proftpd/ldap.conf, com a adição das linhas mostradas na Figura 27. Figura 27. Configuração de consulta ao LDAP do proftpd Após reiniciado o serviço do proftpd, através do comando service proftpd restart, foi feito um teste com o cliente FTP do Windows, que, após fornecer o usuário henrique e senha 123456, foi dado acesso ao home do usuário. O log gerado no arquivo /var/log/auth.log, mostrado na Figura 28, confirma o acesso do usuário. Figura 24. Conteúdo do arquivo dhcp-ldap-startup.log Figura 28. Acesso ao FTP no arquivo /var/log/auth.log Serviço Proxy Figura 25. Logs do DHCP em /var/log/syslog Analisando os dados apresentados, na primeira linha foi feita a requisição (DHCPREQUEST) de um endereço IP pelo host denominado win7-01 através da interface de rede eth0. Na segunda linha, há a confirmação da entrega do IP (DHCPACK) pelo servidor ao computador requisitante. Desta forma, as configurações DHCP inseridas pela interface GOsa no serviço de diretório entraram em operação. O proxy utilizado foi o Squid, na versão 3, que foi instalado através do comando apt-get install squid3. A configuração do Squid foi realizada através do arquivo /etc/squid3/squid.conf, onde foram adicionadas as linhas mostradas na Figura 29. O Squid foi reiniciado com o comando service squid3 restart para que as configurações entrassem em operação. Serviço de FTP Neste trabalho foi utilizado o proftpd e seu módulo de autenticação em base LDAP, o proftpd-mod-ldap. A instalação destes pacotes foi realizada através do comando apt-get install proftpd proftpd-mod-ldap. A opção standalone foi escolhida durante a instalação. As opções mostradas na Figura 26 foram habilitadas no arquivo de configuração principal do proftpd, o /etc/proftpd/proftpd.conf. Figura 26. Configuração do proftpd Figura 29. Configuração do Squid A linha http_access allow autenticacao deve ser incluída logo acima da linha http_access deny all para garantir que a navegação seja permitida apenas para usuários autenticados. O Squid foi reiniciado com o comando service squid3 restart. Um teste foi realizado com o navegador Internet Explorer 9, configurado com o IP do proxy 192.168.180.84 e a porta 3128. O navegador exigiu autenticação e, ao ser fornecido o usuário henrique e senha 123456, a navegação foi permitida. 78

Gerenciamento centralizado de servidor com OpenLDAP e interface GOsa erros e mais simples de ser delegada para usuários sem tanto conhecimento ou experiência com linha de comando ou mesmo que não são os administradores do sistema. Assim, pode-se concluir que o sistema formado pelo OpenLDAP como serviço de diretório e GOsa como front-end para manipulação da árvore de diretório, instalado através do apt-get, mostrou-se como uma alternativa viável na administração centralizada de servidores, uma vez que permitiu a manipulação de usuários e serviços em uma única interface. Apesar de pouco conhecida no Brasil, a interface GOsa possui uma série de plug-ins que lhes fornece o controle de vários serviços, desde o gerenciamento de fax, ligações telefônicas através do asterisk, usuários e grupos samba, certificados digitais, dentre outros. Futuramente, pretende-se estender as potencialidades deste trabalho, com a implantação, em ambiente de produção, de um sistema de gerenciamento centralizado de usuários utilizando-se serviço de diretório e GOsa com recursos de autenticação segura (SASL+TLS) entre os serviços e o OpenLDAP, além de realizar o levantamento de todos os atributos que podem ser inseridos no cache do serviço de diretório, aumentando ainda mais a eficiência desse sistema. Também pretende-se implementar um servidor de email e de telefonia (asterisk) com usuários gerenciados de forma centralizada, além do nagios para monitoramento de todos os serviços em operação. Os logs extraídos do arquivo /var/log/squid3/access.log, mostrados na Figura 30, indicam o processo de autenticação. Figura 30. Acesso ao proxy no arquivo /var/log/squid3/access.log Na primeira linha, a navegação é negada (TCP_DENIED) até o fornecimento de usuário e senha válidos. Após isso, o navegador acessa a página e os logs passam a refletir o usuário que realiza o acesso (henrique). IV. CONCLUSÃO Pelo o estudo de caso apresentado, o usuário (henrique) criado pelo administrador do servidor no serviço de diretório ficou disponível para autenticação centralizada nos serviços de FTP e proxy. O administrador também pôde armazenar as informações da zona de DNS criada (home.com) e seus registros, além da classe de IP (192.168.180.0), cujos endereços seriam disponibilizados pelo DHCP aos clientes do servidor. O armazenamento de tais informações foi possível graças à expansão da capacidade do OpenLDAP através do carregamento de schemas, que trouxeram a estrutura padronizada necessária para seu armazenamento. Desta forma, o profissional deixou de utilizar os mecanismos individuais de cada serviço para autenticar os usuários em um único banco de dados, o que facilitou a administração. Também foi possível verificar que a instalação do OpenLDAP pôde ser feita sem a necessidade do arquivo de configuração slapd.conf, o que trouxe dois diferenciais para os administrador: não foi necessário reiniciar o OpenLDAP a cada mudança de sua configuração ou inserção de novos schemas, como ocorria no método anterior e, também, foi possível manter o sistema operacional sempre atualizado, dentro dos seus padrões de instalação, o que facilita muito as atualizações automatizadas realizadas pelo Ubuntu através do apt-get. A configuração para que os serviços consultassem o OpenLDAP não foi uma tarefa trivial devido ao grande número de modificações nos arquivos. Porém, uma vez implementado, o sistema mantém-se estável e funcional, sem grandes intervenções do administrador. A interface GOsa, ao servir de front-end na manipulação do OpenLDAP, permitiu a criação não só de usuário e grupo na árvore de diretório, como também o cadastramento de zona DNS, seus registros e classe de IP para o DHCP. Desta forma, tornou-se mais simples a interação com a configuração desses serviços, fazendo essa tarefa mais rápida, menos sujeita a REFERÊNCIAS ACHACA. Gosa. Disponível em: < http://acacha.org/mediawiki/index.php/gosa#instal.c2.b7l aci.c3.b3_de_gosa_2.7_pas_a_pas_a_ubuntu_server_11. 10>. Acesso em: 25 set. 2012. DIE.NET. Ldap2zone(1) - Linux man page. Disponível em: < http://linux.die.net/man/1/ldap2zone>. Acesso em: 25 set. 2012. GONICUS. GOsa Documentation. Disponível em: <https://oss.gonicus.de/labs/gosa/wiki/documentation>. Acesso em: 25 set. 2012. OPENLDAP. OpenLDAP Software 2.4 Administrator's Guide. Disponível em: <http://www.openldap.org/doc/admin24>. Acesso em: 25 set. 2012. SUNGAILA, M. Autenticação Centralizada com OpenLDAP: Integrando Serviços de Forma Simples e Rápida. São Paulo: Novatec Editora, 2008. 231 p. TRIGO, C. H. OpenLDAP: Uma Abordagem Integrada. São Paulo: Novatec Editora, 2007. 239 p. TRIGO, Clodonil Honório. Livro OpenLDAP: Uma abordagem integrada, 6-17 de ago. de 2012. 372 p. Notas de aula. TUTTLE, S. et al. Understanding LDAP: Design and Implementation. [S.l.]: RedBooks, 2004. 774 p. UBUNTU. Ubuntu Server Guide. Disponível em: < http://help.ubuntu.com/12.04/serverguide>. Acesso em: 25 set. 2012. 79