Gerenciamento de usuários com OpenLDAP - Revista Infra Magazine 10

Mudanças ocorrem constantemente em um ambiente corporativo, seja por motivo de rotatividade de colaboradores, mobilidade na hierarquia, mudanças de funções e setores, inclusão/retirada de dispositivos, seja por outros motivos. Deste modo, a administração de sistemas torna-se uma tarefa complexa, pois cada um dos fatores mencionados necessita de configuração para que possam operar de acordo com a necessidade do ambiente. Em redes de pequeno porte, muitas vezes é possível utilizar procedimentos manuais para configuração de serviços de rede e administração de usuários. Porém, à medida que a rede cresce, se torna mais complexa e heterogênea, e o gerenciamento de identidades se torna um desafio, trazendo riscos à segurança em função da escolha de senhas frágeis e do vazamento de informações.

Dessa forma, entende-se que todo ambiente de rede necessita armazenar informações de modo a possibilitar o seu gerenciamento. Como exemplo, temos autenticações, grupos de usuários, permissões, cotas de armazenamento, acessos a compartilhamentos, entre outros. Muitas organizações possuem ambientes mistos com várias plataformas (Linux, Windows, Unix) conectadas fisicamente e distribuídas geograficamente, que trocam informações entre si. O problema desse tipo de rede é que para cada plataforma ou rede local existente no ambiente de rede (rede física) será necessário alimentar uma base de dados com as mesmas informações, o que torna a administração complexa, uma vez que será necessário garantir a sincronia e a replicação das informações. Se a solução para a gerência dos dados não for eficaz, torna-se difícil a organização e a distribuição das informações, causando duplicidades, maior custo no suporte e falta de segurança.

Diante disso, o gerenciamento de identidades se torna um fator importante, seja qual for o tamanho da corporação ou da rotatividade de usuários, pois dessa forma há uma grande contribuição na vinculação destes em sistemas de Recursos Humanos (RH) ou cadastros básicos (por exemplo, cadastro de visitantes), permitindo a criação, o bloqueio e a exclusão automática de usuários.

Dentro do contexto de segurança, a prática do gerenciamento de identidades compreende três elementos: diretivas, processos e tecnologias, sendo que as diretivas se referem aos limites e padrões a serem seguidos para cumprir a política da organização e também práticas recomendadas; os processos descrevem as sequências de etapas que levam à conclusão de tarefas; e as tecnologias são as ferramentas automatizadas que auxiliam a organização a atingir os objetivos comerciais de forma eficiente e precisa, respeitando os limites especificados nas diretivas.

Com base nisso, este artigo aborda o aspecto tecnológico do gerenciamento de identidades a partir da instalação e da configuração de um servidor de diretórios utilizando o OpenLDAP integrado com o proxy Squid, de modo a permitir a centralização e o controle dos acessos na rede.

Serviço de Diretórios

Um diretório é um repositório de informações sobre objetos, organizados segundo um critério que facilite a sua consulta. De acordo com o OpenLDAP Software 2.4 Administrator’s Guide (ver Links), a definição simples para diretório é: “um banco de dados específico, otimizado para busca, leitura e navegação”.

Serviços de diretório e bancos de dados compartilham características comuns, tais como buscas rápidas e funções de atualização. Enquanto um serviço de diretório é utilizado mais para leitura do que escrita, em um banco de dados, assume-se que as operações de leitura e de escrita ocorrem mais ou menos com a mesma frequência. Diretórios podem conter informações descritivas baseadas em atributos que podem ser filtrados, ao passo que as transações realizadas devem ser finalizadas totalmente, não podendo ser concluídas de forma parcial, características essas encontradas em bancos de dados que são desenhados para manusear grandes volumes de atualizações e que suportam transações que permitem desistência de operações (rollback). Exemplos de diretórios utilizados no cotidiano são as listas telefônicas e os dicionários, pois ambos armazenam informações ordenadas para consulta para facilitar a busca por entradas. No caso da lista telefônica, as entradas são organizadas em ordem alfabética pelo nome da pessoa, no caso do dicionário, por verbete. Na computação, os serviços de diretórios podem buscar informações localmente (por exemplo, ao executar o comando finger em um servidor Linux/Unix) ou, ainda, em servidores que mantêm a informação distribuída (por exemplo, uma pesquisa no serviço de resolução de nomes deve retornar o mesmo resultado, independentemente do computador no qual foi realizada a busca).

Dentro do contexto de redes de computadores, seja de pequeno, médio ou grande porte, é justificada a utilização de um serviço de diretório, pois permite a mobilidade dos dados que podem ser agrupados por departamentos ou por unidades, centraliza as informações que ficarão disponíveis a todos os serviços da rede e possibilita delegar a administração de parte do diretório (que pode estar localizado fisicamente em outro servidor) a outros usuários.

LDAP

LDAP, que significa Lightweight Directory Access Protocol, tem como função definir o modo como um serviço de diretórios trabalhará, especificando critérios, mecanismos e métodos para armazenar e fornecer informações. Como o nome sugere, é um protocolo leve (lightweight) para acessar serviços de diretório, especificamente serviços de diretório baseados em X.500.

O X.500 é um protocolo baseado no conceito OSI, que especifica um modelo para a conexão de serviços de diretórios locais a fim de formar um diretório global distribuído, com suporte a funções de gerenciamento, tais como adição, alteração e remoção de entradas. O protocolo de acesso a diretórios DAP (Directory Access Protocol) faz parte das especificações do padrão X.500 e foi desenvolvido para trabalhar junto a todas as camadas do modelo Open Systems Interconnection (OSI), com o objetivo de definir o acesso de usuários aos serviços de diretórios que seu padrão provia. Porém, isso tornou sua implementação difícil, gerando aplicações complexas e lentas.

O LDAP foi criado como uma alternativa ao DAP para prover acesso aos serviços de diretórios do X.500, utilizando o modelo da pilha TCP/IP. Por esse motivo, é mais fácil de ser implementado, além de exigir menos recursos da rede e de memória, provendo melhor desempenho.

Posteriormente, foram criados servidores de diretórios para colocar em prática um software provedor de serviços de diretórios específico para o TCP/IP e o LDAP, deixando de lado o X.500. O LDAP foi padronizado pelo Internet Engineering Task Force (IETF) em julho de 1993 por meio da Request For Comments (RFC) 1487 e atualmente está na versão 3, conforme especificado na RFC 4510.

OpenLDAP

O projeto OpenLDAP é o resultado de um esforço colaborativo para desenvolver um software multiplataforma com ferramentas para implantação de um serviço de diretório LDAP em um ambiente de rede (software servidor, cliente, utilitários). É uma solução utilizada como alternativa às implementações de mercado como Microsoft Active Directory, Novell eDirectory, Sun iPlanet Directory Server e outros.

A configuração do OpenLDAP é feita através do slapd (Stand-Alone LDAP Daemon), que tem como função atender as requisições dos clientes, seja em forma de autenticação ou ainda, resposta a uma consulta no diretório. O slurpd (Stand-Alone LDAP Update Replication Daemon) é utilizado para a replicação do diretório, isto é, propaga as alterações de uma base slapd para outra. Como opções para a segurança, o OpenLDAP fornece suporte à criptografia TLS, SSL e SASL, além de permitir um controle granular por meio de listas de controle de acesso (ACLs).

Dentre as aplicações para uso do OpenLDAP, podemos citar:

· Base de autenticação de usuários da rede para serviços como:

o Login de rede (utilizado para acessar estações Linux ou estações Windows através do software Samba, que é utilizado para integrar ambientes heterogêneos);

o E-mail (utilizado para autenticar o usuário no envio e recebimento de mensagens, através dos protocolos POP3, SMTP, IMAP);

o Acesso à Internet (Proxy);

· Catálogo de e-mails e cadastro de clientes.

Estrutura de serviço de diretório

Antes de realizar a instalação de um serviço de diretório, é importante compreender como as informações são organizadas.

No LDAP, as entradas do diretório são estruturadas de forma hierárquica, como uma árvore, para representar limites geográficos ou organizacionais. Por exemplo, pensando em uma estrutura de árvore, no topo estão as entradas que representam os países, seguidas das entradas de estados e organizações nacionais, e mais abaixo, entradas que representam unidades organizacionais, pessoas, hosts e outras informações que se deseja catalogar.

Uma entrada em um serviço de diretório é uma coletânea de atributos agrupados em um identificador único chamado DN (Distinguished Name). Um atributo consiste no par atributo/valor, sendo que um atributo pode ter mais de um valor, como na representação de membros de um grupo; por exemplo, o grupo marketing contém os seguintes membros: Maria, José, João.

A Tabela 1 apresenta as entradas do modelo da estrutura de diretório.

abrir imagem em nova janela

Tabela 1. Entradas da estrutura de diretórios.

A Figura 1 ilustra uma árvore de diretório considerando uma estrutura geográfica e organizacional. Nesse tipo de estrutura, o topo da árvore contém entradas que representam países e estados. Nesse ponto, a estrutura hierárquica é criada a partir de entradas das organizações nacionais, seguidas das unidades organizacionais que podem representar, por exemplo, unidades de uma empresa, como matriz e filiais, ou ainda divisões internas, como departamentos, grupos, usuários e outros.

abrir imagem em nova janela

Figura 1. Exemplo de estrutura de diretório.

Outra maneira para construir um serviço de diretório é utilizar componentes dc (domínio Internet), que refletem a estrutura do DNS. Atualmente, há preferência por esse modelo, pois ele facilita a localização de serviços de diretórios a partir do desmembramento do endereço de Internet, permitindo divisões de hierarquia ou regiões e possibilitando a replicação parcial da base e buscas mais rápidas. A Figura 2 apresenta um exemplo de diretório baseado na estrutura dc, no qual os primeiros níveis (topo da árvore) representam o nome de domínio da empresa, na mesma ordem de leitura de um domínio DNS.

abrir imagem em nova janela

Figura 2. Exemplo de Diretório baseado em estrutura dc.

Instalação

Nesta etapa do artigo, será apresentada a instalação dos pacotes utilizados para a configuração do servidor, que será baseado no Sistema Operacional Debian Squeeze, com OpenLDAP versão 2.4.3. Lembrando que, para executar os comandos que serão apresentados, é necessário realizar o login com o usuário root (administrador do sistema).

Para a instalação dos pacotes, será necessário configurar o arquivo /etc/apt/sources.list com os repositórios externos. A Listagem 1 apresenta um modelo do arquivo.

Listagem 1. Modelo do arquivo /etc/apt/sources.list.

deb http://ftp.br.debian.org/debian/ squeeze main
  deb-src http://ftp.br.debian.org/debian/ squeeze main
  deb http://security.debian.org/ squeeze/updates main
  deb-src http://security.debian.org/ squeeze/updates main
  # squeeze-updates, previously known as 'volatile'
  deb http://ftp.br.debian.org/debian/ squeeze-updates main
  deb-src http://ftp.br.debian.org/debian/ squeeze-updates main
  <p align="left">deb http://backports.debian.org/debian-backports 
    squeeze-backports main

Os pacotes que serão instalados são o slapd e o ldap-utils. Os comandos apresentados na Listagem 2 realizam a pesquisa dos pacotes nos mirrors configurados no /etc/apt/sources.list, e em seguida é feita a instalação.

Listagem 2. Pesquisa e instalação dos pacotes.

  # aptitude search slapd
  # aptitude search ldap-utils
  # aptitude install slapd ldap-utils

Durante a instalação, é solicitada a definição da senha do administrador, conforme demonstrado na Figura 3. Na tela seguinte a essa etapa, basta confirmar a senha escolhida.

abrir imagem em nova janela

Figura 3. Solicitação da senha do administrador do LDAP.

Dadas essas informações, os pacotes serão instalados. É uma boa prática verificar se estes foram instalados corretamente, assim como a versão do protocolo OpenLDAP, se o usuário e grupo utilizados pelo LDAP foram criados e se o serviço foi iniciado. A Listagem 3 apresenta os comandos utilizados para realizar essa operação.

Listagem 3. Verificação dos pacotes, usuário e grupo e processo do serviço LDAP.

Pacotes instalados
  # dpkg -l | egrep 'slapd|ldap-utils'
  ii  ldap-utils       2.4.23-7.2      OpenLDAP utilities
  ii  slapd            2.4.23-7.2      OpenLDAP server (slapd)
  Versão do protocolo OpenLDAP
  # slapd -V
  @(#) $OpenLDAP: slapd 2.4.23 (Jun 16 2011 02:53:39) $
          buildd@murphy:/build/buildd-openldap_2.4.23-7.2-i386-Y1mwvF/
          openldap-2.4.23/debian/build/servers/slapd
   
  Usuário e grupo utilizados pelo Ldap
  <p align="left"># cat /etc/passwd | grep ldap
  <p align="left">openldap:x:104:106:OpenLDAP Server   
   Account,,,:/var/lib/ldap:/bin/false
   
  # cat /etc/group | grep ldap
  openldap:x:106:
   
  Verificação do processo do serviço Ldap:
  # ps -ef | grep ldap
  openldap  1712     1  0 Nov10 ?        00:00:00 /usr/sbin/slapd -h ldap:///
  ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
  root      1770  1126  0 00:17 pts/0    00:00:00 grep ldap

Configuração

Neste tópico será apresentada a configuração do serviço OpenLDAP, de uma forma tradicional, isto é, por meio do arquivo slapd.conf. Em versões mais recentes, o OpenLDAP não traz o arquivo slapd.conf dentro do diretório /etc/ldap/, mas o diretório /etc/ldap/slapd.d/, que contém uma base chamada cn=config. É nesta base onde são armazenadas as informações do serviço de diretório, bem como as informações dos schemas utilizados (identificados pelos arquivos com extensão .schema).

Ao utilizar o arquivo cn=config, a configuração passa a ser online, de modo que, caso seja necessário criar um novo índice ou uma ACL, não será preciso parar o serviço e reiniciá-lo, etapa necessária quando se utiliza o arquivo slapd.conf. Entretanto, deve-se observar que a inclusão de uma ACL incorreta, por exemplo, poderá causar indisponibilidade no serviço, pois apesar de ser imediatamente aplicada, a funcionalidade de remoção de entradas ainda não é contemplada na versão 2.4, sendo necessário reiniciar o serviço. Assim, nesse artigo, a configuração do OpenLDAP será realizada por meio do arquivo slapd.conf, ficando o cn=config como tema para um próximo artigo.

Antes de prosseguir com a configuração, será necessário reconfigurar o pacote slapd utilizando a ferramenta dpkg-reconfigure, de modo a ativar o LDAP com informações, tais como o domínio que será utilizado, tipo de banco que irá armazenar os dados, entre outras.

A Listagem 4 apresenta os comandos necessários para realizar esse procedimento.

Listagem 4. Reconfigurando o pacote slapd.

  Parando o serviço:
  # /etc/init.d/slapd stop
  Removendo os arquivos de base criados durante a instalação:
  # rm -f /var/lib/ldap/*
   
  Reconfigurando o pacote slapd:
  # dpkg-reconfigure slapd

Ao executar o comando dpkg-reconfigure, serão solicitadas informações para a nova configuração do slapd. A primeira pergunta é se o administrador deseja omitir a configuração do servidor OpenLDAP. Caso seja escolhido Yes/Sim, nenhuma configuração inicial ou base de dados será criada. Como os arquivos de base foram removidos, nessa tela, a escolha deve ser No/Não, conforme apresentado na Figura 4.

abrir imagem em nova janela

Figura 4. Reconfiguração do pacote OpenLDAP.

A próxima pergunta se refere ao domínio que será a base DN (Distinguished Name) do diretório do LDAP. Ao preencher os dados dessa tela, é importante observar que deve ser informado o nome de um domínio, conforme ilustrado na Figura 5, e não uma entrada do LDAP como “dc=meudominio,dc=com”. Ao inserir o domínio, o configurador automaticamente criará a entrada LDAP, desmembrando o que foi digitado em componentes de domínio (dc).

abrir imagem em nova janela

Figura 5. Definição do domínio OpenLDAP.

As próximas telas se referem à definição do nome da organização que será utilizada no serviço de diretório, e à senha de root. Para a primeira pergunta, basta informar o nome, como “LDAP Article”, por exemplo. Quanto à senha de root, esta se refere ao administrador do serviço de diretório e não do sistema operacional. Assim, é boa prática que a senha seja diferente da senha do SO e que contenha caracteres especiais, letras e números.

Após confirmar a senha escolhida, será solicitada a definição do tipo de banco de dados que será utilizado. Tanto o BDB quanto o HDB são backends para armazenamento de dados, com as mesmas opções de configuração. A diferença entre eles está no fato de que o BDB utiliza indexação e cache para acelerar o acesso aos dados enquanto HDB utiliza um banco de dados hierárquico e permite renomear objetos na base de dados. Como o configurador recomenda utilizar o HDB, basta selecionar essa opção conforme ilustra a Figura 6.

abrir imagem em nova janela

Figura 6. Configuração do banco que será utilizado pelo LDAP.

A próxima pergunta está relacionada à desinstalação do pacote slapd. O administrador pode optar por remover completamente o pacote junto com a base de dados, ou remover somente o pacote, mantendo as informações da base. Isso quer dizer que ao utilizar o comando aptitude purge slapd, tanto o pacote como todo o conteúdo do banco de dados serão removidos, enquanto utilizar somente aptitude remove slapd desinstala somente o pacote, mantendo o conteúdo do banco. Nesse caso, selecione a opção No/Não.

Por fim, será solicitada a confirmação para deixar habilitado o protocolo LDAPv2, conforme apresentado na Figura 7. Selecione a opção Yes/Sim, para manter a compatibilidade com clientes que ainda não utilizam o LDAPv3.

abrir imagem em nova janela

Figura 7. Escolha da versão do protocolo utilizado.

Ao finalizar a reconfiguração do pacote, a base de dados é recriada e o serviço é iniciado, porém ainda é necessário indicar que o OpenLDAP utilizará as definições do arquivo slapd.conf e não do cn=config. Esse procedimento é feito a partir da atualização da variável SLAPD_CONF e da cópia do arquivo para o diretório /etc/ldap. A Listagem 5 apresenta os comandos para realizar o procedimento.

Listagem 5. Indicando o arquivo de configuração que será utilizado pelo OpenLDAP.

  Atualização da variável SLAPD_CONF que indica o path do arquivo:
  # vim /etc/default/slapd
  SLAPD_CONF="/etc/ldap/slapd.conf"
   
  Copiando o arquivo de configuração
  # cp /usr/share/sladp/slapd.conf /etc/ldap
   
  Verificando se a cópia foi realizada:
  # ls -l /etc/ldap/slapd.conf
  -rw-r--r-- 1 root root 4637 Nov 11 05:57 /etc/ldap/slapd.conf

Diretivas do arquivo de configuração

Conforme dito anteriormente, as configurações para a criação de um serviço de diretórios utilizando o OpenLDAP será feita a partir do arquivo sladp.conf. Assim como a maior parte dos arquivos de configuração no Linux, este arquivo possui comentários que descrevem cada diretiva ou sua sintaxe. Para facilitar o entendimento das diretivas apresentadas, será feito um backup do arquivo original e criado um arquivo limpo, sem comentários. O comando utilizado para esse procedimento é o egrep, que removerá linhas que são iniciadas por um comentário (^#), linhas em branco (^$), e em seguida redirecionar a saída para o arquivo que será utilizado para configurar o OpenLDAP, conforme demonstrado na Listagem 6.

Listagem 6. Retirada dos comentários do arquivo de configuração.

Cópia do arquivo original
  # cp /etc/ldap/slapd.conf /etc/ldap/slapd.conf.original 
  Remoção dos comentários e linhas em branco
  <p align="left"># egrep -v “^#|^$” /etc/ldap/slapd.conf.original 
  > /etc/ldap/slapd.conf

Com o arquivo limpo, podemos verificar as diretivas e aplicar as configurações para disponibilizar um serviço de diretórios na rede. O editor de textos utilizado será o vim, porém o usuário poderá editar o arquivo a partir de outros editores de texto. A Listagem 7 demonstra o arquivo limpo que será utilizado.

Listagem 7. Conteúdo do arquivo slapd.conf.

# vim slapd.conf
  allow bind_v2
  include         /etc/ldap/schema/core.schema
  include         /etc/ldap/schema/cosine.schema
  include         /etc/ldap/schema/nis.schema
  include         /etc/ldap/schema/inetorgperson.schema
  pidfile         /var/run/slapd/slapd.pid
  argsfile        /var/run/slapd/slapd.args
  loglevel        192
  modulepath      /usr/lib/ldap
  moduleload      back_hdb
  sizelimit 500
  tool-threads 1
  backend         hdb
  access to attrs=userPassword,shadowLastChange
          by dn="cn=admin,dc=meudominio,dc=com" write
          by anonymous auth
          by self write
          by * none
  access to dn.base="" by * read
  access to *
          by dn="cn=admin,dc=meudominio,dc=com" write
          by * read
  database        hdb
  suffix          "dc=meudominio,dc=com"
  directory       "/var/lib/ldap"
  rootdn          "cn=admin,dc=meudominio,dc=com"
  rootpw          "senhadificil"
  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

A seguir, são apresentadas as principais diretivas configuradas no arquivo slapd.conf:

· allow bind_v2: Refere-se ao uso da versão 2 do protocolo LDAP e não faz exigência de uso de certificados digitais. É útil manter essa opção para manter compatibilidade com clientes e serviços que utilizam somente essa versão. Caso essa linha não exista no arquivo, basta acrescentá-la;

· include: As linhas com essa diretiva estão relacionadas com os arquivos de schema, que são um conjunto de regras que define atributos, classes de objetos e controles, indicando onde cada dado pode ser armazenado. Em uma instalação padrão, os arquivos de schema são armazenados no diretório /etc/ldap/schema e devem ser definidos linha a linha especificando o seu caminho completo, conforme demonstrado na Listagem 8.

Um diretório pode conter mais de um schema e alguns atributos são de preenchimento obrigatório. Por exemplo, ao utilizar o schema inetOrgPerson, os atributos cn (common name) e sn (surname) obrigatoriamente precisam conter algum valor, enquanto uid e userpassword (id de usuário e senha, respectivamente) são opcionais, não necessitando ser adicionados. A Tabela 2 apresenta as especificações fornecidas com os schemas do arquivo slapd.conf;

Listagem 8. Schemas inclusos no 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

Tabela 2. Especificações dos schemas utilizados no arquivo slapd.conf.

· pidfile: No Linux, todos os processos são identificados por um número denominado PID (Process IDentification). Essa diretiva indica o arquivo que contém o PID do processo em execução do OpenLDAP;

· argsfile: Arquivo que contém os argumentos passados ao servidor no momento de sua execução;

· loglevel: Define o nível de verbosidade do registro de atividades (log) no OpenLDAP. O nível 0 (none) determina que não será gerado log, porém, em caso de problema para iniciar o serviço, é interessante ativar um nível para que sejam gerados registros que podem ser consultados a fim de determinar o problema.

É possível utilizar depuração máxima (-1) ou combinar valores, isto é, somar os valores dos níveis a fim de obter as informações desejadas. Por exemplo, caso deseje habilitar o log para o processamento das configurações (nível 64) e também o processamento de listas ACL (128), basta somar os níveis: 128 + 64 = 192 e alterar a diretiva com esse valor:

loglevel 192

A Tabela 3 apresenta alguns níveis de depuração que podem ser utilizados e combinados na diretiva loglevel;

Tabela 3. Níveis de depuração da diretiva loglevel.

· modulepath: Define o diretório dos módulos para os backends (bdb, hdb) utilizados para armazenar os dados do LDAP;

· moduleload: Ativa o módulo do backend que será utilizado;

· sizelimit: Define a quantidade máxima de entradas retornadas em uma consulta feita na base OpenLDAP. Por padrão, as pesquisas estão limitadas a 500 entradas. Para mais resultados, será necessário aumentar este valor, e ao definir -1, a consulta trará retornos ilimitados;

· tool-threads: Define o número de CPUs que serão utilizadas para a indexação da base de dados. Se o servidor tiver mais de um processador, aumente este número;

· backend: Permite configurar as opções específicas de cada backend, que nesse artigo é o HDB;

· access to: Listas de controle de acesso (ACLs) que definem o que os usuários podem ou não fazer dentro da estrutura do LDAP através de diferentes níveis de acesso. A Tabela 4 apresenta os privilégios que podem ser concedidos para o usuário.

Tabela 4. Níveis de acesso para construção de ACLs no LDAP.

As ACLs oferecem um controle granular no gerenciamento de identidades no que diz respeito à integração entre os serviços, porém deve-se observar que a configuração deve ser bem calculada para evitar que, ao negar um acesso, esta ação não seja sobrescrita pela próxima regra. A Listagem 9 contempla as ACLs configuradas no slapd.conf e, para efeito de distinção entre uma regra e outra, estão descritas como ACL1, ACL2 e ACL3.

Listagem 9. ACLs configuradas no arquivo slapd.conf.

  # ACL1
  access to attrs=userPassword,shadowLastChange
  by dn="cn=admin,dc=meudominio,dc=com" write
  by anonymous auth
  by self write
  by * none
   
  # ACL2
  access to dn.base="" by * read
   
  # ACL3
  access to *
  by dn="cn=admin,dc=meudominio,dc=com" write
  by * read

A ACL1 se refere às permissões referentes à autenticação (userPassword) e alteração de senha (shadowLastChange), o que garante os seguintes direitos de acesso a esses atributos:

· Escrita e leitura ao usuário admin:

by dn="cn=admin,dc=meudominio,dc=com" write

· Autenticação aos usuários anônimos:

by anonymous auth

· Escrita e leitura aos usuários autenticados (apenas nos dados retornados em suas próprias entradas), permitindo que estes alterem a própria senha:

by self write

· Para os demais usuários, o acesso é negado:

by * none

A ACL2 dá direito de leitura à raiz do diretório configurado (dc=meudominio,dc=com):

access to dn.base="" by * read

No exemplo apresentado, a ACL1 é mais restritiva e impede que a ACL2 dê privilégio de leitura de senhas aos usuários comuns; caso a ordem estivesse invertida, a primeira ACL não teria efeito. E, por fim, a ACL3 garante direito de acesso a todo o diretório para escrita e leitura ao usuário admin e apenas leitura aos demais usuários.

Dando continuidade na descrição das diretivas do slapd.conf, ainda temos:

· database: Ativa a base de dados escolhida (HDB);

· suffix: Campo da estrutura da base LDAP (no exemplo, dc=meudominio,dc=com), que define sob qual hierarquia os dados do serviço de diretório serão armazenados;

· directory: Local (path) onde os dados do serviço de diretório serão armazenados;

· rootdn: Define o usuário que será administrador da base LDAP. Pode ser definido um usuário com o nome Manager ou Admin, uma vez que o usuário root do sistema operacional não é o administrador da base;

· rootpw: Define a senha de acesso ao servidor LDAP. Na configuração padrão, a senha é colocada em texto puro no arquivo, porém, por medida de segurança, utiliza-se a ferramenta slappasswd (demonstrada mais a frente) para gerar a senha criptografada que será colocada no arquivo;

· dbconfig: Especifica parâmetros para configuração do backend utilizado, tais como limite do cache da base em memória, número de objetos que podem ser travados simultaneamente, número de travas (locks) solicitadas e ativadas, número de travamentos (lockers) ativos, etc. Na configuração do limite do armazenamento dos dados em memória (set_cachesize), o padrão é 2M, podendo ser alterado caso o servidor tenha memória RAM disponível;

· index: Define para quais atributos o slapd deve manter índices de forma a melhorar a busca. A indexação da base deve ser configurada de acordo com o tipo de pesquisa que será feita e as possibilidades de filtros a serem aplicados. A Tabela 5 apresenta os tipos de indexação ou o tipo de pesquisa a ser realizada;

Tabela 5. Tipos de indexação da base LDAP.

· lastmod: Grava informações de tempo (timestamp) em cada modificação e criação de entradas no diretório, permitindo que o cliente verifique quando a informação foi atualizada;

· checkpoint: Define quando os buffers da base de dados HDB devem ser gravados no disco, para evitar possíveis perdas. É fornecido um limite em kbytes e outro em minutos, sendo que o primeiro a vencer dispara o checkpoint e grava uma entrada no arquivo de log para registrar o evento.

Inicializando o servidor de diretório OpenLDAP

Após realizar as configurações, o próximo passo é modificar a permissão do arquivo slapd.conf, alterar a propriedade do diretório /etc/ldap e verificar a sintaxe do arquivo de configuração.

A alteração da permissão do arquivo de configuração visa proteger a senha que foi definida para o administrador da base. Uma vez que durante a instalação os comandos são executados com o usuário root, os arquivos de configuração herdam as permissões desse usuário e se faz necessário utilizar o comando chown para alterar para o usuário e grupo openldap, utilizados pelo LDAP para iniciar o serviço. A opção –R no comando faz com que sejam alterados todos os arquivos e diretórios abaixo do /etc/ldap, conforme apresentado na Listagem 10.

Listagem 10. Alteração do usuário e grupo do diretório /etc/ldap.

Alteração da permissão do arquivo slapd.conf
  # chmod 600 slapd.conf 
  Alteração do usuário e grupo para openldap
  # chown -R openlap:openldap /etc/ldap 
  Lista dos arquivos após a modificação: 
  # ls -l
  total 28
  -rw-r--r-- 1 openldap openldap  245 Jun 16  2011 ldap.conf
  drwxr-xr-x 2 openldap openldap 4096 Jun 16  2011 sasl2
  drwxr-xr-x 2 openldap openldap 4096 Nov 11 05:48 schema
  -rw------- 1 openldap openldap 1078 Nov 16 05:13 slapd.conf
  -rw-r--r—1 openldap openldap 4637 Nov 11 06:37 slapd.conf.original

Por fim, é hora de checar a sintaxe e iniciar o serviço. O OpenLDAP disponibiliza diversas ferramentas para a administração do serviço, e para checar a sintaxe do arquivo slapd.conf, será utilizado o comando slaptest, que verifica possíveis erros dentro do arquivo de configuração. Sua utilização é demonstrada a seguir:

# slaptest -f /etc/ldap/slapd.conf -F /etc/ldap

As opções do comando slaptest são:

· -f – utilizado para indicar o arquivo de configuração (configfile);

· -F – utilizado para indicar o diretório em que essas configurações serão reescritas sempre que forem alteradas (configdir).

Caso não haja nenhum erro de sintaxe, o comando exibe a mensagem config file testing succeeded, caso contrário, uma mensagem de erro é exibida e deve-se verificar no arquivo a sintaxe ou sequência para a correção. Em caso de sucesso, basta reiniciar o serviço conforme comando a seguir:

# /etc/init.d/slapd restart

Incluindo registros na base de dados

Diferentemente de um banco de dados, o LDAP não possui um gerenciador que pode ser acionado para ações de manipulação de dados, tais como adição, modificação ou exclusão. Os gerenciadores LDAP existentes não trabalham de forma online, isto é, a modificação de dados é feita por meio de um arquivo texto que contém as informações a serem modificadas. Este arquivo possui um formato específico chamado LDIF (LDAP Data Interchange Format), que define os dados necessários para o cadastro de cada tipo de registro.

A seguir, serão apresentados os arquivos LDIF e os comandos necessários para criar um serviço de diretório. Para adição de uma entrada para um domínio, usuário ou grupo, deve-se informar os dados referentes a cada um deles e também quais dados farão parte da entrada, utilizando o objectClass, ou classe de objeto, que é um registro que identifica um conjunto de atributos agrupado por tipo, isto é, determina as características opcionais e obrigatórias que um objeto em particular pode ou deve possuir. Por exemplo, durante a criação de um usuário que irá se autenticar no Linux ou Windows, o objectClass irá determinar quais itens são obrigatórios ou opcionais para criação da conta.

As definições de cada classe de objeto e cada atributo estão nos arquivos .schema localizados em /etc/ldap/schema e são responsáveis pela padronização e manutenção da estrutura do Diretório. Por exemplo, para cadastrar a organização, utiliza-se o atributo organization; unidade organizacional, utiliza-se o atributo organizationalUnit; e para usuários de um modo geral, utiliza-se inetOrgPerson.

A Listagem 11 demonstra a criação do arquivo meudominio.ldif, que irá conter os dados básicos, isto é, a estrutura para o topo da árvore do diretório (organization) para o domínio meudominio.com.

Listagem 11. Criação do arquivo meudominio.ldif.

# vim /etc/ldap/meudominio.ldif
  dn: dc=meudominio,dc=com
  objectClass: dcObject
  objectClass: organization
  o: LDAP Article
  dc: meudominio

Após criar o arquivo, é necessário informar ao servidor LDAP onde estão os dados que devem ser inseridos na base. O comando utilizado para essa ação é o ldapadd, o qual abre uma conexão com o servidor e autentica o usuário administrador ou outro que tenha permissão de escrita (edição) na base. Na mesma linha, indica-se como argumento o arquivo LDIF criado, que será utilizado para que as entradas sejam adicionadas no diretório, conforme demonstrado na Listagem 12.

Listagem 12. Adicionando o primeiro registro na base.

ldapadd -h localhost -W -x -D 
  "cn=admin,dc=meudominio,dc=com" -f /etc/ldap/meudominio.ldif
  Enter LDAP Password:
  adding new entry "dc=meudominio,dc=com"

A Tabela 6 apresenta os parâmetros utilizados no comando ldapadd com uma breve descrição.

Tabela 6. Parâmetros utilizados no comando ldapadd.

Uma vez que a estrutura do topo da árvore do diretório foi criada, é possível inserir dados na base. No entanto, como visto no início deste artigo, um serviço de diretório possibilita organização e hierarquia. Dessa forma, será necessário criar as entradas das unidades organizacionais (ou), que irão agrupar os dados cadastrados de forma ordenada e coerente. Para o modelo de Diretório utilizado neste artigo, serão criadas duas ou, sendo que a ou denominada Pessoa irá conter a identificação dos usuários e a ou Grupos irá conter grupos. Essa estrutura é representada na Figura 8.

abrir imagem em nova janela

Figura 8. Estrutura do modelo de Diretório a ser implementado.

Com o modelo de Diretório que será utilizado, a próxima etapa é criar o arquivo unidades_ou.ldif que irá conter os dados das unidades organizacionais Pessoa e Grupos, conforme o conteúdo da Listagem 13.

Listagem 13. Criação do arquivo unidades_ou.ldif.

dn: ou=Pessoa,dc=meudominio,dc=com
  ou: Pessoa
  objectClass: top
  objectClass: organizationalUnit
   
  dn: ou=Grupos,dc=meudominio,dc=com
  ou: Grupos
  objectClass: top
  objectClass: organizationalUnit

Após criar esse arquivo, é necessário incluir as unidades organizacionais no Diretório utilizando o comando ldapadd. A Listagem 14 demonstra a sintaxe para executar essa ação, sendo que o padrão é o mesmo que foi utilizado para criar o topo da árvore, apenas modificando o nome do arquivo que será fornecido como argumento para leitura dos dados que serão cadastrados.

Listagem 14. Adicionando unidades organizacionais no Diretório.

<p align="left"># ldapadd -x -h localhost -D 
  “cn=admin,dc=meudominio,dc=com” –W -f /etc/ldap/unidades_ou.ldif
  Enter LDAP Password:
  adding new entry "ou=Pessoa,dc=meudominio,dc=com"
   
  adding new entry "ou=Grupos,dc=meudominio,dc=com"

Até este ponto foram criadas três entradas no Diretório: uma referente ao topo da árvore, representada pelo domínio dc=meudominio,dc=com; a segunda referente à unidade organizacional ou=Pessoa; e a terceira referente à unidade organizacional ou=Grupos. Seguindo o modelo da estrutura de Diretório apresentada na Figura 8, o próximo passo é criar uma entrada de usuário utilizando uma classe de objeto que contemple os atributos que se deseja disponibilizar.

Para esse exemplo, serão utilizados os atributos da classe de objetos inetOrgPerson, localizada no diretório /etc/ldap/schema. Essa classe é estrutural e não necessita de classes adicionais para que a entrada seja criada, além de definir atributos essenciais para que um registro de usuários associados à organização possa ser criado. A Listagem 15 apresenta o arquivo da entrada de dados para registro do usuário e o comando para incluir este no Diretório.

Listagem 15. Arquivo LDIF que contém a entrada de dados do usuário.

# vim /etc/ldap/pessoa.ldif
  dn: cn=Pathiene Gerstenberger,ou=Pessoa,dc=meudominio,dc=com
  objectClass: inetOrgPerson
  cn: Pathiene Gerstenberger
  givenName: Pathiene
  sn: Gerstenberger
  uid: pgerstenberger
  userPassword: peth1234
  mail: pathigerst@gmail.com
  description: OpenLDAP

Sintaxe do comando ldapadd para incluir usuário no Diretório

# ldapadd -h localhost -W -x -D “cn=admin,dc=meudominio,dc=com” -f /etc/ldap/pessoa.ldif

Enter LDAP Password:

adding new entry "cn=Pathiene Gerstenberger,ou=Pessoa,dc=meudominio,dc=com"

Com isso, temos uma estrutura inicial da base LDAP. Agora veremos como realizar as pesquisas para verificar os registros cadastrados.

Consultas

Uma vez que os dados foram cadastrados no Diretório, é necessário realizar a pesquisa para verificar as informações. O comando ldapsearch é utilizado para realizar as buscas dentro das bases LDAP e pode ser utilizado de diversas formas, sendo que a mais comum é a pesquisa anônima, isto é, a pesquisa que não exige a identificação do solicitante dos dados. A Listagem 16 apresenta o resultado de uma busca anônima.

Listagem 16. Realizando uma busca anônima.

# ldapsearch –x
  # extended LDIF
  #
  # LDAPv3
  # base <> (default) with scope subtree
  # filter: (objectclass=*)
  # requesting: ALL
  # 
  # search result
  search: 2
  result: 32 No such object 
  # numResponses: 1

A Tabela 7 apresenta os principais parâmetros que o comando ldapsearch aceita.

Tabela 7. Parâmetros aceitos pelo ldapsearch.

A Listagem 17 apresenta um exemplo de como buscar os dados do usuário pgerstenberger cadastrado no exemplo de criação de usuário no LDAP.

Listagem 17. Exemplo de pesquisa por usuário (uid).

# ldapsearch -h localhost -x -b ou=Pessoa,dc=meudominio,dc=com  uid=pgerstenberger
  # extended LDIF
  #
  # LDAPv3
  # base <ou=Pessoa,dc=meudominio,dc=com> with scope subtree
  # filter: uid=pgerstenberger
  # requesting: ALL
  # 
  # Pathiene Gerstenberger, Pessoa, meudominio.com
  dn: cn=Pathiene Gerstenberger,ou=Pessoa,dc=meudominio,dc=com
  objectClass: inetOrgPerson
  cn: Pathiene Gerstenberger
  givenName: Pathiene
  sn: Gerstenberger
  uid: pgerstenberger
  mail: pathigerst@gmail.com
  description: OpenLDAP
   
  # search result
  search: 2
  result: 0 Success
   
  # numResponses: 2
  # numEntries: 1

Autenticação do Squid no OpenLDAP

Na Edição 8 da Infra Magazine, foi apresentado como instalar o servidor Proxy com Squid e retirar relatórios dos acessos à Internet utilizando a ferramenta Sarg. Com o objetivo de aperfeiçoar a instalação do OpenLDAP, este será integrado com o Squid para que os usuários utilizem seus cadastros para fazer login no Squid, permitindo a integração e o controle dos acessos na rede.

Para configurar o Squid com autenticação no LDAP, é necessário indicar no arquivo squid.conf que o parâmetro squid_auth_param será utilizado para que os usuários sejam autenticados na rede. Porém, antes de antes de iniciar a configuração, deve ser feito um teste em linha de comando para verificar se o Squid já tem conexão com a base LDAP. O comando usado para isso é:

# /usr/lib/squid3/squid_ldap_auth -b “dc=meudominio,dc=com” -f “uid=%s” -h 127.0.0.1

Onde:

· -b: Define o contexto da busca. Em alguns lugares é chamado de “ramo de árvore” porque é onde se define a localização que os usuários serão procurados para se autenticar. No exemplo, foi definido todo o domínio; assim, será feita uma busca completa na árvore LDAP e em toda a sua estrutura;

· -f: Define o que será considerado na autenticação. No exemplo, será o uid do usuário;

· - h: Indica a localização do servidor OpenLDAP.

Ao executar o comando e teclar <ENTER>, o prompt continuará aberto aguardando a autenticação. Conforme ilustrado na Figura 9, deve-se inserir o nome do usuário seguido da senha. Se a conexão for bem sucedida, haverá um retorno OK, caso contrário, haverá o retorno ERR, que pode vir seguido de uma mensagem de erro.

abrir imagem em nova janela

Figura 9. Resultado do teste de conexão do Squid com o servidor LDAP.

Como o resultado do teste de conexão e autenticação foi bem sucedido, o próximo passo é incluir as linhas apresentadas na Listagem 18 no arquivo /etc/squid/squid.conf para indicar que a partir desse momento a autenticação no Squid será realizada pelo LDAP.

Listagem 18. Linhas a serem adicionadas no arquivo squid.conf.

auth_param basic program /usr/lib/squid3/squid_ldap_auth -b 
  “dc=meudominio,dc=com” -f “uid=%s” -h localhost 
  auth_param basic children 5
  auth_param basic realm - SQUID AUTENTICANDO NO LDAP
  auth_param basic credentialsttl 1 hour

As linhas adicionadas no arquivo são:

· auth_param basic program /usr/lib/squid3/squid_ldap_auth -b “dc=meudominio,dc=com” -f “uid=%s” -h localhost: Linha que define a conexão do Squid com o LDAP. O parâmetro auth_param basic program é utilizado para indicar a lib que será usada para a autenticação dos serviços, que no caso está em /usr/lib/squid3/squid_ldap_auth, sendo obrigatório adicionar o path completo do arquivo. O parâmetro uid=%s foi utilizado no arquivo squid.conf para substituir o nome do usuário (pathigerst) que foi inserido no momento da autenticação;

· auth_param basic children 5: Especifica a quantidade de processos filhos que serão iniciados durante a autenticação;

· auth_param basic realm – SQUID AUTENTICANDO NO LDAP: Determina a mensagem que será apresentada ao usuário quando a autenticação for solicitada;

· auth_param basic credentialsttl 1 hour: Informa o tempo de duração que o login será mantido ativo.

Também no arquivo squid.conf deve ser configurada a ACL para que as regras, isto é, as linhas que foram adicionadas anteriormente referentes à autenticação, sejam aplicadas, conforme demonstrado na Listagem 19.

Listagem 19. ACL para aplicar a autenticação no Squid via LDAP.

acl ldap-auth proxy_auth
  http_access allow ldap-auth 

Onde:

· acl ldap-auth proxy_auth: Define que a autenticação via proxy por meio do LDAP é obrigatória;

· http_access allow ldap-auth: Libera os clientes (browsers) a acessarem o serviço HTTP por meio da autenticação via LDAP.

É importante observar que as linhas mencionadas devem estar antes da linha http_access deny all, que bloqueia todas as requisições. Caso a autenticação via LDAP seja inserida após essa linha dentro do squid.conf, ela será ignorada.

Com as configurações definidas, é necessário salvar e sair do arquivo de configuração squid.conf e carregar as alterações, conforme apresentado na Listagem 20.

Listagem 20. Carregando as alterações no squid.conf.

# squid -k parse
  # squid -k reconfigure
  # /etc/init.d/squid restart 

A primeira linha analisa se as configurações do Squid estão corretas. Em seguida, o comando squid –k reconfigure faz com que as alterações no arquivo sejam consideradas. Por fim, o serviço é reiniciado.

Configuração do navegador

Após a configuração do servidor, a próxima etapa é configurar os navegadores das estações clientes para autenticar no LDAP e navegar utilizando o proxy Squid. O exemplo apresentado a seguir é baseado no Firefox e os passos para esse procedimento consistem em acessar o menu Edit > Preferences e, em seguida, clicar nas opções Advanced > Network > Connection > Settings, conforme apresentado na Figura 10.

abrir imagem em nova janela

Figura 10. Configurando o Firefox para autenticar no Squid (Etapa 1).

Feito isso, será aberta uma tela para indicar o servidor proxy que será utilizado. Conforme apresentado na Figura 11, clique em Manual proxy configuration, informe o IP do servidor Squid e a porta de acesso. Em seguida, marque a opção Use this proxy server for all protocols e, para finalizar, clique em OK em todas as telas.

Figura 11. Configurando o Firefox para autenticar no Squid (Etapa 2).

Ao tentar navegar, uma tela de autenticação aparecerá, onde usuário deverá informar seu login e senha, conforme ilustrado na Figura 12.

abrir imagem em nova janela

Figura 12. Tela de autenticação para navegação.

No servidor onde estão configurados o OpenLDAP e o Squid, é possível ver essa autenticação no log, onde entre as informações de acesso também é mostrado o uid do usuário que está navegando. O administrador pode acompanhar o log de acesso utilizando o comando tail. A Figura 13 ilustra o trecho do log em tempo real.

# tail -f /var/log/squid/access.log

abrir imagem em nova janela

Figura 13. Log de acesso do Squid.

Dica de Segurança

Durante a configuração do servidor OpenLDAP, foi definida uma senha simples e deixada em texto claro dentro do arquivo slapd.conf, o que pode causar um incidente de segurança, uma vez que se outro usuário que não o administrador tiver acesso ao arquivo, terá acesso total à base. Pensando nisso, a suíte OpenLDAP oferece o comando slappasswd, utilizado para gerar senhas criptografadas que podem ser colocadas em arquivos como slapd.conf ou os arquivos com extensão .ldif, impossibilitando a leitura da senha dos usuários.

A Tabela 8 apresenta os principais parâmetros utilizados para o comando slappasswd.

Tabela 8. Parâmetros do comando slappasswd.

Conclusão

O protocolo LDAP tem sido cada vez mais utilizado por administradores em razão da facilidade de integração de ambientes heterogêneos, assim como pela sua estrutura leve. A utilização de programas de código aberto (OpenLDAP + Squid) apresenta uma solução de baixo custo com farta documentação encontrada na Internet e em publicações comerciais. Dentro deste contexto, o OpenLDAP pode ser utilizado para gerenciar identidades e integrar informações para que usuários de rede e aplicações tenham acesso aos recursos de maneira padronizada.

No ambiente corporativo, é comum encontrar áreas, departamentos ou até gerências responsáveis por cuidar das informações sobre os funcionários, porém muitas vezes não existe uma integração dessa área com aquela responsável pela administração do controle de acesso aos recursos computacionais da empresa.

Nesse contexto, se faz necessária uma solução que integre as bases de autenticação com os serviços de rede, garantindo que, além da validação do usuário, apenas as aplicações e recursos relacionados com a sua área de atuação estejam disponíveis.

Assim, com o OpenLDAP, é possível configurar um serviço de diretório em uma organização sem custo de licenças, além de ficar a critério do usuário a possibilidade de configurá-lo ou desenvolvê-lo da forma que melhor se adaptar às suas necessidades, seja para autenticar os usuários nos serviços de rede como o proxy demonstrado neste artigo, seja para qualquer outra finalidade na qual seja necessário armazenar e consultar informações de modo centralizado.