Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Quando é abordado um serviço de diretórios, a primeira ideia que surge é uma base de dados em que podem ser armazenadas informações de usuários. De certa forma, isso é verdade. Em um servidor de diretórios, podem ser armazenados dados de usuários que poderão ser recuperados a qualquer momento, assim como em um SGBD (Sistema de Gerenciamento de Banco de Dados) convencional, como Oracle e PostgreSQL.

O protocolo LDAP (Lightweight Directory Access Protocol) ou Protocolo Leve de Acesso a Diretório trata-se, como o nome já diz, de um protocolo que rege a forma de acesso a serviços de diretórios e seus respectivos clientes. Em outras palavras, fornece a comunicação entre usuários e serviços de diretórios, centralizando deste modo toda uma base de dados de autenticação.

Dentre as funcionalidades do LDAP, o que pode ser considerado como um destaque principal é a capacidade de oferecer a autenticação de usuários usando sua base de dados. Com ela, podem-se acessar as referências de todas as informações dos usuários da rede em um único lugar, permitindo também que todos os protocolos e serviços de diretórios vinculados a ele possam utilizar seus dados para a autenticação de seus clientes. Isso gera o que se denomina de centralização, pois a autenticação de todos os serviços de rede será concentrada em uma única árvore de informações e, como consequência, facilita o trabalho do gerente de redes.

Para esclarecer melhor o que é um diretório, pode-se comparar com uma lista telefônica, onde se procura, por exemplo, o telefone de uma pizzaria. Nesse caso, através do telefone você irá conseguir o caminho até o destino da pizzaria. Portanto, pode-se definir um diretório como um serviço de armazenamento hierárquico de informações com o objetivo principal de facilitar a pesquisa e a recuperação dessas informações.

De forma semelhante, um diretório pode ser uma lista de informações sobre objetos organizados ou catalogados em uma ordem, e que fornece o acesso aos dados dos objetos. O diretório permite que usuários ou aplicações possam encontrar recursos no ambiente com características necessárias para um tipo de tarefa particular.

Há algumas comparações equivocadas sobre o serviço de diretórios, sendo descritas algumas delas abaixo:

• Banco de dados: um banco de dados é criado para otimizar a leitura e escrita de dados com o mesmo grau de eficiência. Um diretório, ao contrário, é otimizado apenas para leitura, podendo ocasionalmente inserir novos dados. Seu sistema de transações é muito simples quando comparado a um sistema de banco de dados;

• Sistema de arquivos: O sistema de arquivos possui otimizações para manipulação de arquivos. Um arquivo grande não precisa ser completamente carregado na memória, sendo possível apontar para apenas uma região naquele instante. O diretório não possui esse tipo de otimização;

• FTP e servidores web: seguem a filosofia de ler muito e gravar pouco. Mas ao ser analisada a questão do tamanho do arquivo, observa-se o mesmo problema do item anterior, o tamanho do arquivo a ser carregado. Servidores web são extensíveis, podem ser usados como base de desenvolvimento de aplicações mais complexas. Um diretório, por sua vez, não possui essa natureza de extensão.

Nos itens seguintes serão abordados alguns conceitos importantes para um bom conhecimento dos serviços de diretórios.

O Serviço de Diretórios

Entre um serviço de diretórios e um SGBD existem diferenças importantes que devem ser observadas:

• Otimização de leitura: um gerenciador de base de dados deve levar em consideração uma série de operações de escrita e travamento de registros, ao passo que os diretórios devem disponibilizar prontamente os dados solicitados;

• Hierarquia: uma base de dados possui tabelas com campos e registros, ao passo que no diretório cria-se uma estrutura em formato de árvore, de modo que cada registro será armazenado dentro de um ramo específico da árvore;

• Modelo distribuído para armazenamento de informações: com base na raiz da árvore, podem-se criar estruturas independentes para cada unidade (ramo);

• Forte padronização: os dados armazenados em um diretório seguem uma padronização, normalmente estabelecida em uma RFC;

• Capacidade avançada de pesquisa: efetuar pesquisas pelo seu conteúdo de forma exata ou aproximada, levando em consideração até mesmo variações fonéticas.

Em alguns casos, uma análise deverá ser feita antes de escolher entre o uso de um Diretório ou de um SGBD. Assim, pode-se saber quem terá melhor desempenho, afinal o SGBD tem estrutura muito similar a servidores de Diretórios, compartilhando muitas características como pesquisas rápidas e base de fácil personalização.

Neste contexto, os seguintes aspectos devem ser observados:

• Volume de dados: Servidores de diretórios normalmente não têm suporte a métodos avançados para controle de transações ou esquemas de rollback, sendo a baixa performance em escrita seu ponto fraco;

• Hierarquia: A estrutura em forma de árvore permite mobilidade aos dados que podem ser agrupados por departamentos ou mesmo por unidades geograficamente diferentes;

• Administração descentralizada: Possibilita delegar a administração de parte do Diretório a outros usuários (ramos, unidades), podendo assim estar localizados em outros servidores.

X.500

O X.500 é um padrão de protocolos de serviços de diretórios utilizado em redes de computadores, tendo sido elaborado para trabalhar em cima do modelo OSI (veja a Nota DevMan 1) e incorporado ao pacote de protocolos do mesmo. Designado para dar suporte ao padrão X.400, que define a troca de mensagens eletrônicas entre os usuários da rede local, sua função é prover serviços de diretórios para a rede centralizando a base de dados dos usuários em um servidor.

O protocolo de acesso a diretórios – DAP (Directory Access Protocol) faz parte das especificações do padrão X.500, tendo sido desenvolvido para trabalhar junto a todas as camadas do modelo OSI, e tinha por objetivo definir o acesso de usuários aos serviços de diretórios que seu padrão provia.

Assim como o OSI e o X.500, o DAP foi desenvolvido antes do advento da Internet e originalmente não foi preparado para trabalhar com o TCP/IP, visto que a aplicação do mesmo, além de ser de difícil implementação, gerava aplicações complexas e lentas. Além do mais, o estilo da organização da árvore de diretórios do X.500 não foi preparado para a utilização de diretórios distribuídos.

Quando se trata de redes de computadores, tudo gira em torno dos protocolos, a Internet, e-mail, intranets, transferência de arquivos, acessos a diretórios e outras aplicações providas pela pilha TCP/IP. A grande vantagem da utilização de protocolos se resume na compatibilidade que eles oferecem, tanto entre hardware quanto entre software de diversos fabricantes, o que os torna compatíveis. Um exemplo prático disso é a possibilidade de se estabelecer a comunicação entre Sistemas Operacionais diferentes, ou partindo para o nível de hardware, que é, por exemplo, fazer com que placas de rede de fabricantes distintos possam se comunicar.

Já é aceito que a implementação do Modelo OSI utiliza uma gama maior de recursos de rede, onde se trafega uma grande quantidade de dados desnecessários, e a pilha TCP/IP, por sua vez, trabalha de forma mais leve, exigindo menos dos recursos da rede, tanto que, com a disseminação da Internet, o TCP/IP passou a ser usado como um padrão internacional. O sucesso foi tanto que os protocolos do padrão X.500 foram adaptados para que as redes TCP/IP pudessem trabalhar com os servidores X.500. No entanto, posteriormente percebeu-se a necessidade da criação de protocolos que se encaixassem melhor em suas características.

O LDAP foi criado como uma alternativa ao DAP, para prover acesso aos serviços de diretórios do X.500 pelos protocolos da pilha TCP/IP. O LDAP é mais fácil de ser implementado do que o DAP, além de exigir menos dos recursos da rede e memória. Ele foi desenvolvido, e não adaptado (como o DAP), para aplicações TCP/IP. Deste modo, o LDAP obteve um maior desempenho. Por esses motivos, recebeu o nome Lightweight Directory Access Protocol (protocolo leve de acesso a diretórios), que é o nome de seu antecessor acrescentado de Lightweight (leve).

Posteriormente foram criados servidores de diretórios voltados para o TCP/IP e o LDAP. O servidor Slapd (Stand-alone LDAP daemon) foi escolhido como a melhor opção. Com sua utilização, passa a se colocar em prática um software provedor de serviços de diretórios específicos para o TCP/IP e o LDAP, deixando de lado o X.500, que é uma mera adaptação de um padrão desenvolvido para o modelo OSI. Com isso, há um ganho em desempenho, funcionalidades e melhor integração com o LDAP.

Deste modo, o LDAP passou a ser a melhor forma de se obter o acesso a serviços de diretórios, e foi padronizado em julho de 1993 na RFC 1487.

LDAP

O serviço de Diretórios é executado em um servidor especializado, onde todas as informações contidas são consultadas obedecendo a uma série de convenções definidas inicialmente pelo protocolo X.500. Este protocolo determinou uma série de informações e controles devido ao seu desenvolvimento ter sido baseado no modelo OSI, porém não serão abordados neste artigo.

O protocolo LDAP está em sua versão 3 (LDAPv3), publicada no final da década de 1990, e acrescenta melhorias em relação a sua versão anterior, algumas delas listadas a seguir:

• Autenticação e serviços de segurança de dados via SASL (veja a Nota DevMan 2);

• Autenticação via certificados digitais e serviço de segurança de dados via TLS (SSL) – veja a Nota DevMan 2;

• Internacionalização usando a tabela UNICODE;

• Resolução de schemas;

• Extensibilidade;

• Dentre outras melhorias.

Imagine o cenário de uma empresa com 100 funcionários, onde toda base de e-mail (contatos do outlook) é compartilhada com todos eles. Assim, sempre que um novo contato é adicionado, o administrador deverá informar a todos os usuários, repassando a informação de alteração via e-mail. Esse processo pode ser centralizado em um servidor de Diretórios. Dessa forma todos os usuários serão atualizados ao mesmo tempo.

Há algumas características a serem consideradas para adoção dos serviços de diretórios. Dentre elas, pode-se citar:

• Base de autenticação para serviços de rede;

o Login de rede (autenticação em um servidor de Domínio);

o E-mail (pop, smtp, imap);

o Proxy (autenticação para uso da Internet);

o Intranet (uso de aplicações e compartilhamentos internos);

• Permissão para administrar parte do Diretório (direitos administrativos centralizados; dessa forma as permissões de acesso são referenciadas no LDAP).

Estrutura do servidor de Diretórios

No LDAP, as entradas do Diretório são organizadas em uma estrutura semelhante a uma árvore, lembrando a estrutura de um DNS ou do sistema de diretórios do GNU/Linux. Tal estrutura foi desenvolvida para representar limites geográficos ou organizacionais.

Quando se pensa em uma estrutura física, como exemplo, entradas representando países, esses devem obrigatoriamente aparecer no topo da estrutura, conforme apresentado na Figura 1.

Figura 1. Exemplo de estrutura de Diretórios, dois níveis representando países.

Abaixo dessas estruturas deverão existir entradas representando os Estados, como pode ser observado na Figura 2.

Figura 2. Exemplo de estrutura de Diretórios, com subníveis.

Em seguida, o administrador poderá criar as unidades organizacionais que serão armazenadas no Diretório. Toda estrutura hierárquica criada pode representar unidades da empresa como matrizes, filiais e até mesmo divisões internas como usuários, grupos, impressoras, documentos, ou quaisquer outras entradas necessárias. Observa-se um exemplo de modelo de diretório na Tabela 1.

Tabela 1. Modelo de Diretório.

Na Figura 3 tem-se um exemplo da representação de uma árvore de diretórios construída pela forma tradicional de nomes, considerando uma estrutura geográfica e organizacional.

Figura 3. Modelo de Diretórios baseado na forma tradicional de nomes.

A forma de armazenamento dos dados em um servidor de Diretórios segue a hierarquia dos objetos a que pertence a entrada. Na Listagem 1, pode ser observado que o objeto “Flavio Reis” pertence a “NTI”, que por sua vez pertence a “Empresa”, até que chegue ao objeto de maior valor na hierarquia.

Listagem 1. Exemplo de resultado em uma estrutura hierárquica.

  cn=Flavio Reis, ou=NTI, o=Empresa, st=Rio de Janeiro, c=br 

Esse tipo de identificação é chamado de DN (Distinguished Name) ou nome único. O DN deverá indicar todos os ramos da árvore LDAP, desde a base (c=br) até a parte final, ou seja, a identificação do usuário. Outro ponto importante é que o DN deve sempre ser único em todo o Diretório.

Outra forma de construir uma árvore de Diretórios é utilizando componentes de domínio Internet (DC). Essa abordagem tem se tornado cada vez mais popular, pois permite que serviços de Diretórios sejam localizados utilizando um DNS. Um exemplo pode ser observado na Figura 4, onde são alterados os componentes inicias para construção da árvore, alterando os atributos (c=country) e (o=organization) para objetos (dc=domainComponent), replicando o formato DNS. Outra modificação é feita no usuário, inserindo a forma de identificação UID.

Figura 4. Modelo de Diretórios baseado em DNS.

A forma de armazenamento dos dados em um servidor de Diretórios seguindo o formato DNS fica um pouco diferente, conforme pode ser observado no exemplo da Listagem 2.

Listagem 2. Identificando o usuário dentro da estrutura DNS.

  uid=freis, ou=usuarios, dc=empresa, dc=com, dc=br 

Além da possibilidade de estruturação de uma rede de computadores como mostrado anteriormente, o LDAP ainda permite controlar quais atributos são necessários, ou quais são permitidos, para a entrada de dados por meio de um atributo especial chamado “objectClass”. Dependendo do conteúdo desse atributo, um registro deverá obedecer às regras definidas em seu schema.

OpenLDAP

O OpenLDAP é uma aplicação multiplataforma, ou seja, independente de sistema operacional. Deste modo, várias distribuições GNU/Linux já incluem o pacote do aplicativo, que inicialmente foi desenvolvido pela Universidade de Michigan. O OpenLDAP trouxe as seguintes características como principais:

• Suporte a IPv4 e IPv6;

• Autenticação (Cyrus Sasl-Kerberos V, GSSAPI, Digest-MD5);

• Segurança no transporte – SSL e TLS;

• Controle de acessos;

• Escolha entre bancos de dados (DBD ou HDB);

• Capacidade de atender a múltiplos bancos de dados simultaneamente;

• Alta performance em múltiplas chamadas;

• Replicação de base, oferecendo redundância.

O projeto OpenLDAP é composto pelos seguintes elementos:

• SLAPD (Stand Alone LDAP Daemon), servidor que controla as requisições dos clientes;

• SLURPD (Stand Alone LDAP Update Replication Daemon), servidor utilizado para replicação da base de dados;

• Bibliotecas diversas de implementação do protocolo LDAP;

• Ferramentas, utilitários diversos e clientes de exemplo.

A aplicação possui basicamente dois arquivos de configuração, que são, respectivamente:

• slapd.conf - configuração do daemon;

• ldap.conf - configuração para acesso dos clientes à base.

O OpenLDAP possui alguns arquivos chamados de schemas. Um esquema é um conjunto de regras que define atributos, classes de objetos, e controles, indicando onde cada dado pode ser armazenado. Alguns autores abordam um schema como sendo uma estrutura de objetos que especifica a lista total de atributos permitidos e necessários para uma entrada de dados no serviço de diretório.

Os schemas permitem manter a consistência entre os dados. Uma importante característica desses arquivos é serem extensíveis e, assim, podem-se adicionar mais atributos ou classes em função de novas necessidades. Para usar um schema é necessário incluí-lo no arquivo de configuração slapd.conf.

Os schemas podem definir:

• Quais as classes de objetos (object classes) podem ser inseridas num diretório;

• Quais os atributos de uma determinada classe de objetos;

• Os valores possíveis para os atributos.

Se um objeto (entrada) não obedecer às regras do schema, esse não pode ser inserido no diretório. Portanto, cada entrada estará condicionada a uma hierarquia de armazenamento dos dados na base LDAP. Isto é especificado através do Distinguished Name (DN).

Instalação do Servidor OpenLDAP

Antes de instalar o sistema, deve-se efetuar um estudo aprofundado e projetar o servidor LDAP, observando quantos usuários farão uso do sistema, ou quantas filiais, por exemplo. Neste tópico serão apresentados três tipos de casos diferentes.

No primeiro caso, talvez o mais tradicional, assume-se como base que a implementação do servidor LDAP será feita em uma empresa simples, sem filiais, ou apenas em um servidor, sem acesso das filiais externas ao parque computacional.

Pode-se observar um exemplo na Figura 5, onde os clientes irão efetuar as pesquisas diretamente no servidor. O cliente solicita uma pesquisa e o servidor responde. É um tipo de estrutura simples, como mencionado.

Figura 5. Estrutura de conexão LDAP – Primeiro Caso.

No segundo caso, toda a organização usa o LDAP. Assim, quando os usuários da matriz precisam de alguma informação da filial, o servidor LDAP da matriz faz uma pesquisa no servidor da filial (pesquisa feita por referência) e retorna o valor para o cliente.

Para o exemplo, pode-se imaginar uma empresa que tem Matriz no Rio de Janeiro e Filial em Minas Gerais. Todos os servidores estão concentrados na matriz, e qualquer informação requerida pelos usuários das filiais deverá enviar uma solicitação ao servidor LDAP localizado na matriz. Deste modo ele irá responder à filial.

Ao analisar a situação, verifica-se que a filial sempre procura a mesma informação, que na maioria das vezes, está relacionada com a própria filial. Para resolver esse problema, pode-se criar um servidor LDAP em que uma parte da árvore fica na matriz (Rio de Janeiro) e outra parte da árvore fica na filial (Minas Gerais). Com essa estrutura, todas as informações importantes para a filial serão processadas no servidor local. Dessa forma, as pesquisas feitas pelos clientes da filial serão efetuadas localmente, obtendo ganho nas respostas. Caso a pesquisa solicitada não tenha resposta no servidor local, o próprio servidor se encarrega de efetuar uma busca no servidor da matriz e, em seguida, responder ao cliente. Observa-se esse tipo de conexão na Figura 6.

Figura 6. Estrutura de conexão LDAP – Segundo Caso.

No terceiro caso, utilizam-se servidores com redundância. Isto é, para todos os dados cadastrados no servidor, serão feitas réplicas em outro servidor LDAP. Deste modo, em caso de problemas do servidor principal, é possível iniciar o servidor secundário, mantendo as informações disponíveis aos usuários. Vale ressaltar que os casos 2 e 3 que foram apresentados podem ser unificados, mantendo redundância de dados. Seguem algumas vantagens de se trabalhar com servidores com redundância:

• Fazer cópia parcial ou total do diretório;

• Melhorar o desempenho e a confiabilidade;

• Aproximar os dados dos clientes em caso de filiais;

• Distribuir melhor a carga de processamento dos servidores;

• Garantir redundância do serviço, minimizando os efeitos de falhas no servidor.

Na Figura 7 pode-se observar um exemplo desse caso.

Figura 7. Estrutura de conexão LDAP – Terceiro Caso.

Após essas análises, pode-se iniciar o processo de instalação do OpenLDAP. Para os exemplos demonstrados neste artigo será utilizado o Sistema Operacional GNU/Linux Debian Squeeze. Os pacotes necessários para sua instalação são:

• libldap: biblioteca ldap;

• slapd: daemon do servidor ldap;

• ldap-utils: utilitários para o OpenLDAP (comandos de busca, inserção, atualização);

• migrationtools: conjunto de scripts em Perl utilizados para migrar a base de usuários e grupos existentes no sistema GNU/Linux para a base LDAP;

• phpldapadmin, apache2 e php5: utilizados para gerência via Web.

Na Listagem 3 pode-se verificar como efetuar a instalação do OpenLDAP nos sistemas GNU/Linux Debian ou derivados.

Listagem 3. Instalando os pacotes necessários.

  #aptitude install libldap-2.4-2 slapd ldap-utils 
  #aptitude install migrationtools phpldapadmin apache2 php5 

BerkeleyDB

Todas as informações do diretório devem ser armazenadas em algum tipo de base. E para isso, o LDAP possui dois bancos de dados nativos, LDBM e BerkeleyDB. Alguns autores apontam o segundo como melhor quando analisado o desempenho. Em distribuições baseadas em GNU/Linux Debian, a instalação do BerkeleyDB pode ser feita conforme apresentado na Listagem 4.

Listagem 4. Instalando com BerkeleyDB.

  #aptitude install libdb4.8++-dev 

OpenSSL e Cyrus

Na maioria das vezes, o LDAP é utilizado para armazenar dados de usuários, inclusive a senha de autenticação. Com isso, tem-se a necessidade de um nível de segurança extra. E para aumentar a segurança no transporte dos dados, é possível criptografá-los de forma que, mesmo sendo interceptados por terceiros, não seja possível ver o que está sendo transmitido.

Para implementar esse nível de segurança, será configurado o OpenSSL, sendo sua instalação também simples, pois a maioria das distribuições trazem o pacote em seu repositório oficial. Para aumentar ainda mais a segurança dos dados pode-se instalar o cyrus (libsasl), que é uma opção de autenticação e criptografia para o OpenSSL. Feito a instalação, pode iniciar a migração dos dados. A Listagem 5 apresenta como instalar o OpenSSL no GNU/Linux Debian.

Listagem 5. Instalando o OpenSSL no Debian.

  #aptitude install openssl libsasl2-2 

No entanto, antes de iniciar a migração dos dados de usuários e grupos do sistema, deve-se ajustar algumas configurações no OpenLDAP. O primeiro passo é gerar a senha de administrador da base LDAP. Assim, digite o comando ldappasswd e copie o valor retornado, pois ele será usado posteriormente. A Listagem 6 apresenta como fica o shell quando executado o comando para gerar a senha.

Listagem 6. Gerando a senha de admin do OpenLDAP.

  #ldappasswd
  #ldappasswd:
  {SSHA}lt/pthgyeFA4NhGdzJ+qlqMuAGi267dq 

Nas versões anteriores, o LDAP criava um arquivo chamado slapd.conf em /etc/init.d/ldap, mas nas versões mais atuais ele é localizado em /usr/share/slapd. Com isso, faça uma cópia do arquivo para /etc/ldap, alterando o arquivo de acordo com a necessidade. Esse é um arquivo genérico, usado como exemplo de configuração. A senha gerada anteriormente deverá ser inserida na linha rootpw. Na Listagem 7 observa-se um exemplo do arquivo slapd.conf já com o valor do rootpw alterado.

Listagem 7. Exemplo do arquivo slapd.conf.

  include      /etc/ldap/schema/core.schema
  include      /etc/ldap/schema/cosine.schema
  include      /etc/ldap/schema/nis.schema
  include      /etc/ldap/schema/inetorgperson.schema
  allow         bind_v2
  pidfile     /var/run/slapd/slapd.pid
  argsfile    /var/run/slapd/slapd.args
  loglevel    none
  modulepath  /usr/lib/ldap
  moduleload  back_bdb
  sizelimit 500
  tool-threads 1
  backend      bdb
  database   bdb
  suffix      "dc=reisfa,dc=eti,dc=br"
  rootdn      "cn=admin,dc=reisfa,dc=eti,dc=br"
  rootpw      {SSHA}lt/pthgyeFA4NhGdzJ+qlqMuAGi267dq
  directory   "/var/lib/ldap"
  dbconfig set_cachesize 0 2097152 0
  dbconfig set_lk_max_objects 1500
  dbconfig set_lk_max_locks 1500
  dbconfig set_lk_max_lockers 1500
  index      objectClass eq
  lastmod      on
  checkpoint   512 30
  access   to   attrs=userPassword,shadowLastChange
      by dn="cn=admin,dc=reisfa,dc=eti,dc=br" write
      by anonymous auth
      by self write
      by * none
  access to dn.base="" by * read
  access to *
     by dn="cn=admin,dc=reisfa,dc=eti,dc=br" write
     by * read 

Para gerar uma nova estrutura de configuração do OpenLDAP, devem ser seguidos os passos apresentados na Listagem 8.

Listagem 8. Gerando uma nova estrutura para o OpenLDAP.

  # /etc/init.d/slapd stop
  # cd /etc/ldap
  # mv slapd.d slapd.d.backup
  # mkdir slapd.d
  # slaptest -f slapd.conf -F slapd.d
  # chown -R openldap:openldap slapd.d
  # /etc/init.d/slapd start 

Para que o migrationtools possa efetuar as alterações de forma correta, o arquivo migrate_common.ph deverá ser modificado. Dessa forma, edite o arquivo através de um editor de textos, como exemplo o vim, e localize as linhas $DEFAULT_MAIL_DOMAIN e $DEFAULT_BASE, que devem ter seus respectivos valores modificados conforme o slapd.conf. Observe um exemplo na Listagem 9.

Listagem 9. Exemplo de configuração do arquivo migrate_common.ph.

  # vim /usr/share/migrationtools/migrate_common.ph
  $DEFAULT_MAIL_DOMAIN = "reisfa.eti.br";
  $DEFAULT_BASE = "dc=reisfa,dc=eti,dc=br"; 

LDIF

Alguns administradores de sistemas LDAP preferem usar arquivos de texto puro para informar dados de configuração dos servidores em vez de alguns bits de armazenamento na base de dados. O formato de troca de dados LDAP é conhecido como LDIF (LDAP Data Interchange Format), definida pela RFC 2849, sendo um formato padrão de arquivos de texto para armazenar informações de configuração do LDAP e conteúdo dos diretórios. Em sua forma básica, um LDIF é:

• Um conjunto de entradas separadas umas das outras por linhas em branco;

• Um mapeamento de nomes de atributos e valores;

• Um conjunto de diretivas que instruem o analisador sobre como processar a informação.

As duas primeiras características fornecem exatamente o que é preciso para descrever o conteúdo de um diretório DAP. Arquivos LDIF são frequentemente utilizados para importar novos dados para seu diretório ou fazer mudanças de dados existentes, facilitando assim a manutenção dos mesmos. Os dados no arquivo de LDIF deverão obedecer às regras de schemas de seu diretório LDAP. Cada item que é adicionado ou alterado no diretório é verificado segundo o esquema para correção. Uma violação do esquema ocorre quando os dados não correspondem às regras existentes. Observa-se o exemplo de uma parte de um arquivo LDIF na Listagem 10.

Listagem 10. Parte de um arquivo LDIF.

  dn: uid=reisfa,ou=People,dc=reisfa,dc=eti,dc=br
  uid: reisfa
  cn: Flavio Reis
  objectClass: account
  objectClass: posixAccount
  objectClass: top
  objectClass: shadowAccount
  userPassword: {crypt}$6$fBWxv7O9$LWFyYlfCk79LiCdi9cVU48YOEULTnDwpuKmqVTrmGa3i/4hcOnWyIiStCb/JZkbVmvdL0ZwR8BHr28TWYRQt51
  shadowLastChange: 15167
  shadowMax: 99999
  shadowWarning: 7
  loginShell: /bin/bash
  uidNumber: 1000
  gidNumber: 1000
  homeDirectory: /home/reisfa
  gecos: Flavio Reis,,, 

Após uma breve descrição sobre LDIF, podem-se gerar os arquivos que serão usados para importar os dados para a base de usuários do sistema. Para isso, serão adotados os scripts do migrationtools. Os passos descritos na Listagem 11 criam as LDIFs de usuários, grupos e a base utilizada pelo OpenLDAP.

Listagem 11. Criando as LDIFs.

  # cd /usr/share/migrationtools/
  # ./migrate_passwd.pl /etc/passwd /etc/ldap/users.ldif
  # ./migrate_group.pl /etc/group /etc/ldap/groups.ldif
  # ./migrate_base.pl > /etc/ldap/base.ldif 

A Listagem 12 apresenta um exemplo de como deverá ficar o arquivo base.ldif.

Listagem 12. Exemplo do arquivo base.ldif.

  dn: dc=reisfa,dc=eti,dc=br
  dc: reisfa
  objectClass: top
  objectClass: domain
   
  dn: ou=Hosts,dc=reisfa,dc=eti,dc=br
  ou: Hosts
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Rpc,dc=reisfa,dc=eti,dc=br
  ou: Rpc
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Services,dc=reisfa,dc=eti,dc=br
  ou: Services
  objectClass: top
  objectClass: organizationalUnit
   
  dn: nisMapName=netgroup.byuser,dc=reisfa,dc=eti,dc=br
  nismapname: netgroup.byuser
  objectClass: top
  objectClass: nisMap
   
  dn: ou=Mounts,dc=reisfa,dc=eti,dc=br
  ou: Mounts
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Networks,dc=reisfa,dc=eti,dc=br
  ou: Networks
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=People,dc=reisfa,dc=eti,dc=br
  ou: People
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Group,dc=reisfa,dc=eti,dc=br
  ou: Group
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Netgroup,dc=reisfa,dc=eti,dc=br
  ou: Netgroup
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Protocols,dc=reisfa,dc=eti,dc=br
  ou: Protocols
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Aliases,dc=reisfa,dc=eti,dc=br
  ou: Aliases
  objectClass: top
  objectClass: organizationalUnit
   
  dn: nisMapName=netgroup.byhost,dc=reisfa,dc=eti,dc=br
  nismapname: netgroup.byhost
  objectClass: top
  objectClass: nisMap 

Após ter criado as LDIFs de usuários, grupos e base, deve-se inseri-las na base OpenLDAP. Lembre-se que já haverá os usuários e grupos antes criados no GNU/Linux, pois toda a base foi importada de lá. A Listagem 13 apresenta a sequência de comandos utilizados para essa operação.

Listagem 13. Inserindo os dados na base OpenLDAP.

  # ldapadd -x -D cn=admin,dc=reisfa,dc=eti,dc=br -f /etc/ldap/base.ldif -W
  # ldapadd -x -D cn=admin,dc= reisfa,dc= eti,dc=br -f /etc/ldap/groups.ldif -W
  # ldapadd -x -D cn=admin,dc= reisfa,dc= eti,dc=br -f /etc/ldap/users.ldif -W 

Onde:

• ldapadd – é o comando para inserir novos dados;

• x – é utilizado para autenticação simples;

• D – especifica o domínio;

• f – especifica o arquivo que será incluído;

• W – chama um prompt para digitar a senha.

Após executar os comandos, pode ser feita uma pesquisa para confirmar se os dados foram inseridos com sucesso. Observa-se na Listagem 14 a utilização do comando ldapsearch.

Listagem 14. Exemplo de uso do comando ldapsearch.

  # ldapsearch -x -b dc=reisfa,dc=eti,dc=br uidNumber=1000
   
  dn: uid=reisfa,ou=People,dc=reisfa,dc=eti,dc=br
  uid: reisfa
  cn: Flavio Reis
  objectClass: account
  objectClass: posixAccount
  objectClass: top
  objectClass: shadowAccount
  shadowMax: 99999
  shadowWarning: 7
  loginShell: /bin/bash
  uidNumber: 1000
  gidNumber: 1000
  homeDirectory: /home/reisfa
  gecos: Flavio Reis,,, 

Autenticando serviços

Os tópicos apresentados a seguir mostram a configuração para se autenticar em uma base OpenLDAP, não sendo abordada a instalação e configuração de cada serviço. Será apresentado o que deve ser alterado para que uma aplicação possa utilizar a autenticação em conjunto com a base de Diretórios.

Samba

O Samba é uma aplicação para GNU/Linux (e outros sistemas baseados em Unix) que permite o gerenciamento e compartilhamento de recursos em redes formadas por computadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos, servidor de impressão, entre outros, como se a rede utilizasse servidores Windows (NT, 2000, XP, Server 2003).

Com o servidor Samba, é possível compartilhar arquivos, compartilhar impressoras e controlar o acesso a determinados recursos de rede com igual ou maior eficiência que servidores baseados em sistemas operacionais da Microsoft.

Todo trabalho feito pelo Samba é provido de grande segurança, uma vez que há grande rigor nos controles dos recursos oferecidos. Tanto é que existem empresas que usam o Samba como solução para conflitos existentes entre diferentes versões do Windows.

Pode-se usar o Samba como um controlador primário de domínio (PDC), onde ele passa a funcionar como um servidor de autenticação para os clientes Windows e, opcionalmente, armazenar os perfis dos usuários, permitindo que eles tenham acesso a seus arquivos e configurações a partir de qualquer máquina onde façam logon.

Ao cadastrar um novo usuário no servidor Samba, ele automaticamente pode fazer logon em qualquer uma das estações configuradas. Ao remover ou bloquear uma conta de acesso, o usuário é automaticamente bloqueado em todas as estações. Isso elimina o problema de sincronismo entre as senhas no servidor e nas estações, além de centralizar a administração de usuários e permissões de acesso no servidor, simplificando bastante seu trabalho de administração.

Neste contexto, para que o Samba utilize a base de dados do OpenLDAP, algumas configurações devem ser efetuadas, alterando a diretiva passdb backend = tdbsam guest para o que está na Listagem 15.

Listagem 15. Configuração do smb.conf a ser inserido para autenticação via OpenLDAP.

  passdb backend = ldapsam:ldap://127.0.0.1
  ldap suffix = dc=reisfa,dc=eti,dc=br
  ldap machine suffix = ou=machines
  ldap user suffix = ou=users
  ldap group suffix = ou=groups
  ldap admin dn = cn=admin,dc=reisfa,dc=eti,dc=br
  ldap delete dn = no
  domain logons = yes
  enable privileges = yes 

Após essas alterações, deve-se reiniciar o Samba, através do comando service samba restart, e os usuários cadastrados no OpenLDAP estarão aptos a utilizar os compartilhamentos disponíveis pelo Samba.

Squid

Com a Internet cada vez mais acessível a pequenas e médias empresas, um número imenso de usuários está se interligando a Internet. Além de todos os benefícios fornecidos, como informação em tempo real, comunicação mundial a baixo custo, contato com possíveis clientes e fornecedores por todo o mundo, a mesma trouxe alguns problemas.

Os usuários tendem a passar cada vez mais tempo navegando por sites não relativos ao seu trabalho primário, acessam sites que não condizem com a política da empresa, utilizam a banda de Internet destinada a serviços como WEB ou VPN e podem, em muitos casos, acabar infectando toda a rede da empresa com vírus e worms que são adquiridos em sites impróprios. Isso sem contar com a ameaça sempre presente da propagação de downloads de softwares piratas e músicas, fatores que podem complicar a vida de uma empresa durante fiscalizações.

O Squid concede a possibilidade de autenticação de usuários. Dessa forma, sempre que o usuário acessar um navegador serão solicitadas suas credenciais. A Listagem 16 mostra a configuração que deve ser inserida no squid.conf.

Listagem 16. Configuração a ser inserida no proxy para autenticação via OpenLDAP.

  auth_param basic program /usr/lib/squid/ldap_auth -v 3 -b "dc=reisfa,dc=eti,dc=br" -f "uid=%s" -h serverldap.reisfa.eti.br
  auth_param basic children 8
  auth_param basic realm Acesso Restrito - Informe usuário e senha para acesso a Internet.
  auth_param basic credentialsttl 20 minutes
  acl usuarios proxy_auth REQUIRED 

Dessa forma, o administrador da rede poderá identificar os acessos de cada usuário visualizando os logs através do sarg, utilitário para análise de log de acesso do squid.

Conclusão

A concentração da base de dados de autenticação de usuários visa facilitar a administração de um parque computacional, independente do tamanho e complexidade. Com o uso do OpenLDAP, pode-se centralizar toda essa administração.

Com tudo o que foi relatado neste artigo, pode-se concluir que a centralização da informação, bem como o processo de autenticação seguro e centralizado, são ferramentas essenciais para uma organização competitiva. O acesso à informação deve, sempre que possível, ser monitorado e logado para a realização de auditorias futuras.

A utilização de um processo centralizado e criptografado de autenticação proporciona segurança ao ambiente organizacional, focando na precisão do controle da informação, garantindo que essas sejam acessadas somente pelos usuários que realmente têm direito. Sistemas com autenticação robusta elevam a confiabilidade de sua aplicação, porém vale ressaltar que uma aplicação é tão segura quanto seu ponto mais vulnerável, logo é necessário aplicar segurança em todas as partes.

Para concluir, vale destacar que é considerada uma boa prática a utilização de criptografia dos dados não só durante o processo de autenticação, mas também nas trocas de informação por meio de ambientes públicos como a Internet. É importante também fazer uma prévia análise de ameaças no sistema, para que sejam mapeadas e classificadas as possíveis vulnerabilidades de cada funcionalidade, evitando assim que falhas venham a comprometer toda a base de usuários.