Segundo a Wikipédia, serviço de diretórios é:

“Um serviço de diretório é um software que armazena e organiza informações sobre os recursos e os usuários de uma rede de computadores, e que permite os administradores de rede gerenciar o acesso de usuários e sistemas a esses recursos. Além disso, os serviços de diretório atuam como uma camada de abstração entre os usuários e esses recursos. A palavra directory em inglês poderia ser melhor traduzida por catálogo, no sentido de uma lista ordenada com descrição curta dos itens, não necessariamente de arquivos.” A sua primordial diferença está na forma como os recursos são tratados. Entenda por recursos todos os componentes de uma rede de computadores, como os compartilhamentos, configurações, usuários, senhas, permissões e mais.

Permitir a centralização de gestão dos recursos da rede, visando simplificar a administração, backup e replicação. Centralização é a palavra chave de todas as facilidades encontradas no uso de um serviço de diretórios.

LDAP é um protocolo. Como todos os protocolos sua função é definir a forma de funcionamento de um serviço de diretórios especificando critérios, mecanismos e métodos para armazenar e fornecer informações.

LDAP – “Lightweight Directory Access Protocol” (LDAP) ou Protocolo Leve de Acesso à Diretórios é um conjunto de protocolos desenhados para acessar informação centralizada em uma rede.

Esse conjunto de protocolos serve para interagir com o Serviço de Diretório. Assim as regras de acesso ao diretório estão definidas no LDAP. O LDAP é definido para uso em sistemas Cliente-Servidor permitindo a um cliente LDAP consultar ou alterar o diretório comunicando-se com o servidor LDAP. É multi-plataforma.

O servidor LDAP tem a função de verificar as credenciais do cliente, verificar se as informações solicitadas estão armazenadas neste servidor e permitir ou não que o cliente realize consultas e modificações. As formas de armazenamento dos dados, tipo de gerenciador de bancos de dados usado e sistema operacional de base não fazem parte do protocolo. Fazem parte da implementação específica do LDAP.

A manutenção de um cadastro centralizado de usuários é um grande desafio para o administrador de TI. A rotatividade de colaboradores e a mobilidade na hierarquia tornam difícil a manutenção de informações coerentes sobre determinado recurso de uma organização.

O grande número de sistemas e a heterogeneidade de plataformas faz com que a manutenção de senhas e identidades seja um grande desafio. É repetidamente motivo para escolha de senhas frágeis e vazamento de informações.

O uso do LDAP permite que colaboradores, aplicativos e recursos de rede possam usar informações armazenadas em um repositório central. Isso unifica os esforços de criação, manutenção da base de informações. O LDAP permite a consulta a informações cadastrais, o que permite sua utilização como agenda de contatos central da organização, um dos primeiros usos para o protocolo.

Como vantagens do LDAP podemos citar:

Por ser um padrão aberto, a interoperabilidade entre os diversos fornecedores é facilitada. Um cliente LDAP baseado em OpenLDAP pode perfeitamente realizar consultas e atualizações em um servidor de outro fornecedor que siga os padrões LDAP. O LDAP é um protocolo. As implementações podem trazer novas interfaces e ferramentas de administração e consulta, mas os métodos básicos são definidos no protocolo; API (”Application Programming Interface”, Interface para Programação) bem definida e com suporte para diversas linguagens de programação; Muito mais rápido que Sistemas de Bancos de Dados (considerando que atualizações são menos constantes que consultas); Esquemas (regras para o armazenamento de dados) padronizados existem para diferentes funções; Permite a consolidação de informações de várias fontes; Facilmente replicável e distribuível.

Uma base LDAP busca organizar as informações em forma de diretório, ou seja, em forma de “árvore”. As partes que permitem essa formação são as especificações do protocolo.

Baseando-se em campos, chamados de atributos e em seus conjuntos, chamados de schemas, é possível armazenar praticamente qualquer tipo de informação de forma estruturada o que facilita sua administração.

Cada ramificação da “árvore” pode ser um departamento da organização, permitindo ter um efeito visual organizacional da base.

O primeiro passo para entender como uma base LDAP está estruturada é realizar um exercício mental para eliminar quaisquer outros conceitos pré-existentes. Um erro muito comum é tentar estabelecer elos com bases de dados SQL ou DB.

Bases LDAP tem uma estrutura muito singular e qualquer comparação servirá apenas para criar confusão, especialmente para os iniciantes. Portanto evite as comparações e abra a mente para entender algo completamente novo.

Visando simplificar o entendimento vamos utilizar a palavra diretório com o seu mais conhecido conceito: o de pasta de armazenamento de arquivos e outros diretórios.

Sabemos que um diretório no sistema de arquivos nada mais é do que uma divisão lógica que visa organizar os arquivos existentes no disco rígido. Pense no LDAP nos mesmos termos. Assim começa a ficar claro que a estrutura de uma base LDAP é completamente diferente de qualquer outra base de dados comum.

Em um sistema de arquivos o diretório principal chama-se raiz e isso deve-se a sua estrutura em forma de “árvore”. O LDAP mantém essa mesma idéia, ou seja, a partir da “raiz da árvore”, estão suas ramificações, que permitem a organização lógica dosarquivos.

Assim como em uma estrutura de diretórios o LDAP permite a existência de outros diretórios dentro de um diretório já existente. Portanto cada novo diretório é raiz em si mesmo para todo o seu conteúdo.

Em um diretório não é permitido ter arquivos com o mesmo nome e isso faz sentido, afinal, é fundamental ter apenas um nome que identifique cada arquivo.

Uma vez compreendido que a base LDAP funciona como um diretórios de um sistema de arquivos basta fazer a relação entre arquivos e recursos. Em uma base LDAP não se armazenam arquivos mas sim recursos de rede, como usuários e senhas, por exemplo.

Assim como em alguns sistemas de arquivos existem regras para a criação de arquivos, a base LDAP também possui regras para o armazenamento de recursos. Estas regras são muito mais complexas do que simplesmente limitar o número de caracteres no nome de um arquivo, afinal trata-se do armazenamento de dados.

Estas regras ou limites são impostos pela definição do protocolo e elas tem que ser respeitadas. Caso contrário a base simplesmente negará a adição de informações.

Qual informação e qual conteúdo podem ser adicionados, são definidos pelo conjunto de atributos e seus conjuntos, as ObjectClasses. Portanto quanto mais schemas sua base LDAP tiver, mais flexível ela será, permitindo o armazenamento de mais recursos.

O conjunto de ObjectClasses e atributos são chamados de “schemas”

Os schemas nada mais são do que arquivos texto contendo uma série de ObjectClasses. Os ObjectClasses nada mais são do que um conjunto de atributos, e os atributos nada mais são do que a definição lógica dos campos que podem ser utilizados em uma base LDAP.

Cada schema habilita um determinado tipo informação a ser armazenada na base. Os schemas são lidos pela base LDAP e assim permite o uso dos campos nele definido.

Para ilustrar essa idéia vamos usar um exemplo de criação de um usuário válido para sistemas Gnu/Linux.

Sabemos que quando um usuário comum é criado, alguns atributos são obrigatórios, como seu UID e GID, além do diretório home, senha e shell de login. Esses atributos podem ser facilmente vistos no arquivo /etc/passwd.

De forma similar, quando se quer adicionar um usuário “posix” em uma base LDAP esses atributos também são obrigatórios. Mas como saber disso? Quem define quais são obrigatórios? Alguns desses atributos são apenas opcionais?

O arquivo de schema que contém esses atributos chama-se “nis.schema” e nele vamos encontrar o objectClass posixAccount. Veja abaixo:

 objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
        DESC 'Abstraction of an account with POSIX attributes'
        SUP top AUXILIARY
        MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
        MAY ( userPassword $ loginShell $ gecos $ description ) )

Entendendo essa descrição:

Linha um: Definição do objectClass, contendo o seu número único e nome; Linha dois: Descrição livre do objectClass; Linha três: Herança do objeto. Neste caso ele é um objeto auxiliar do objectClass “top”; Linha quatro: Atributos obrigatórios para o uso deste objeto; Linha cinco: Atributos opcionais para o uso deste objeto.

Agora vamos ver um exemplo de um dos atributos obrigatórios:

 attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
         DESC 'The absolute path to the home directory'
         EQUALITY caseExactIA5Match
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Linha um: Definição do atributo, contendo seu número único e nome; Linha dois: Descrição do atributo; Linha três: Definição do tipo de valor que pode ser armazenado nesse atributo. Linha quatro: Sintaxe válida

Todos esses valores fazem parte da especificação do protocolo LDAP.

Cada arquivo de schema contém uma série de objetos e atributos para atender necessidades específicas de recursos específicos, ou seja, os atributos necessários para se adicionar um usuário do Samba são bem diferentes dos atributos necessários para se adicionar um usuário “posix”. Portanto, para cada recurso que se deseje armazenar em uma base LDAP deve-se ter um schema próprio.

É fato que para a maioria dos serviços existentes já existe um schema, bastando incluí-lo na base LDAP para que possa ser utilizado.

Para ver mais detalhes sobre às regras dos tipos de informação que podem ser utilizados em um atributo e suas sintaxes verifique às tabelas no Apêndice I.

Como foi visto acima, as regras para adicionar um registro em uma base LDAP, são muito mais complexas do que para criar um arquivo em um diretório comum em um sistema de arquivos.

Entretanto a similaridade está no fato de que não pode haver dois registros iguais em um mesmo diretório. Para garantir essa unicidade para todos os registros utiliza-se o identificador DN (Distinguished Name).

Um registro único pode conter diversos objetos e atributos, de acordo com sua finalidade. Aqui vemos um exemplo de registro único:

cn=”Anahuac de Paula Gil”,ou=Usuarios,dc=kyapanel,dc=com,dc=br

É importante entender o que está descrito acima. Esta é uma descrição do formato padrão que deve ser utilizado em nome da compatibilidade com os diversos serviços que oferecem suporte à bases LDAP. Portanto não é obrigatório, as extremamente desejável.

Quando uma base LDAP é criada precisa-se definir a raiz da “árvore” do diretório. Esta raiz normalmente é definida pelo atributo “domainComponent”, também conhecido como “dc”, com o nome do domínio da internet da organização.

Neste exemplo:

dc=kyapanel,dc=com,dc=br

Dentro da raiz foi criado um outro “galho” da “árvore” chamado Usuarios cujo atributo é ou (Organizational Unit).

Neste exemplo:

ou=Usuarios

Finalmente, dentro do “galho” Usuarios foi criado um usuário, cuja identificação única está sendo feita pelo atributo cn (Common Name).

Neste exemplo:

cn=”Anahuac de Paula Gil”

Pode-se também referenciar um usuário utilizando o atributo uid em vez de cn, entretanto o padrão é usar o cn.

O objeto final, que é o usuário, poderá e deverá conter diversos atributos para atender às exigências de diversos servidores. Por exemplo:

dn: cn=”Anahuac de Paula Gil”,ou=Usuarios,dc=kyapanel,dc=com,dc=br
uid: anahuac
sn: anahuac
objectClass: top
objectClass: person
objectClass: qmailUser
homeDirectory: /home/anahuac
userPassword:: e1NTSEF9MGNjcXJKTEVOQU9nTSswR2l4TVRtelhBWERObng5cFU=
cn: Anahuac de Paula Gil
mail: anahuac@kyapanel.com.br

Perceba que o primeiro registro contém o identificador único: “dn:”

Para efeito de comparação teríamos o usuário anahuac dentro do diretório Usuarios que está dentro da raiz kyapanel.com.br. Visualizando:

dc=kyapanel,dc=com,dc=br
|
--------> ou=Usuarios
             |
	     --------> cn=”Anahuac de Paula Gil”

O objetivo de manter as informações assim é simplesmente para facilitar a localização e consequentemente, facilitar a administração dos recursos.

A base LDAP tem um funcionamento similar aos diretórios dos sistemas de arquivos. Portanto não há nenhuma relação direta com bases de dados SQL;

A base LDAP armazena recursos e não arquivos;

A base LDAP utiliza um conjunto de objetos e atributos para fazer esse armazenamento;

O conjunto de objetos e atributos é chamado de schema e não passa de um arquivo texto que deve ser lido pela base LDAP para que possam ser usados;

Um objeto é chamado de ObjectClass e ele é composto de atributos obrigatórios e atributos opcionais;

Um atributo é uma definição de campo, contendo a definição de que tipo de valor ele pode armazenar.

Dentro de uma base LDAP cada registro é único, ou seja, não podem haver dois registros iguais em um mesmo diretório.

Copyright 2007 Anahuac de Paula Gil e Francisco Kem Iti Saito

Permite-se distribuição, publicação e cópia literal da íntegra deste documento, sem pagamento de royalties, desde que sejam preservadas a nota de copyright, a URL oficial do documento e esta nota de permissão.

Permite-se também distribuição, publicação e cópia literal de seções individuais deste documento, sem pagamento de royalties, desde que sejam preservadas a nota de copyright e a nota de permissão acima, e que a URL oficial do documento seja preservada ou substituída pela URL oficial da seção individual.