Protocolo de acesso a diretório leve - Lightweight Directory Access Protocol

Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

O Lightweight Directory Access Protocol ( LDAP / ɛ l d æ p / ) é uma, a indústria aberta, independente de fornecedor padrão protocolo de aplicação para acessar e manter distribuídos serviços de informações de diretório sobre um Protocolo de Internet (IP). Os serviços de diretório desempenham um papel importante no desenvolvimento de aplicativos de intranet e Internet, permitindo o compartilhamento de informações sobre usuários, sistemas, redes, serviços e aplicativos em toda a rede. Como exemplos, os serviços de diretório podem fornecer qualquer conjunto organizado de registros, geralmente com uma estrutura hierárquica, como um diretório de e-mail corporativo . Da mesma forma, uma lista telefônica é uma lista de assinantes com um endereço e um número de telefone.

O LDAP é especificado em uma série de publicações da faixa padrão da IETF ( Internet Engineering Task Force ) denominadas Request for Comments (RFCs), usando a linguagem de descrição ASN.1 . A especificação mais recente é a versão 3, publicada como RFC 4511 (um roteiro para as especificações técnicas é fornecido pela RFC4510 ).

Um uso comum do LDAP é fornecer um local central para armazenar nomes de usuário e senhas. Isso permite que muitos aplicativos e serviços diferentes se conectem ao servidor LDAP para validar os usuários.

O LDAP é baseado em um subconjunto mais simples dos padrões contidos no padrão X.500 . Devido a esse relacionamento, às vezes o LDAP é chamado de X.500-lite.

História

O entendimento das empresas de telecomunicações sobre os requisitos de listas foi bem desenvolvido após cerca de 70 anos de produção e gerenciamento de listas telefônicas. Essas empresas introduziram o conceito de serviços de diretório para tecnologia da informação e redes de computadores , sua entrada culminando na especificação X.500 abrangente , um conjunto de protocolos produzidos pela União Internacional de Telecomunicações (UIT) na década de 1980.

Os serviços de diretório X.500 eram tradicionalmente acessados ​​por meio do X.500 Directory Access Protocol (DAP), que exigia a pilha de protocolos Open Systems Interconnection (OSI) . O LDAP foi originalmente planejado para ser um protocolo alternativo leve para acessar serviços de diretório X.500 por meio da pilha de protocolos TCP / IP mais simples (e agora amplamente difundida) . Este modelo de acesso ao diretório foi emprestado dos protocolos DIXIE e Directory Assistance Service .

O protocolo foi originalmente criado por Tim Howes da Universidade de Michigan , Steve Kille da Isode Limited, Colin Robbins da Nexor e Wengyik Yeong da Performance Systems International , por volta de 1993, como sucessor do DIXIE e DAS . Mark Wahl da Critical Angle Inc., Tim Howes e Steve Kille começaram a trabalhar em 1996 em uma nova versão do LDAP, LDAPv3, sob a égide da Internet Engineering Task Force (IETF). O LDAPv3, publicado pela primeira vez em 1997, substituiu o LDAPv2 e adicionou suporte para extensibilidade, integrou a Camada de Autenticação e Segurança Simples e melhor alinhou o protocolo à edição de 1993 do X.500. O desenvolvimento das próprias especificações LDAPv3 e de numerosas extensões adicionando recursos ao LDAPv3 veio por meio da IETF .

Nos primeiros estágios de engenharia do LDAP, ele era conhecido como Lightweight Directory Browsing Protocol ou LDBP . Ele foi renomeado com a expansão do escopo do protocolo além da navegação e pesquisa de diretório, para incluir funções de atualização de diretório. Recebeu o nome de Lightweight porque não fazia uso intensivo da rede como seu predecessor DAP e, portanto, foi mais facilmente implementado na Internet devido ao uso de largura de banda relativamente modesto.

O LDAP influenciou os protocolos subsequentes da Internet, incluindo versões posteriores do X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML) e Service Location Protocol (SLP). Ele também é usado como base para o Active Directory da Microsoft .

Visão geral do protocolo

Um cliente inicia uma sessão LDAP conectando-se a um servidor LDAP, chamado Directory System Agent (DSA), por padrão nas portas TCP e UDP 389 ou na porta 636 para LDAPS (LDAP sobre TLS / SSL, veja abaixo). O cliente então envia uma solicitação de operação ao servidor e um servidor envia respostas em troca. Com algumas exceções, o cliente não precisa esperar por uma resposta antes de enviar a próxima solicitação e o servidor pode enviar as respostas em qualquer ordem. Todas as informações são transmitidas usando regras básicas de codificação (BER).

O cliente pode solicitar as seguintes operações:

  • StartTLS - use a extensão LDAPv3 Transport Layer Security (TLS) para uma conexão segura
  • Vincular - autenticar e especificar a versão do protocolo LDAP
  • Pesquisar - pesquisar e / ou recuperar entradas do diretório
  • Comparar - testar se uma entrada nomeada contém um determinado valor de atributo
  • Adicionar uma nova entrada
  • Excluir uma entrada
  • Modificar uma entrada
  • Modificar nome distinto (DN) - mover ou renomear uma entrada
  • Abandonar - aborta um pedido anterior
  • Operação estendida - operação genérica usada para definir outras operações
  • Desvincular - feche a conexão (não o inverso de Vincular)

Além disso, o servidor pode enviar "Notificações não solicitadas" que não sejam respostas a nenhuma solicitação, por exemplo, antes que o tempo limite da conexão seja atingido.

Um método alternativo comum de proteger a comunicação LDAP é usar um túnel SSL . A porta padrão para LDAP sobre SSL é 636. O uso de LDAP sobre SSL era comum no LDAP Versão 2 (LDAPv2), mas nunca foi padronizado em nenhuma especificação formal. Esse uso foi descontinuado junto com o LDAPv2, que foi oficialmente retirado em 2003.

Estrutura de diretório

O protocolo fornece uma interface com diretórios que seguem a edição de 1993 do modelo X.500 :

  • Uma entrada consiste em um conjunto de atributos.
  • Um atributo possui um nome (um tipo de atributo ou descrição de atributo ) e um ou mais valores. Os atributos são definidos em um esquema (veja abaixo).
  • Cada entrada possui um identificador exclusivo: seu nome distinto (DN). Isso consiste em seu Nome Distinto Relativo (RDN), construído a partir de algum (s) atributo (s) na entrada, seguido pelo DN da entrada pai. Pense no DN como o caminho completo do arquivo e o RDN como seu nome de arquivo relativo em sua pasta pai (por exemplo, se /foo/bar/myfile.txtfosse o DN, myfile.txtseria o RDN).

Um DN pode mudar durante o tempo de vida da entrada, por exemplo, quando as entradas são movidas dentro de uma árvore. Para identificar entradas de forma confiável e inequívoca, um UUID pode ser fornecido no conjunto de atributos operacionais da entrada .

Uma entrada pode ter a seguinte aparência quando representada no formato de intercâmbio de dados LDAP (LDIF) (o próprio LDAP é um protocolo binário ): 

 dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1232
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

" dn" é o nome distinto da entrada; não é um atributo nem uma parte da entrada. " cn=John Doe" é o RDN (Nome Distinto Relativo) da entrada e " dc=example,dc=com" é o DN da entrada pai, onde " dc" denota ' Componente de Domínio '. As outras linhas mostram os atributos da entrada. Nomes de atributos são tipicamente strings mnemônicas, como " cn" para nome comum, " dc" para componente de domínio, " mail" para endereço de e-mail e " sn" para sobrenome.

Um servidor contém uma subárvore começando com uma entrada específica, por exemplo, " dc=example,dc=com" e seus filhos. Os servidores também podem conter referências a outros servidores, portanto, uma tentativa de acesso " ou=department,dc=example,dc=com" pode retornar uma referência ou referência de continuação a um servidor que contém essa parte da árvore de diretórios. O cliente pode então entrar em contato com o outro servidor. Alguns servidores também suportam encadeamento , o que significa que o servidor contata o outro servidor e retorna os resultados ao cliente.

O LDAP raramente define qualquer ordem: o servidor pode retornar os valores de um atributo, os atributos em uma entrada e as entradas encontradas por uma operação de pesquisa em qualquer ordem. Isso decorre das definições formais - uma entrada é definida como um conjunto de atributos e um atributo é um conjunto de valores, e os conjuntos não precisam ser ordenados.

Operações

Adicionar

A operação ADD insere uma nova entrada no banco de dados do servidor de diretório. Se o nome distinto na solicitação de adição já existir no diretório, o servidor não adicionará uma entrada duplicada, mas definirá o código de resultado no resultado da adição para o decimal 68, "entryAlreadyExists".

  • Os servidores compatíveis com LDAP nunca removerão a referência do nome distinto transmitido na solicitação de inclusão ao tentar localizar a entrada, ou seja, os nomes distintos nunca são removidos do alias.
  • Os servidores compatíveis com LDAP garantirão que o nome distinto e todos os atributos estejam em conformidade com os padrões de nomenclatura.
  • A entrada a ser adicionada não deve existir, e o superior imediato deve existir.
dn: uid=user,ou=people,dc=example,dc=com
changetype: add
objectClass:top
objectClass:person
uid: user
sn: last-name
cn: common-name
userPassword: password

No exemplo acima, uid=user,ou=people,dc=example,dc=comnão deve existir e ou=people,dc=example,dc=comdeve existir.

Vincular (autenticar)

Quando uma sessão LDAP é criada, ou seja, quando um cliente LDAP se conecta ao servidor, o estado de autenticação da sessão é definido como anônimo. A operação BIND estabelece o estado de autenticação para uma sessão.

Simple BIND e SASL PLAIN podem enviar o DN e a senha do usuário em texto simples , portanto, as conexões que utilizam Simple ou SASL PLAIN devem ser criptografadas usando Transport Layer Security (TLS). O servidor normalmente verifica a senha em relação ao userPassword atributo na entrada nomeada. BIND anônimo (com DN e senha vazios) redefine a conexão para o estado anônimo.

SASL (Simple Authentication and Security Layer) BIND fornece serviços de autenticação através de uma ampla gama de mecanismos, por exemplo, Kerberos ou o certificado de cliente enviado com TLS.

O BIND também define a versão do protocolo LDAP enviando um número de versão na forma de um inteiro. Se o cliente solicitar uma versão não compatível com o servidor, o servidor deverá definir o código de resultado na resposta BIND ao código de erro de protocolo. Normalmente, os clientes devem usar LDAPv3, que é o padrão no protocolo, mas nem sempre nas bibliotecas LDAP.

O BIND deve ser a primeira operação em uma sessão no LDAPv2, mas não é obrigatório no LDAPv3. No LDAPv3, cada solicitação BIND bem-sucedida altera o estado de autenticação da sessão e cada solicitação BIND malsucedida redefine o estado de autenticação da sessão.

Excluir

Para excluir uma entrada, um cliente LDAP transmite ao servidor uma solicitação de exclusão devidamente formada.

  • Um pedido de exclusão deve conter o nome distinto da entrada a ser excluída
  • Os controles de solicitação também podem ser anexados à solicitação de exclusão
  • Os servidores não cancelam a referência de aliases ao processar uma solicitação de exclusão
  • Apenas entradas folha (entradas sem subordinados) podem ser excluídas por uma solicitação de exclusão. Alguns servidores suportam um atributo operacional hasSubordinatescujo valor indica se uma entrada possui alguma entrada subordinada e alguns servidores suportam um atributo operacional que numSubordinatesindica o número de entradas subordinadas à entrada que contém o numSubordinatesatributo.
  • Alguns servidores suportam o controle de solicitação de exclusão de subárvore, permitindo a exclusão do DN e de todos os objetos subordinados ao DN, sujeitos aos controles de acesso. As solicitações de exclusão estão sujeitas a controles de acesso, ou seja, se uma conexão com um determinado estado de autenticação terá permissão para excluir uma determinada entrada é governado por mecanismos de controle de acesso específicos do servidor.

Pesquise e compare

A operação de pesquisa é usada para pesquisar e ler entradas. Seus parâmetros são:

baseObject
O nome da entrada do objeto base (ou possivelmente a raiz) em relação à qual a pesquisa deve ser realizada.
alcance
Quais elementos abaixo do baseObject pesquisar. Isso pode ser BaseObject(pesquise apenas a entrada nomeada, normalmente usada para ler uma entrada), singleLevel(entradas imediatamente abaixo do DN de base) ou wholeSubtree(a subárvore inteira começando no DN de base).
filtro
Critérios a serem usados ​​na seleção de elementos dentro do escopo. Por exemplo, o filtro (&(objectClass=person)(|(givenName=John)(mail=john*)))selecionará "pessoas" (elementos de objectClass person) para as quais as regras de correspondência givenNamee maildeterminará se os valores desses atributos correspondem à declaração do filtro. Observe que um equívoco comum é que os dados do LDAP diferenciam maiúsculas de minúsculas, ao passo que, na verdade, as regras de correspondência e as regras de ordenação determinam a correspondência, as comparações e as relações de valor relativo. Se os filtros de exemplo forem necessários para corresponder ao caso do valor do atributo, um filtro de correspondência extensível deve ser usado, por exemplo,(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
derefAliases
Se e como seguir entradas de alias (entradas que se referem a outras entradas),
atributos
Quais atributos devem ser retornados nas entradas de resultado.
sizeLimit, timeLimit
Número máximo de entradas a serem retornadas e tempo máximo para permitir a execução da pesquisa. Esses valores, no entanto, não podem substituir as restrições que o servidor coloca no limite de tamanho e limite de tempo.
typesOnly
Retorna apenas tipos de atributos, não valores de atributos.

O servidor retorna as entradas correspondentes e referências de continuação potencialmente. Eles podem ser devolvidos em qualquer ordem. O resultado final incluirá o código do resultado.

A operação Comparar pega um DN, um nome de atributo e um valor de atributo e verifica se a entrada nomeada contém esse atributo com esse valor.

Modificar

A operação MODIFY é usada por clientes LDAP para solicitar que o servidor LDAP faça alterações nas entradas existentes. As tentativas de modificar entradas que não existem falharão. As solicitações MODIFY estão sujeitas aos controles de acesso implementados pelo servidor.

A operação MODIFY requer que o nome distinto (DN) da entrada seja especificado e uma sequência de alterações. Cada mudança na sequência deve ser uma das seguintes:

  • add (adiciona um novo valor, que ainda não deve existir no atributo)
  • deletar (deletar um valor existente)
  • substituir (substituir um valor existente por um novo valor)

Exemplo de LDIF de adição de um valor a um atributo: 

dn: dc=example,dc=com
changetype: modify
add: cn
cn: the-new-cn-value-to-be-added
-

Para substituir o valor de um atributo existente, use a replacepalavra - chave. Se o atributo tiver vários valores, o cliente deve especificar o valor do atributo a ser atualizado.

Para excluir um atributo de uma entrada, use a palavra-chave deletee o designador de changetype modify. Se o atributo tiver vários valores, o cliente deve especificar o valor do atributo a ser excluído.

Há também uma extensão Modify-Increment que permite que um valor de atributo incrementável seja incrementado por um valor especificado. O exemplo a seguir usando incrementos de LDIF employeeNumberpor 5: 

dn: uid=user.0,ou=people,dc=example,dc=com
changetype: modify
increment: employeeNumber
employeeNumber: 5
-

Quando os servidores LDAP estão em uma topologia replicada, os clientes LDAP devem considerar o uso do controle pós-leitura para verificar as atualizações em vez de uma pesquisa após uma atualização. O controle pós-leitura é projetado para que os aplicativos não precisem emitir uma solicitação de pesquisa após uma atualização - é uma má forma de recuperar uma entrada com o único propósito de verificar se uma atualização funcionou devido ao modelo de consistência eventual de replicação . Um cliente LDAP não deve presumir que se conecta ao mesmo servidor de diretório para cada solicitação porque os arquitetos podem ter colocado balanceadores de carga ou proxies LDAP ou ambos entre clientes e servidores LDAP.

Modificar DN

Modificar DN (mover / renomear entrada) leva o novo RDN (Nome Distinto Relativo), opcionalmente, o novo DN do pai e um sinalizador que indica se deve excluir o (s) valor (es) na entrada que corresponde ao RDN antigo. O servidor pode suportar a renomeação de subárvores inteiras de diretório.

Uma operação de atualização é atômica: outras operações verão a nova entrada ou a antiga. Por outro lado, o LDAP não define transações de várias operações: se você ler uma entrada e depois modificá-la, outro cliente pode ter atualizado a entrada nesse meio tempo. Os servidores podem implementar extensões que suportam isso, no entanto.

Operações estendidas

A Operação Estendida é uma operação LDAP genérica que pode definir novas operações que não faziam parte da especificação do protocolo original. StartTLS é uma das extensões mais significativas. Outros exemplos incluem Cancelar e Modificar senha.

StartTLS

A operação StartTLS estabelece o Transport Layer Security (o descendente do SSL ) na conexão. Ele pode fornecer confidencialidade de dados (para proteger os dados de serem observados por terceiros) e / ou proteção de integridade de dados (que protege os dados de adulteração). Durante a negociação TLS, o servidor envia seu certificado X.509 para provar sua identidade. O cliente também pode enviar um certificado para comprovar sua identidade. Depois de fazer isso, o cliente pode usar SASL / EXTERNAL. Ao usar SASL / EXTERNAL, o cliente solicita que o servidor obtenha sua identidade de credenciais fornecidas em um nível inferior (como TLS). Embora tecnicamente o servidor possa usar qualquer informação de identidade estabelecida em qualquer nível inferior, normalmente o servidor usará a informação de identidade estabelecida por TLS.

Os servidores também freqüentemente suportam o protocolo não padrão "LDAPS" ("LDAP seguro", comumente conhecido como "LDAP sobre SSL") em uma porta separada, por padrão 636. O LDAPS difere do LDAP de duas maneiras: 1) ao conectar, o o cliente e o servidor estabelecem o TLS antes que qualquer mensagem LDAP seja transferida (sem uma operação StartTLS) e 2) a conexão LDAPS deve ser fechada após o fechamento do TLS.

Algumas bibliotecas de cliente "LDAPS" criptografam apenas a comunicação; eles não verificam o nome do host em relação ao nome no certificado fornecido.

Abandono

A operação Abandonar solicita que o servidor aborte uma operação nomeada por um ID de mensagem. O servidor não precisa honrar o pedido. Nem Abandon, nem uma operação abandonada com sucesso enviam uma resposta. Uma operação estendida Cancelar semelhante envia respostas, mas nem todas as implementações suportam isso.

Desvincular

A operação Unbind abandona todas as operações pendentes e fecha a conexão. Não tem resposta. O nome é de origem histórica e não é o oposto da operação Bind.

Os clientes podem abortar uma sessão simplesmente fechando a conexão, mas devem usar Unbind. O Unbind permite que o servidor feche a conexão normalmente e libere recursos que, de outra forma, ele manteria por algum tempo até descobrir que o cliente havia abandonado a conexão. Ele também instrui o servidor a cancelar as operações que podem ser canceladas e a não enviar respostas para as operações que não podem ser canceladas.

Esquema URI

Existe um esquema de identificador uniforme de recursos (URI) LDAP , que os clientes suportam em vários graus, e os servidores retornam em referências e referências de continuação (consulte RFC 4516): 

ldap://host:port/DN?attributes?scope?filter?extensions

A maioria dos componentes descritos abaixo são opcionais.

  • host é o FQDN ou endereço IP do servidor LDAP a ser pesquisado.
  • port é a porta de rede ( porta padrão 389) do servidor LDAP.
  • DN é o nome distinto a ser usado como base de pesquisa.
  • atributos é uma lista separada por vírgulas de atributos a serem recuperados.
  • O escopo especifica o escopo da pesquisa e pode ser "base" (o padrão), "um" ou "sub".
  • filtro é um filtro de pesquisa. Por exemplo, (objectClass=*)conforme definido no RFC 4515.
  • extensões são extensões para o formato de URL LDAP.

Por exemplo, " ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refere-se a todos os atributos do usuário na entrada de John Doe em ldap.example.com, enquanto " ldap:///dc=example,dc=com??sub?(givenName=John)" procura a entrada no servidor padrão (observe a barra tripla, omitindo o host, e o ponto de interrogação duplo, omitindo os atributos). Como em outros URLs, os caracteres especiais devem ser codificados por porcentagem .

Existe um ldapsesquema de URI não padrão semelhante para LDAP sobre SSL. Isso não deve ser confundido com LDAP com TLS, que é obtido usando a operação StartTLS usando o ldapesquema padrão .

Esquema

O conteúdo das entradas em uma subárvore é governado por um esquema de diretório , um conjunto de definições e restrições relativas à estrutura da árvore de informações de diretório (DIT).

O esquema de um Directory Server define um conjunto de regras que regem os tipos de informações que o servidor pode conter. Possui vários elementos, incluindo:

  • Sintaxe de atributo - fornece informações sobre o tipo de informação que pode ser armazenada em um atributo.
  • Regras de correspondência - fornecem informações sobre como fazer comparações com os valores dos atributos.
  • Usos de regras de correspondência - indica quais tipos de atributos podem ser usados ​​em conjunto com uma regra de correspondência específica.
  • Tipos de atributo - defina um identificador de objeto (OID) e um conjunto de nomes que podem se referir a um determinado atributo e associa esse atributo a uma sintaxe e a um conjunto de regras correspondentes.
  • Classes de objeto - defina coleções nomeadas de atributos e classifique-as em conjuntos de atributos obrigatórios e opcionais.
  • Formulários de nome - defina regras para o conjunto de atributos que devem ser incluídos no RDN para uma entrada.
  • Regras de conteúdo - defina restrições adicionais sobre as classes de objeto e atributos que podem ser usados ​​em conjunto com uma entrada.
  • Regra de estrutura - defina as regras que governam os tipos de entradas subordinadas que uma determinada entrada pode ter.

Atributos são os elementos responsáveis ​​por armazenar informações em um diretório, e o esquema define as regras para quais atributos podem ser usados ​​em uma entrada, os tipos de valores que esses atributos podem ter e como os clientes podem interagir com esses valores.

Os clientes podem aprender sobre os elementos do esquema que o servidor suporta, recuperando uma subentrada de subesquema apropriada.

O esquema define classes de objetos . Cada entrada deve ter um atributo objectClass, contendo classes nomeadas definidas no esquema. A definição do esquema das classes de uma entrada define que tipo de objeto a entrada pode representar - por exemplo, uma pessoa, organização ou domínio. As definições de classe de objeto também definem a lista de atributos que devem conter valores e a lista de atributos que podem conter valores.

Por exemplo, uma entrada que representa uma pessoa pode pertencer às classes "superior" e "pessoa". A associação à classe "person" exigiria que a entrada contivesse os atributos "sn" e "cn" e permitiria que a entrada também contivesse "userPassword", "telephoneNumber" e outros atributos. Como as entradas podem ter vários valores ObjectClasses, cada entrada tem um complexo de conjuntos de atributos opcionais e obrigatórios formados a partir da união das classes de objetos que representa. ObjectClasses podem ser herdados e uma única entrada pode ter vários valores ObjectClasses que definem os atributos disponíveis e necessários da própria entrada. Um paralelo ao esquema de uma objectClass é uma definição de classe e uma instância na programação orientada a objetos , representando a objectClass LDAP e a entrada LDAP, respectivamente.

Os servidores de diretório podem publicar o esquema de diretório controlando uma entrada em um DN base fornecido pelo atributo operacional subschemaSubentry da entrada. (Um atributo operacional descreve a operação do diretório em vez das informações do usuário e só é retornado de uma pesquisa quando é explicitamente solicitado.)

Os administradores do servidor podem adicionar entradas de esquema adicionais além dos elementos de esquema fornecidos. Um esquema para representar pessoas individuais dentro das organizações é denominado esquema de páginas em branco .

Variações

Grande parte da operação do servidor é deixada para o implementador ou administrador decidir. Da mesma forma, os servidores podem ser configurados para oferecer suporte a uma ampla variedade de cenários.

Por exemplo, o armazenamento de dados no servidor não é especificado - o servidor pode usar arquivos simples, bancos de dados ou apenas ser um gateway para algum outro servidor. O controle de acesso não é padronizado, embora tenha havido trabalho nisso e haja modelos comumente usados. As senhas dos usuários podem ser armazenadas em suas entradas ou em outro lugar. O servidor pode se recusar a realizar operações quando desejar e impor vários limites.

A maioria das partes do LDAP são extensíveis. Exemplos: pode-se definir novas operações. Os controles podem modificar solicitações e respostas, por exemplo, para solicitar resultados de pesquisa classificados. Novos escopos de pesquisa e métodos de vinculação podem ser definidos. Os atributos podem ter opções que podem modificar sua semântica.

Outros modelos de dados

À medida que o LDAP ganhou impulso, os fornecedores o forneceram como um protocolo de acesso a outros serviços. A implementação, então, reformula os dados para imitar o modelo LDAP / X.500, mas o grau de aproximação desse modelo varia. Por exemplo, existe um software para acessar bancos de dados SQL por meio do LDAP, embora o LDAP não se preste a isso prontamente. Os servidores X.500 também podem oferecer suporte a LDAP.

Da mesma forma, os dados anteriormente mantidos em outros tipos de armazenamentos de dados às vezes são movidos para diretórios LDAP. Por exemplo, as informações de usuários e grupos do Unix podem ser armazenadas no LDAP e acessadas por meio dos módulos PAM e NSS . O LDAP é freqüentemente usado por outros serviços para autenticação e / ou autorização (quais ações um determinado usuário já autenticado pode realizar em qual serviço). Por exemplo, no Active Directory, o Kerberos é usado na etapa de autenticação, enquanto o LDAP é usado na etapa de autorização.

Um exemplo de tal modelo de dados é o GLUE Schema, que é usado em um sistema de informação distribuído baseado em LDAP que permite que usuários, aplicativos e serviços descubram quais serviços existem em uma infraestrutura Grid e mais informações sobre sua estrutura e estado.

Uso

Um servidor LDAP pode retornar referências a outros servidores para solicitações que ele não pode atender sozinho. Isso requer uma estrutura de nomenclatura para as entradas do LDAP, de forma que se possa encontrar um servidor com um determinado nome distinto (DN), um conceito definido no diretório X.500 e também usado no LDAP. Outra maneira de localizar servidores LDAP para uma organização é um registro de servidor DNS (SRV).

Uma organização com o domínio example.org pode usar o DN do LDAP de nível superior dc=example,dc=org(onde dc significa componente do domínio). Se o servidor LDAP também for denominado ldap.example.org, o URL LDAP de nível superior da organização se tornará ldap://ldap.example.org/dc=example,dc=org.

Principalmente dois estilos comuns de nomenclatura são usados ​​no X.500 [2008] e no LDAPv3. Eles estão documentados nas especificações da ITU e nos RFCs da IETF. A forma original leva o objeto de nível superior como o objeto país, tais como c=US, c=FR. O modelo de componente de domínio usa o modelo descrito acima. Um exemplo de nomeação baseado no país poderia ser l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR, ou nos EUA: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.

Veja também

Referências

Notas

Leitura adicional

links externos