Network Working Group Request for Comments: 1777 Obsoletes: 1487 Category: Standards Track

W. Yeong Performance Systems International T. Howes University of Michigan S. Kille ISODE Consortium Marzo 1995

El Protocolo Ligero de Acceso a Directorio (LDAP) Estado de este Memorndum Este documento especifica una serie de normas de protocolo de Internet para la comunidad de Internet, y pide un debate y sugerencias para las mejoras. Por favor referirse a la edicin actual de los "Protocolos Normalizados Oficiales de Internet" (STD 1) para el estado y control de la estandarizacin de este protocolo. La distribucin de este memorndum es ilimitada. Introduccin El protocolo descrito en este documento est diseado para proveer acceso al Directorio X.500 a la vez que no utiliza todos los recursos requeridos por el Protocolo de Acceso a Directorio (DAP). Este protocolo est especficamente orientado a aplicaciones simples de gestin y buscadores de aplicaciones que provean accesos sencillos de lectura/escritura interactiva al directorio X.500, y tiene la intencin de ser un complemento al propio DAP. Los aspectos claves de LDAP son: - Los elementos protocolares se llevan directamente sobre TCP u otro transporte, dejando de lado muchos de los costes de sesin/presentacin. - Muchos elementos protocolares de datos estn codificados como cadenas ordinarias (p. ej., Los Nombres Distinguidos). - Un codificacin ligera BER se usa para codificar todos los elementos protocolares. 1. Historia El tremendo inters en la tecnologa X.500 [1,2] para Internet tiene el liderazgo en los esfuerzos para reducir el alto "costo de entrada" asociado con el uso de la tecnologa, como el Servicio de Asistencia al Directorio [3] y DIXIE [4]. Mientras esfuerzos tales como estos han encontrado el xito, han sido soluciones basadas en

Yeong, Hows & Kille

[Pgina 1]

RFC 1777

LDAP

Marzo 1995

implementaciones particulares y como tal han limitado el campo de aplicacin. Este documento contina los esfuerzos para definir alternativas protocolares de Directorio pero parte desde esfuerzos previos que a sabiendas evita dependencias de implementaciones particulares. 2. El Modelo del Protocolo El modelo general adoptado por este protocolo es de los clientes realizando operaciones protocolares contra servidores. En este modelo, esto es realizado por un cliente que transmite una peticin protocolar que describe la operacin para ser realizada por el servidor, que es entonces responsable de hacer las operaciones necesarias sobre el Directorio. Al terminar las operaciones necesarias, el servidor devuelve una respuesta conteniendo cualquier resultado o error al cliente solicitante. Tratando de aligerar los costos asociados con el uso del Directorio, es un objetivo de este protocolo minimizar la complejidad de los clientes para facilitar el despliegue generalizado de las aplicaciones capaces de utilizar el Directorio. Note que, aunque se exige que los servidores devuelvan respuestas cuando tales respuestas se definen en el protocolo, no hay requisitos para el comportamiento sncrono por parte de las implementaciones del cliente o servidor: las peticiones y las respuestas para operaciones mltiples pueden ser cambiados por cliente y servidor en cualquier orden, mientras los clientes eventualmente reciben una respuesta para cada petcicin que solicitan. Coherente con el modelo de servidores que realizan operaciones protocolares en el nombre de clientes, tambin obsrvese que los servidores del protocolo estn expectantes para manejar referencias sin echar mano del regreso de tales remisiones al cliente. Este protocolo no tiene clusulas para el regreso de referencias a los clientes, como el modelo es uno de los servidores garantizando la realizacin de todas las operaciones necesarias en el Directorio, solo los errores o resultados finales son devueltos por los servidores a los clientes. Note que este protocolo puede ser acotado al subconjunto estricto del servicio abstracto de directorio, por tanto puede ser ntidamente facilitado por el DAP. 3. Mapeo sobre los Servicios de Transporte Este protocolo est diseado para funcionar sobre transportes orientados a conexin y fiables, siendo todos los 8 bits de un octeto significativos en el flujo de datos. Se definen aqu especificaciones

Yeong, Hows & Kille

[Pgina 2]

RFC 1777

LDAP

Marzo 1995

para dos servicios subyacentes, aunque son posibles otros. 3.1. El protocolo de Control de Transmisin (TCP) Las PDUs del LDAPMessage se traducen directamente a octetos en el flujo TCP Las implementaciones de servidor que corren sobre TCP deberan proveer un servidor escuche en el puerto 389. 3.2. El Servicio de Transporte Orientado a Conexin (COTS) La conexin se establece. Se hace uso no especial de T-CONNECT. Cada LDAPMessage PDU se combina directamente en T-DATA. 4. Elementos del Protocolo Para los propsitos de cambios de protocolo, todas las operaciones de protocolo se encapsulan en un empaquetado ("sobre") comn, el LDAPMessage, que se define como se indica a continuacin: LDAPMessage ::= SEQUENCE { messageID protocolOp

MessageID, ELECCION { bindRequest bindResponse unbindRequest searchRequest searchResponse modifyRequest modifyResponse addRequest addResponse delRequest delResponse modifyRDNRequest modifyRDNResponse compareDNRequest compareDNResponse abandonRequest }

BindRequest, BindResponse, UnbindRequest, SearchRequest, SearchResponse, ModifyRequest, ModifyResponse, AddRequest, AddResponse, DelRequest, DelResponse, ModifyRDNRequest, ModifyRDNResponse, CompareRequest, CompareResponse, AbandonRequest

} MessageID ::= EL ENTERO (0 .. maxInt) La funcin del LDAPMessage es proporcionar un sobre conteniendo los campos comunes requeridos en todos los cambios de protocolo. En este momento el campo comn nico es un mensaje ID, que se requiere que tenga un valor diferente de los valores de cualquier otras peticiones

Yeong, Hows & Kille

[Pgina 3]

RFC 1777

LDAP

Marzo 1995

excepcional en la sesin LDAP del que este mensaje es una parte. El mensaje ID de valor debe repetirse en todo LDAPMessage de sobres encapsulando las respuestas que corresponden a la peticin contenido en el LDAPMessage en que el valor del mensaje ID se us originalmente. Adems del LDAPMessage definido arriba, las siguientes descripciones se usan tambin en definir operaciones protocolares: LDAPString ::= OCTET STRING El LDAPString es una convencin de marca para indicar que, aunque las cadenas de tipo LDAPString se codifican como tipo OCTET STRING, el conjunto legal de caracteres en tales cadenas se limita al conjunto de caracteres IA5. LDAPDN ::= LDAPString RelativeLDAPDN ::= LDAPString Un LDAPDN y un RelativeLDAPDN se definen respectivamente para ser la representacin de un Nombre Distinguido y un Nombre de Pariente Distinguido despus de codificar segn la especificacin en [5], tal como <distinguished-name> ::= <name> <relative-distinguished-name> ::= <name-component> donde <name> y <name-component> son definidos como en [5]. AttributeValueAssertion ::= SEQUENCE { attributeType AttributeType, attributeValue AttributeValue } La definicin de tipo AttributeValueAssertion es parecido al uno en las normas de Directorio X.500. AttributeType ::= LDAPString AttributeValue ::= OCTET STRING Un valor AttributeType toma como su valor la cadena de texto asociada con ese AttributeType en las normas de Directorio X.500. Por ejemplo, el AttributeType 'organizationName' con el objeto

Yeong, Hows & Kille

[Pgina 4]

RFC 1777

LDAP

Marzo 1995

identificador 2.5.4.10 se representa como un AttributeType en este protocolo por la cadena "organizationName". En el caso que que una implementacin protocolar encuentre un tipo de Atributo que no puede asociar a una cadena de texto, una cadena codificada en ASCII del objeto identificador asociado con el Tipo de Atributo puede ser substituido. Por ejemplo, el tipo de atributo organizationName puede ser representado por la cadena ASCII "2.5.4.10" si una implementacin de protocolo es incapaz de asociar la cadena "organizationName" con l. Un campo de tipo AttributeValue toma como su valor una cadena de octeto codificada de un tipo de Directorio AttributeValue. La definicin de estas cadenas codificadas por diferentes tipos de Directorio AttributeValue pueden ser encontrados acompaando a este documento que define la codificacin de diversas sintaxis de atributo tal como [6]. LDAPResult ::= SEQUENCE { resultCode

ENUMERATED { success operationsError protocolError timeLimitExceeded sizeLimitExceeded compareFalse compareTrue authMethodNotSupported strongAuthRequired noSuchAttribute undefinedAttributeType inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax noSuchObject aliasProblem invalidDNSyntax isLeaf aliasDereferencingProblem inappropriateAuthentication invalidCredentials insufficientAccessRights busy unavailable unwillingToPerform loopDetect namingViolation

(0), (1), (2), (3), (4), (5), (6), (7), (8), (16), (17), (18), (19), (20), (21), (32), (33), (34), (35), (36), (48), (49), (50), (51), (52), (53), (54), (64),

Yeong, Hows & Kille

[Pgina 5]

RFC 1777

LDAP objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists objectClassModsProhibited other }, matchedDN LDAPDN, errorMessage LDAPString }

Marzo 1995 (65), (66), (67), (68), (69), (80)

El LDAPResult es construido usando este protocolo para devolver el indicativo de xito o fracaso desde servidores a clientes. En respuesta a diversos peticiones, los servidores devolvern las respuestas que contienen campos de tipo LDAPResult para indicar la condicin final de una peticin de operacin de protocolo. El campo errorMessage de esta construccin puede, en la opcin de servidores, ser usado para devolver una cadena ASCII conteniendo un texto, diagnstico de error legible por el hombre. Como este diagnstico de error no est normalizado, las implementaciones no deberan confiar en los valores devueltos. Si el servidor escoge no devolver un diagnstico de texto, el campo errorMessage del tipo LDAPResult debera contener una longitud de cadena 0. Para resultCodes de noSuchObject, aliasProblem, invalidDNSyntax, isLeaf, y aliasDereferencing, el campo matchedDN es puesto al nombre de la entrada mas baja (objeto o alias) en el DIT que era equiparado y es una forma truncada del nombre provisto o, si un alias ha sido quitado la nota, del nombre resultante. El campo matchedDN deber colocarse a DN NULO (una cadena de longitud 0) en el resto de casos. 4.1. Operacin de Enlace La funcin de la Operacin de Compromiso es iniciar una sesin protocolar entre un cliente y un servidor, y para permitir la autenticacin del cliente al servidor. La Operacin de Compromiso debe ser la operacin de peticin primera recibida por un servidor desde un cliente en una sesin protocolar. La Peticin de Compromiso se define como se indica a continuacin: BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication CHOICE { simple [0] OCTET STRING, krbv42LDAP [1] OCTET STRING, krbv42DSA [2] OCTET STRING

Yeong, Hows & Kille

[Pgina 6]

RFC 1777 } }

LDAP

Marzo 1995

Los parmetros de la Peticin de Compromiso son: - version: Un nmero de versin que indica la versin del protocolo a ser usado en esta sesin protocolar. Este documento describe la versin 2 del protocolo LDAP. Anote que no hay negociacin de versin, y el cliente debera colocar simplemente este parmetro a la versin que desea. - name: El nombre del objeto Directorio que el cliente desea como compromiso. Este campo puede tomar sobre un valor nulo (una cadena de longitud cero) para los propsitos de compromisos annimos. - autentication: la informacin usada para autenticar el nombre, si cualquier, provedo en la Peticin de Compromiso. La opcin de autenticacin "simple" provee instalaciones mnimas de autenticacin, con los contenidos de campo de autenticacin que consiste solo en una contrasea limpia de texto. Esta opcin se usara tambin cuando no identificados o annimos compromisos son ejecutados, con el campo que contiene una cadena de longitud cero en tales casos. La autenticacin Kerberos de versin 4 [7] al servidor de LDAP y el DSA es realizado por usar las opciones de autenticacin "krbv42LDAP" y "krbv42DSA", respectivamente. Anote que aunque ellos se refieren a las entidades separadas aqu, no debe el requerimiento de estas dos entidades ser distinto (es decir, un DSA podra hablar directamente LDAP). Dos opciones separadas de autenticacin se proveen para apoyar todas las implementaciones. Cada cadena de octeto debera contener el billete kerberos (p. ej., devuelto por krb_mk_req()) para el servicio apropiado. El nombre de servicio sugerido para la autenticacin al servidor de LDAP es "ldapserver". El nombre de servicio sugerido para la autenticacin al DSA es "x500dsa". En ambos casos, el el nombre sugerido de ejemplo para el servicio es el nombre del host sobre el que corre el servicio. Por supuesto, el servicio de nombres actual y las instancias dependern de qu estn introducidas desde el principio en la base de datos local kerberos. La Operacin de Compromiso requiere una respuesta, la Respuesta de Compromiso, que sea definida como: BindResponse ::= [APPLICATION 1] LDAPRESULT Una Respuesta de Compromiso consiste simplemente de un indicativo desde el servidor de la condicin de la peticin del cliente para la iniciar una sesin de protocolo.

Yeong, Hows & Kille

[Pgina 7]

RFC 1777

LDAP

Marzo 1995

Al recibir una Peticin de Enlace, un servidor protocolar autenticar el cliente solicitante si es necesario, e intentar establecer una sesin de protocolo con ese cliente. El servidor volver entonces una Respuesta de Compromiso al cliente que indica la condicin de la sesin de peticin de estructura. 4.2. Operacin Desconectar La funcin de la Operacin Desconectar es terminar una sesin de protocolo. La Operacin Desconectar se define como se indica a continuacin: UnbindRequest ::= [APPLICATION 2] NULL La Operacin Desconectar no tiene respuesta definida. Sobre la transmisin de una peticin de desconexin, un cliente puede presumir que la sesin protocolar se termina. Al recibir una peticin de desconexin, un servidor de protocolo puede presumir que el cliente solicitante ha terminado la sesin y que todos las peticiones pendientes pueden desecharse. 4.3. Operacin Bsqueda La Operacin de Bsqueda permite a un cliente pedir que el servidor realiza una bsqueda. La Peticin de Bsqueda se define como sigue: SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2) }, derefAliases ENUMERATED { neverDerefAliases derefInSearching derefFindingBaseObj derefAlways }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), attrsOnly BOOLEAN, filter Filter, attributes SEQUENCE OF AttributeType } Filter ::=

(0), (1), (2), (3)

Yeong, Hows & Kille

[Pgina 8]

RFC 1777 CHOICE { and or not equalityMatch substrings greaterOrEqual lessOrEqual present approxMatch }

LDAP

Marzo 1995

[0] [1] [2] [3] [4] [5] [6] [7] [8]

SET OF Filter, SET OF Filter, Filter, AttributeValueAssertion, SubstringFilter, AttributeValueAssertion, AttributeValueAssertion, AttributeType, AttributeValueAssertion

SubstringFilter SEQUENCE { type AttributeType, SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } Los parmetros de la Peticin de Bsqueda son: - baseObject: Un LDAPDN que es la base de entrada relativa de objeto a que se realizar la bsqueda. - scope: Un indicador del alcance para realizar la bsqueda. La semntica de los valores posibles de este campo son idnticas a la semntica del campo de alcance en la Operacin de Bsqueda de Directorio. - derefAliases: Un indicador con respecto a como objetos de alias deberan ser manejado en bsquedas. La semntica de los valores posibles de este campo son, en orden de valor creciente: neverDerefAliases: no quitar notas de alias en buscar o en ubicar el objeto de base de la bsqueda; derefInSearching: quitar notas de alias supeditados de la base de objeto en buscar, pero no en ubicar el objeto base de la bsqueda; derefFindingBaseOb: quitar referencia de alias en ubicar el objeto base de la bsqueda, pero no cuando busca los subordinados de la base de objetos; derefAlways: quitar ambos alias en buscar y en ubicar el

Yeong, Hows & Kille

[Pgina 9]

RFC 1777

LDAP objeto base de la bsqueda.

Marzo 1995

- sizelimit: Un lmite de tamao que restringe el nmero mximo de entradas para ser devuelto como resultado de la bsqueda. Un valor de 0 en este campo indica que ninguna restriccin lmite de tamao est en vigor para la bsqueda. - timelimit: Un lmite de tiempo que restringe el tiempo mximo (en segundos) permitido para una bsqueda. Un valor de 0 en este campo indica que ninguna restriccin de lmite de tiempo est en vigor para la bsqueda. - attrsOnly: Un indicador con respecto a si los resultados de bsqueda deberan contener ambos atributos de tipo y valor, o simplemente atributos de tipo. Configurando este campo a VERDADERO ocasiona solo tipos de atributos (no valores) para ser devueltos. Colocar este campo a FALSO ocasiona ambos tipos de atributo y los valores para ser vueltos. - filter: Un filtro que define las condiciones que deben cumplirse en el orden que la bsqueda encuentre una entrada determinada. - attributes: Una lista de los atributos que cada entrada encontr como un resultado de la bsqueda para ser devuelto. Una lista vaca significa que todos los atributos de cada entrada encontrados en la bsqueda estn para ser devueltos. Los resultados de la bsqueda intentados por el servidor sobre el acuse de recibo de una Peticin de Bsqueda se devuelven en las Respuestas de Bsqueda, definidas como sigue: Search Response ::= CHOICE { entry

resultCode }

[APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes SEQUENCE OF SEQUENCE { AttributeType, SET OF AttributeValue } }, [APPLICATION 5] LDAPResult

Al recibir de una Peticin de Bsqueda, un servidor realizar la bsqueda necesaria del DIT. El servidor devolver al cliente una sucesin de respuestas consistente en:

Yeong, Hows & Kille

[Pgina 10]

RFC 1777

LDAP

Marzo 1995

- Cero o ms Respuestas de Bsqueda cada una consistente de una entrada encontrada durante la bsqueda; con la secuencia de respuesta terminada por - Una Respuesta nica de Bsqueda que contiene un indicativo de xito, o detallando cualquier error que ha ocurrido. Cada entrada devuelta contendr todos los atributos, completos con los valores asociados si es necesario, como se especifica en el campo 'attributes' de la Peticin de Bsqueda. Anote que una operacin de lista X.500 puede ser emulada por un nico nivel LDAP que busca la operacin con un filtro que comprueba la existencia del atributo objectClass, y que una operacin de lectura X.500 puede ser emulada por una operacin de bsqueda de base de objeto LDAP con el mismo filtro. 4.4. Operacin Modificar La Operacin Modificar permite que un cliente pida que se realice una una modificacin del DIB. La peticin de modificacin se define como sigue: ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification SEQUENCE { type AttributeType, values SET OF AttributeValue } } } Los parmetros de la Peticin de Modificar son: - object: El objeto para ser modificado. El valor de este campo debera mostrar el nombre del objeto para ser modificado despus de que todos los alias han sido no referenciados. El servidor no har ninguna desreferencia de alias determinando el objeto para ser modificado.

Yeong, Hows & Kille

[Pgina 11]

RFC 1777

LDAP

Marzo 1995

- Una lista de modificaciones para ser ejecutados sobre la entrada para ser modificada. La lista entera de las modificaciones de entrada deberan realizarse en el orden enumerado, como una operacin atmica nica. Mientras las modificaciones individuales pueden infringir el esquema de Directorio, la entrada resultante despus de la lista entera de modificaciones es ejecutada conforme a los requerimientos del esquema de Directorio. Los valores que pueden tomarse sobre por el campo 'operation' en cada modificacin construida tiene la semntica siguiente respectivamente: add: agrega los valores enumerados al atributo determinado, creando el atributo si es necesario; delete: borra los valores enumerados desde el atributo determinado, quitando el atributo entero si no hay valores enumerados, o si todos los valores actuales del atributo son listados para la eliminacin; replace: reemplaza los valores existentes del atributo determinado con los nuevos valores enumerados, creando el atributo si es necesario. El resultado de la modificacin intentado por el servidor al recibir una Peticin de Modificacin es devolver una Respuesta de Modificacin, definida como sigue: ModifyResponse ::= [APPLICATION 7] LDAPResult Al recibir una Peticin de Modificacin, un servidor ejecutar las modificaciones necesarias al DIB. El servidor devolver al cliente una nica Respuesta de Modificacin indicando o la terminacin exitosa del DIB de modificacin, o la razn del fracaso de la modificacin. Note que debido al requisito de atomicidad en aplicar la lista de modificaciones en la Peticin de Modificacin, el cliente puede esperar que ninguna modificacin de el DIB se ha ejecutado si la Respuesta de Modificacin recibida indica cualquier tipo de error, y que todas las modificaciones pedidas han sido ejecutadas si la Respuesta de Modificacin indica la terminacin exitosa de la Operacin de Modificacin. 4.5. Operacin Aadir La Operacin Aadir permite a un cliente pedir la adicin de una entrada en el Directorio. La Peticin de Aadir se define como se indica a continuacin:

Yeong, Hows & Kille

[Pgina 12]

RFC 1777

LDAP

Marzo 1995

AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attrs SEQUENCE OF SEQUENCE { type AttributeType, values SET OF AttributeValue } } Los parmetros de la Peticin de Aadir son: - entry: el Nombre Distinguido de la entrada para ser agregado. Anote que todos los componentes del nombre a excepcin del ltimo componente de RDN deben existir para que el aadir tenga xito. - attrs: la lista de atributos que constituyen el contenido de la entrada a ser agregados. El resultado de la agregacin intentada por el servidor al recibir una Peticin de Aadir se devuelve en la Respuesta de Aadir, definido como sigue: AddResponse ::= [APPLICATION 9] LDAPResult Al recibir un Peticin de Aadir, un servidor intentar ejecutar la solicitud de aadir. El resultado del intento de aadir se devolver al el cliente en la Respuesta de Aadir. 4.6. Operacin Borrar La Operacin Borrar permite a un cliente pedir la remocin de una entrada del Directorio. La Peticin de Borrar se define como sigue: DelRequest ::= [APPLICATION 10] LDAPDN La Peticin de Borrar consiste solo en el Nombre Distinguido de la entrada para ser eliminada. El resultado del intento de borrado por el el servidor al recibir una Peticin de Borrado se vuelve en la Respuesta de Borrar, definida como se indica a continuacin: DelResponse ::= [APPLICATION 11] LDAPResult Al recibir una Peticin de Borrar, un servidor intentar ejecutar la remocin de la entrada pedida. El resultado del intento de borrar ser devuelto al cliente en la Respuesta de Borrar. Notar que solo una hoja de los objetos pueden borrarse con esta operacin. 4.7. Operacin Modificar RDN

Yeong, Hows & Kille

[Pgina 13]

RFC 1777

LDAP

Marzo 1995

La Operacin Modificar RDN permite a un cliente cambiar el ltimo componente del nombre de una entrada en el Directorio. La Peticin de Modificar RDN es definido como se indica a continuacin: ModifyRDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN } Los parmetros de la Peticin de Modifica RDN son: - entry: el nombre de la entrada para ser cambiado. - newrdn: el RDN que formar el ltimo componente del nuevo nombre. - deleteoldrdn: un parmetro booleano que controla si los viejos valores de atributo RDN deberan guardarse como atributos de la entrada o borrados desde la entrada. El resultado del cambio de nombre intentado por el servidor al recibir una Peticin de Modificar RDN se devuelve en la Respuesta de Modificado RDN, definida como se indica a continuacin: ModifyRDNResponse ::= [APPLICATION 13] LDAPResult Al recibir una Peticin de Modificar RDN, un servidor intentar ejecutar el cambio de nombre. El resultado del intento de cambio de nombre se devolver al cliente en la Respuesta de Modificado RDN. Los atributos que constituyen el RDN viejo se borrarn desde la entrada, o guardarn, dependiendo de la configuracin del parmetro deleteoldrdn. 4.8. Operacin Comparar La Operacin Comparar permite a un cliente comparar una afirmacin facilitada con una entrada en el Directorio. La Peticin de Comparar es definida como se indica a continuacin: CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } Los parmetros de la Peticin de Comparar son:

Yeong, Hows & Kille

[Pgina 14]

RFC 1777

LDAP

Marzo 1995

- entry: el nombre de la entrada para ser comparada. - ava: la afirmacin con la cual, la entrada ser comparada. El resultado del intento de comparacin por el servidor al recibir una Peticin de Comparar se devolver en la Respuesta de Comparar, definido como sigue: CompareResponse ::= [APPLICATION 15] LDAPResult Al recibir una Peticin de Comparar, un servidor intentar ejecutar la comparacin pedida. El resultado de la comparacin ser devuelto al cliente en la Respuesta de Comparar. Note que todos los errores y el resultado de la comparacin se devolvern en la misma construccin. 6.9. Operacin Abandonar La funcin de la Operacin Abandonar es para permitir a un cliente pedir que el servidor abandone una operacin pendiente. La Peticin Abandonar se define como se indica a continuacin: AbandonRequest ::= [APPLICATION 16] MessageID No hay respuesta definida en la Operacin Abandonar. Sobre la transmisin de una Operacin Abandonar, un cliente puede esperar que la operacin identificada por el ID del Mensaje en la Peticin de Abandonar ha sido dejada. En el caso de que un servidor recibe una Peticin de Abandono sobre una Operacin de Bsqueda en medio de transmitir respuestas que debe buscar, ese servidor debera cesar transmitir respuestas y abandonar la bsqueda inmediatamente. 5. Codificacin del Elemento Protocolar Los elementos protocolares de LDAP son codificados para el cambio usando las Reglas Bsicas de Codificacin (BER) [12] de ASN.1 [11]. Sin embargo, debido al alto costo implicado en usar elementos seguros del BER, las restricciones adicionales siguientes se ponen sobre codificaciones BER de los elementos protocolares LDAP: (1) Solo se usar la forma definitiva de longitud codificada. (2) Las cadenas de Bits y cadenas de octetos y todos los tipos de cadena de caracteres se codificarn solo en la forma primitiva. 6. Consideraciones de Seguridad Esta versin del protocolo solo provee instalaciones para

Yeong, Hows & Kille

[Pgina 15]

RFC 1777

LDAP

Marzo 1995

identificacin sencilla que usa una contrasea de texto, y para autenticacin kerberos versin 4. Las futuras versiones de LDAP probablemente incluirn apoyo para otros mtodos de autenticacin. 7. Bibliografa [1] The Directory: Overview of Concepts, Models and Service. CCITT Recommendation X.500, 1988. [2] Information Processing Systems -- Open Systems Interconnection -The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC 1/SC21; International Standard 9594-1, 1988 [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance Systems International, Inc., February 1991. [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol Specification, RFC 1249, University of Michigan, August 1991. [5] Kille, S., "A String Representation of Distinguished Names", RFC 1779, ISODE Consortium, March 1995. [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight Directory Access Protocol", RFC 1488, University of Michigan, ISODE Consortium, Performance Systems International, NeXor Ltd., July 1993. [7] Kerberos Authentication and Authorization System. S.P. Miller, B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena Documentation Section E.2.1, December 1987. [8] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC 1/SC21; International Standard 9594-2, 1988. [10] The Directory: Abstract Service Definition. CCITT Recommendation X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988. [11] Specification of Abstract Syntax Notation One (ASN.1). CCITT Recommendation X.208, 1988. [12] Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). CCITT Recommendation X.209, 1988. 10. Las Direcciones de los Autores Wengyik Yeong PSI Inc.

Yeong, Hows & Kille

[Pgina 16]

RFC 1777 510 Huntmar Park Drive Herndon, VA 22070 USA Phone: +1 703-450-8001 EMail: yeongw@psilink.com Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA Phone: +1 313 747-4454 EMail: tim@umich.edu Steve Kille ISODE Consortium PO Box 505 London SW11 1DX UK Phone: +44-71-223-4062 EMail: S.Kille@isode.com

LDAP

Marzo 1995

Traduccin: H.T.A. Software http://www.lanzadera.com/trueno/ Apndice A - Definicin Completa ASN.1 Protocolo Ligero de Acceso a Directorio ETIQUETAS IMPLICITAS DE DEFINICIONES ::= BEGIN LDAPMessage ::= SEQUENCE { messageID MessageID, -- identificador nico de peticin, -- para ser repetido en respuesta(s) protocolOp CHOICE { searchRequest SearchRequest, searchResponse SearchResponse, modifyRequest ModifyRequest,

Yeong, Hows & Kille

[Pgina 17]

RFC 1777 modifyResponse addRequest addResponse delRequest

LDAP

Marzo 1995

ModifyResponse, AddRequest, AddResponse, DelRequest, delResponse DelResponse, modifyDNRequest ModifyDNRequest, modifyDNResponse ModifyDNResponse, compareDNRequest CompareRequest, compareDNResponse CompareResponse, bindRequest BindRequest, bindResponse BindResponse, abandonRequest AbandonRequest, unbindRequest UnbindRequest

} } BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), -- la versin actual es la 2 name LDAPDN, -- un nombre nulo significa una conexin annima authentication CHOICE { simple [0] OCTET STRING, -- un octeto con cadena cero de longui tud -- implica conexin no autenticada -- . krbv42LDAP [1] OCTET STRING, krbv42DSA [2] OCTET STRING -- valores devueltos por -- krb_mk_req() -- Otros valores en versiones posterio res -- de este protocolo. } } BindResponse ::= [APPLICATION 1] LDAPResult UnbindRequest ::= [APPLICATION 2] NULL SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject singleLevel wholeSubtree },

(0), (1), (2)

Yeong, Hows & Kille

[Pgina 18]

RFC 1777 derefAliases

LDAP

Marzo 1995

sizeLimit timeLimit attrsOnly filter attributes } SearchResponse ::= CHOICE { entry

ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), alwaysDerefAliases (3) }, INTEGER (0 .. maxInt), -- valor 0 implica que no tiene lmite de tamao INTEGER (0 .. maxInt), -- valor 0 implica que no tiene lmite de tiempo BOOLEAN, -- TRUE, si solo los atributos (sin valores) -- se devolvern. Filter, SEQUENCE OF AttributeType

resultCode }

[APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes SEQUENCE OF SEQUENCE { AttributeType, SET OF AttributeValue } }, [APPLICATION 5] LDAPResult

ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modifications SEQUENCE OF SEQUENCE { operation ENUMERATED add delete replace }, modification SEQUENCE { type values } } }

{ (0), (1), (2) AttributeType, SET OF AttributeValue

Yeong, Hows & Kille

[Pgina 19]

RFC 1777

LDAP

Marzo 1995

ModifyResponse ::= [APPLICATION 7] LDAPResult AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attrs SEQUENCE OF SEQUENCE { type AttributeType, values SET OF AttributeValue } } AddResponse ::= [APPLICATION 9] LDAPResult DelRequest ::= [APPLICATION 10] LDAPDN DelResponse ::= [APPLICATION 11] LDAPResult ModifyRDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN -- old RDN always deleted } ModifyRDNResponse ::= [APPLICATION 13] LDAPResult CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } CompareResponse ::= [APPLICATION 15] LDAPResult AbandonRequest ::= [APPLICATION 16] MessageID MessageID ::= INTEGER (0 .. maxInt) LDAPDN ::= LDAPString RelativeLDAPDN ::= LDAPString Filter ::= CHOICE { and or not equalityMatch substrings

[0] [1] [2] [3] [4]

SET OF Filter, SET OF Filter, Filter, AttributeValueAssertion, SubstringFilter,

Yeong, Hows & Kille

[Pgina 20]

RFC 1777 greaterOrEqual lessOrEqual present approxMatch } LDAPResult ::= SEQUENCE { resultCode [5] [6] [7] [8]

LDAP AttributeValueAssertion, AttributeValueAssertion, AttributeType, AttributeValueAssertion

Marzo 1995

ENUMERATED { success operationsError protocolError timeLimitExceeded sizeLimitExceeded compareFalse compareTrue authMethodNotSupported strongAuthRequired noSuchAttribute undefinedAttributeType inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax noSuchObject aliasProblem invalidDNSyntax isLeaf aliasDereferencingProblem inappropriateAuthentication invalidCredentials insufficientAccessRights busy unavailable unwillingToPerform loopDetect namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists objectClassModsProhibited other }, matchedDN LDAPDN, errorMessage LDAPString

(0), (1), (2), (3), (4), (5), (6), (7), (8), (16), (17), (18), (19), (20), (21), (32), (33), (34), (35), (36), (48), (49), (50), (51), (52), (53), (54), (64), (65), (66), (67), (68), (69), (80)

Yeong, Hows & Kille

[Pgina 21]

RFC 1777

LDAP

Marzo 1995

AttributeType ::= LDAPString -- nombre de texto del atributo, o OID -- representacin punteada AttributeValue ::= OCTET STRING AttributeValueAssertion ::= SEQUENCE { attributeType AttributeType, attributeValue AttributeValue } SubstringFilter ::= SEQUENCE { type AttributeType, SEQUENCE OF CHOICE { initial [0] LDAPString, any [1] LDAPString, final [2] LDAPString } } LDAPString ::= OCTET STRING maxInt INTEGER ::= 65535 END

Yeong, Hows & Kille

[Pgina 22]