Introdução ao LDAP

HISTÓRIA

Quando a International Organization Standardization (ISO) e o Consultative Committee for International Telegraphy and Telephony (CCITT) se juntaram no início da década de 80 para criar um serviço de mensagens (a série X.400), houve a necessidade de desenvolver um protocolo que organizasse entradas num serviço de nomes de forma hierárquica, capaz de suportar grandes quantidades de informação e com uma enorme capacidade de procura de informação. Esse serviço criado pelas duas instituições, foi apresentado em 1988, denominando-se X.500, juntamente com um conjunto de recomendações e das normas ISO 9594.

O X.500 especificava que a comunicação entre o cliente e o servidor do Diretório usava o Directory Access Protocol (DAP) que era executado sobre a pilha de protocolos do modelo Open Source Initiative (OSI). O fato de o X.500 ser muito complexo e de custo incompatível, levou os pesquisadores da Universidade de Michigan a criar um servidor Lightweight Directory Access Protocol (LDAP) standalone, o slapd, que atuava sobre o TCP/IP. Em 1993 o LDAP foi então apresentado como alternativa ao protocolo DAP para acesso a Diretórios baseados no modelo X.500, sendo pela primeira vez implementado na própria universidade. Esse grupo de pesquisadores disponibilizou as fontes do slapd na Internet e criou listas de discussão para divulgar e aperfeiçoar o novo serviço, sendo a sua evolução acompanhada por pessoas do mundo inteiro. Com a divulgação do slapd, o LDAP deixou de ser uma mera alternativa ao DAP do X.500 e ganhou estatuto de Serviço de Diretório completo, passando a competir diretamente com o X.500.
Em Dezembro de 1997, o Internet Engineering Task Force (IETF) lançou a versão 3 do LDAP como proposta padrão Internet para Serviços de Diretório. Atualmente varias empresas oferecem produtos LDAP, incluindo a Microsoft, Netscape e Novell. A OpenLDAP Foundation mantém e disponibiliza uma implementação Open Source do Serviço de Diretório LDAP, baseada na Universidade de Michigan, que inclui os seguintes módulos: slapd, slurpd, bibliotecas que implementam o protocolo LDAP, utilitários, ferramentas e exemplos de clientes LDAP.
A evolução do OpenLDAP prossegue, acompanhando a evolução dos padrões IETF.
LDAP vs X.500
O LDAP foi concebido efetuando-se as seguintes simplificações em relação ao X.500:
• Transporte – O LDAP é executado diretamente sobre o TCP/IP, evitando o “overhead” das camadas superiores da pilha de protocolos OSI.
• Representação de dados – No LDAP a maioria dos elementos de dados são representados como cadeias de caracteres, processadas de modo mais fácil que os dados na representação estruturada Abstract Syntax Notation One (ASN.1) usada pelo X.500.
• Codificação de dados – O LDAP codifica dados para transporte em redes usando uma versão simplificada das mesmas regras de codificação usadas pelo X.500.
• Funcionalidade – O LDAP elimina características pouco usadas e também operações redundantes do X.500.
O fato de evitar as camadas superiores dos protocolos OSI veio simplificar o modo de funcionamento do Serviço de Diretório LDAP, tornando-o uma opção cada vez mais acessível a quem pretendia implementa-lo.
Noções Teóricas sobre o LDAP
Diretório
A palavra Diretório que normalmente usamos para as pastas de um disco rígido, neste contexto, tem um significado diferente. Um Diretório é uma base de dados especializada definida de forma hierárquica, otimizado para leitura suportando sofisticados métodos de pesquisa, com o objetivo de proporcionar uma resposta rápida a um enorme volume de consultas e onde são armazenadas informações estáticas de objetos. Não existe restrições quanto aos objetos que podem ser guardados num Diretório.
Esses objetos podem ser pessoas, organizações, endereços de email, impressoras, etc.

Schema

Os schemas em LDAP permitem manter a consistência dos dados do Diretório. Uma importante característica é serem extensíveis e assim podemos adicionar mais atributos ou classes dependente das necessidades. Para usar um schema é necessário inclui-lo no arquivo de configuração slapd.conf. Os schemas definem:
• quais as object classes que podem ser inseridas num Diretório;
• quais os atributos de uma determinada object class;
• os valores possíveis para os atributos;
Obs.: Se um objeto (entrada), não obedecer às regras do schema, este 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).
Distinguished Names
O Distinguished Name (DN) é usado para identificar uma entrada de forma não ambígua num Serviço de Diretório. Os DN ́s são compostos por uma sequência de Relative Distinguished Name (RDN) ́s e cada RDN corresponde a um ramo na DIT, desde a raiz até a entrada a qual o DN faz referência. Um DN é formado por uma série de RDN ́s separados por vírgulas. Por exemplo:

Atributos
Os atributos são identificados por um nome ou acrônimo, possuem um tipo e um ou mais valores. O tipo de atributo está associado a uma sintaxe. A sintaxe define que tipo de valor pode ser armazenado no atributo.
Alguns exemplos de atributos:

Object Identifier
Cada objectClass ou tipo de atributo tem uma sintaxe que identifica o de tipo de objeto, isto é, um Object Identifier (OID) globalmente único.
Os OID ́s são representados como strings decimais separados por pontos representando uma árvore hierárquica. A Internet Assigned Authority (IANA) é a entidade responsável pelo registo de “sub-árvores”de OID ́s.
Exemplos:

LDIF
LDAP Data Interchange Format (LDIF) é um arquivo de texto usado para:
• importar dados para o Diretório;
• alterar objetos existentes;
• criar o Backup do Diretório;
• a replicação;
Entrada
A unidade básica de informação armazenada num Diretório é denominada por entrada. As entradas são compostas por um conjunto de atributos referentes a um objecto, sendo organizadas numa estrutura semelhante a uma árvore, isto é, organizada segundo uma DIT.
Exemplo de uma entrada num arquivo LDIF

Obs.: Podem ser adicionadas várias entradas no mesmo arquivo LDIF. O comando para adicionar uma ao mais entradas ao Diretório é o sldapadd/ldapadd que será abordado com mais pormenor mais à frente na parte da implementação.
ObjectClass
Consiste num conjunto de atributos referentes a uma entrada. Quando uma entrada é definida, são atribuídas um ou mais object classes. Esses object class possuem atributos que podem ser opcionais ou obrigatórios. Existem dois tipos de object classes: structural e auxiliary. Toda a entrada deve ter um object class do tipo structural e pode ter uma ou mais object class auxiliary.
Um exemplo retirado do core.schema da object class “person”:

Como podemos ver no exemplo, é obrigatório o uso de sn (surname) ou cn (common name) e os atributos opcionais são: userPassword; telephoneNumber; seeAlso; e description.
Qual é a funcionalidade do slapd.conf?
O arquivo slapd.conf é o arquivo de configuração da daemon slapd do OpenLDAP. Normalmente está localizado em /etc/openldap/slapd.conf. Nele são especificados:
• Quais são os schemas usados;
• Que Backend é usada: ldbm, hdb, bdb, etc;
• Qual a base do Serviço de Diretório;
• Quem é o administrador e a sua password;
• A política de acesso;
Acesso aos dados do Diretório
O acesso aos dados do Diretório é controlado pelas Listas de Controle de Acesso Access Control Lists (ACL)s. Estas definem:
• Quais as entradas e/ou atributos com acesso;
• Os clientes que podem ou não ter acesso.
Não existe um modelo padrão para o controle de acesso no LDAP.
Serviços: slapd e slurpd
Slapd – Stand-alone LDAP Daemon
O slapd é um serviço LDAP autônomo (desenhado para executar como um servidor único), responsável por escutar ligações nas portas definidas, que podem ser uma ou mais (tipicamente é usada a porta 389). Toda a configuração do slapd é efetuada através do arquivo slapd.conf.
Slurpd – Stand-alone LDAP Update Replication Daemon
O slurpd é também um serviço LDAP autônomo de atualização e replicação de dados entre as Bases de Dados dos vários servidores. Permite propagar as alterações de uma Base de Dados slapd para outra. Se o slapd estiver configurado para produzir um log de replicação com alterações, então o slurpd lê a partir desse log e envia as alterações para as outras instâncias slapd, via protocolo LDAP.
Obs.: Versões mais novas no LDAP não utilizam mais o slurpd para replicação, para o seu lugar há o syncrepl.
Características do LDAP
Algumas das características e potencialidades mais interessantes do slapd são:
• Tem suporte para IPV6 – Desde a implementação LDAPv3, que o suporte LDAP sobre IPv6 tem vindo a ser uma realidade;
• Autenticação e Segurança – O slapd (serviço responsável pelo LDAP no servidor), sustenta serviços de forte autenticação através do uso do Simple Authentication and Security Layer (SASL). A implementação SASL do slapd utiliza o software Cyrus SASL o qual suporta um grande número de mecanismos: emphDIGEST-MD, EXTERNAL e GSSAPI;
SASL – Permite ao cliente negociar um método de autenticação seguro;
• Segurança da Camada de Transporte – O slapd fornece protecção de privacidade, integridade e autenticação através do uso do Transport Layer Security (TLS) ou de Secure Sockets Layer (SSL). A implementação TLS do slapd utiliza software OpenSSL;
SSL – É um sistema de codificação para proporcionar a máxima confidencialidade dos dados pela Internet. Os dados são encriptados no ponto de envio e decifrados no ponto de destino.
TLS – É semelhante ao SSL mas com uma tecnologia diferente.
• Escolha da Base de Dados de Backend – O slapd contém várias bases de dados backend disponíveis, que o permitem escolher a base de dados que mais se adapta à solução pretendida;
• Berkeley ́s Data Base (BDB) – É uma base de dados backend de alta performance transacional;
• Configuração – O slapd é altamente configurável através de um único arquivo de configuração (slapd.conf), a partir do qual é possível efetuar as alterações pretendidas e adaptar o Serviço ao nosso sistema. Novas versões do LDAP agora utilizam a própria base de dados para armazenagem de suas configurações (cn=config) mas ainda é possível a utilização do arquivo de configuração mediante um parâmetro fornecido ao Daemon do LDAP.
Bases Dados vs LDAP
A grande diferença entre o LDAP e as Bases de Dados Relacionais, é que no LDAP a informação está guardada segundo uma estrutura em árvore, raramente se efetuam atualizações, está otimizado para responder a um grande número de pesquisas e têm um alto nível de segurança.
Atualmente o LDAP é escolhido pela maioria dos administradores de rede em detrimento das Bases de Dados Tradicionais, porque para além das suas características já referidas, cada vez mais existem aplicações com suporte LDAP.
Modelos definidos pelo LDAP
O Serviço de Diretório LDAP é composto pelos seguintes modelos:
Modelo Funcional
Define o que pode ser feito com a informação no Diretório LDAP e como podemos altera-la e a forma de ter acesso. Funcionalmente as operações definidas pelo LDAP estão divididas em três categorias:
– Interrogação:
• ldapsearch – faz pesquisas das entradas no Diretório;
• ldapcompare – verifica se uma entrada contém um dado valor num  atributo;
– Atualização:
• ldapmodify – altera uma entrada existente;
• ldapadd – adiciona uma nova entrada;
• ldapdelete – apaga uma entrada existente;
• ldapmodrdn – renomeia uma entrada existente;
– Autenticação:
• ldap_bind – faz autenticação do cliente (PHP3, PHP4, PHP5);
• ldap_unbind – encerra uma sessão LDAP;
Modelo de Informação
Define o tipo de informação que pode ser armazenada num Diretório LDAP. A unidade básica da informação armazenada no Diretório é chamada de entrada. Esse modelo, herdado quase sem alterações do X.500, é extensível. Ao definir novas object classes, pode-se adicionar a um Diretório qualquer tipo de informação.
Modelo de Nomes
Este modelo define a forma como a informação no Diretório LDAP pode ser organizada e referenciada. As entradas são organizadas numa DIT e divididas segundo uma distribuição geográfica e/ou organizacional. Cada entrada tem um DN que especifica o caminho da raiz até à entrada.
Modelo de Segurança
Este importante modelo, define como os dados do Diretório LDAP podem ser protegidos de acessos ou modificações não autorizadas. Para isso, existem três aspectos básicos na proteção da informação do Diretório:
Acesso – Para o acesso seguro o LDAP suporta o TLS que criptografa toda a comunicação entre cliente e servidor. Desta forma garante a segurança das informações que são trocadas na rede.
Autenticação – é a forma de provar ao serviço que um cliente é válido. Para autenticação o LDAP suporta a SASL, que permite que o cliente e servidor negociem um método de autenticação (seguro).
Autorização – é o serviço que fornece ou nega direitos específicos ou funcionalidades ao cliente. A autorização é controlada pelas ACLs.
O LDAP irá controlar todos os três aspectos da Authentication, Authorization, Accounting (AAA) através de Listas de Controle de Acesso, isto é, ACLs. As ACLs podem ser usadas para autorizar o acesso baseado em muitos fatores diferentes. Elas podem ser usadas para forçar tipos específicos de autenticação. Uma vez que o cliente esteja autenticado como válido, as ACLs são usadas para autorizar o cliente. O cliente quando chama a operação “bind” fornece a sua identificação (distinguished name), credenciais de autenticação, password, chaves privadas, etc. Uma lista de controle de acesso é usada para determinar que entradas do Diretório o cliente pode ver e que alterações ele tem permissão para fazer. Há a possibilidade de um cliente não se identificar, ou seja, ter acesso ao Diretório como anônimo. Nesse caso as regras de controle de acesso também determinarão o que o cliente poderá ou não fazer.
Vantagens do LDAP
• É um padrão aberto;
• Está otimizado para fazer pesquisas de informação;
• Centraliza toda a informação trazendo assim enormes benefícios, tais como: um único ponto de administração; menos dados duplicados;
• Tem um mecanismo de replicação incluído (slurpd);
• Tem mecanismos de segurança tanto para a autenticação (SASL) como para o troca de dados (SSL/TLS);
• Atualmente várias aplicações tem suporte para LDAP;
Desvantagens do LDAP
• O LDAP em alguns casos não substitui as Bases de Dados Relacionais;
• Raramente são efetuadas atualizações;
• Apenas convém ser guardados dados estáticos;
• Obviamente não é possível relacionar dois atributos, visto que não se trata de uma Base de Dados Relacional mas sim de uma base de dados estruturada hierarquicamente. Exemplo: Não é possível relacionar o código de uma disciplina com o nome da disciplina;
• Instalação torna-se difícil, pois cada vez tem mais pré-requisitos:
OpenSSL, Kerberos, SASL (Cyrus), BerkeleyDB;
Conclusão:
O LDAP tem vindo a ser usado cada vez mais por administradores de rede porque as suas características e as suas vantagens em muitos casos compensam as desvantagens. A prova disso é que cada vez mais aplicações e sistemas operacionais possuem suporte para LDAP.
Este é o início de uma série de posts sobre o LDAP, espero que tenham gostado e continuem comentando.

Ricardo Pinheiro