Lightweight Directory Access Protocol

Esta seção aborda questões sobre o que o LDAP (Lightweight Directory Access Protocol) é e como ele funciona e fornece visões gerais de alto nível do X.500 e LDAP.

LDAP é um protocolo padrão que fornece meios de armazenar e recuperar informações sobre pessoas, grupos ou objetos em um servidor de diretórios X.500 ou LDAP centralizado. X.500 permite que as informações sejam organizadas e consultadas utilizando LDAP a partir de vários servidores da Web, utilizando uma variedade de atributos. As consultas de LDAP podem ser simples ou complexas, conforme requerido para identificar uma entidade individual ou grupo de entidades requeridas. O LDAP reduz os recursos do sistema requeridos, incluindo apenas um subconjunto funcional do DAP (Directory Access Protocol) X.500 original.

O módulo LDAP IBM® HTTP Server possibilita o uso de um servidor de diretórios X.500 para fins de autenticação e autorização. IBM HTTP Server pode usar esta capacidade para limitar o acesso de um recurso a um conjunto controlado de usuários. Esse recurso reduz o código extra administrativo, normalmente requerido para manter as informações sobre usuários e grupos, para cada servidor da Web individual.

Você pode configurar o módulo LDAP IBM HTTP Server para usar conexões TCP/IP ou Secure Sockets Layer (SSL) para o servidor de diretórios X.500 . O módulo LDAP pode ser configurado para referenciar um único servidor ou vários servidores LDAP.

Visão Geral do X.500. O X.500 fornece um serviço de diretório com componentes capazes de recuperação mais eficiente. O LDAP utiliza dois destes componentes: O modelo de informações, que determina o formato e caractere, e o espaço de nomes, que ativa a indexação e referenciação de informações.

A estrutura de diretórios do X.500 difere de outros diretórios no armazenamento e recuperação de informações. Esse serviço de diretório associa informações a atributos. Uma consulta com base em atributos é gerada e passada ao servidor LDAP e o servidor retorna os respectivos valores. O LDAP utiliza uma abordagem simples baseada em cadeias para representar as entradas de diretório.

Um diretório de X.500 consiste em entradas digitadas baseadas no atributo ObjectClass. Cada entrada é composta pelos atributos. O atributo ObjectClass identifica o tipo de entrada, por exemplo, uma pessoa ou organização, que determina os atributos requeridos e opcionais.

Você pode dividir entradas, organizadas em uma estrutura em árvore, entre servidores na distribuição geográfica e organizacional. O serviço de diretório nomeia entradas de acordo com a posição na hierarquia de distribuição, por um DN (Nome Distinto).

Visão Geral do Lightweight Directory Access Protocol. Acessar um diretório do X.500 requer o DAP (Directory Access Protocol). No entanto, o DAP requer grandes quantidades de recursos do sistema e mecanismos de suporte para manejar a complexidade do protocolo. O LDAP foi introduzido para ativar as estações de trabalho de mesa para acessar o serviço de diretório X.500.

O LDAP, um protocolo com base em cliente e servidor, pode tratar alguns dos recursos pesados exigidos pelos clientes DAP. Um servidor LDAP pode apenas retornar resultados ou erros ao cliente, que requerem pouco do cliente. Se não for possível responder a um pedido do cliente, um Servidor LDAP deve encadear o pedido a outro servidor X.500. O servidor deve concluir o pedido ou retornar um erro ao servidor LDAP que, por sua vez, transmite as informações ao cliente.

IBM HTTP Server suporta os seguintes servidores LDAP:

iPlanet/Netscape Directory Server
Servidor do Diretório IBM SecureWay
Microsoft Active Directory

Usando ldapsearch para Depurar Problemas de Configuração LDAP

Existem algumas ocorrências que podem impedir o funcionamento adequado da configuração LDAP. Exemplo

O nome distinto (DN) não está na lista de controle de acesso administrativo (ACL) e não pode executar algumas consultas LDAP.
O DN foi bloqueado do LDAP devido a muitas tentativas de login com falha.
A senha do DN pode ter sido alterada.
O servidor LDAP pode não permitir consultas anônimas.
O filtro padrão definido em WebSphere® Application Server pode não se ajustar às suas configurações (por exemplo, objectclass=someObjectClass é definido)
O firewall não permite comunicação na porta.
O LDAP está configurado para usar uma porta não padrão diferente de 389.
O ID de administrador LDAP é usado para o ID do servidor, mas o ID de administrador não está definido como um usuário regular.

Para essas e outras ocorrências que podem impedir o funcionamento adequado da configuração LDAP, é possível depurar o problema rapidamente usando ldapsearch. ldapsearch é um utilitário de linha de comando semelhante ao que o WebSphere Application Server usa para consultar o servidor LDAP no console administrativo. Exemplo

ldapsearch -h <Host> -p <Port> -b “<BaseDN>” -D <BindDN> -w <Bind Password> “<User Filter>”

em que:

Host: O nome do host do servidor LDAP. O nome do host pode ser um nome abreviado, um nome longo ou um endereço IP.
Porta: O nome da porta LDAP padrão, que é 389.
BaseDN: O local inicial da consulta na árvore LDAP.
BindDN: O DN completo que possui autoridade para se ligar ao servidor LDAP e executar as consultas solicitadas. Alguns servidores LDAP permitem consultas anônimas, portanto, nenhum DN de ligação ou nenhuma senha de ligação é necessária
Bind Password: A senha do DN de ligação.
User Filter: A sequência usada para consultar o servidor LDAP.

Consultas ldapsearch de exemplo:

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test