X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=doc%2Fdrafts%2Fdraft-ietf-ldapext-locate-xx.txt;h=88d6cd2b019141f32e5170c247478059aba634b9;hb=d650b1a446c7c7cfb5e50d2dca3e83092114f18c;hp=40f438d514530a3ff0431c2e6c0fc189e493c644;hpb=1d03f5dbac5e716c25c5e4809fb763c0ab5d9180;p=openldap diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt index 40f438d514..88d6cd2b01 100644 --- a/doc/drafts/draft-ietf-ldapext-locate-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt @@ -1,7 +1,9 @@ INTERNET-DRAFT Michael P. Armijo - Levon Esibov -January, 2000 Paul Leach -Expires: July, 2000 Microsoft Corporation + Levon Esibov +August, 2000 Paul Leach +Expires: February, 2001 Microsoft Corporation + R.L. Morgan + University of Washington Discovering LDAP Services with DNS @@ -27,124 +29,178 @@ Status of this Memo http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. It is filed as , and expires on July 4, 2000. + ietf-ldapext-locate-04.txt>, and expires on February 25, 2001. Please send comments to the authors. + 1. Abstract - This draft defines a way that native Internet LDAP servers can make - use of the DNS's knowledge base to provide clients a method to - resolve LDAP services for a given domain. + A Lightweight Directory Access Protocol (LDAP) request must be + directed to an appropriate server for processing. This document + specifies a method for discovering such servers using information in + the Domain Name System. 2. Introduction - The LDAPv3 protocol [1] is designed to be a lightweight access - protocol for directory services supporting X.500 models. This may - be the X.500 directory itself, but the LDAP specification - explicitly allows it to be a different directory. Let us define - a "native LDAP server" to be one that is not a front end to the - X.500 directory service. Let us further define an "Internet based - organization" as one that has a domain name, and an "Internet LDAP - server" to be one containing a directory entries for such an - organization. - - This draft defines a way that native Internet LDAP servers can make - use of the DNS's knowledge base to perform the same function, while - still supporting integration with the X.500 directory. - - This draft builds on RFC 2247[2] to define a mechanism by which - collections of native Internet LDAP servers can be integrated to - create a directory service. That work supports this cause by - defining a mapping from an LDAP DN to a DNS name that can be - resolved to the address of a server holding the entry corresponding - to the DN. For example, the DN "CN=Fred,OU=Eng,DC=example,DC=net" - maps to the DNS name "example.net". - - In an Internet context, many of the names about which users seek - information are DNS names, or include DNS names. A native LDAP based - directory service for the Internet should make it convenient to - process such names -- there is a huge social investment spanning two - decades to get to the point where names like - "john.doe@somewhere.example" and "http://www.example.net" can - appear in newspaper articles, TV commercials, and on billboards - and millions of people understand what to do with them. As a result, - we assume that Internet based organizations wish to preserve this - investment, yet also want to deploy directory services. - - Widespread use of, and dependence on, LDAP services will require that - they are robust and scalable. Both of these features are typically - supported by replicated servers. Use of SRV records to locate LDAP - servers supports clients' use of replicated servers. - - -3. Locating LDAP servers through DNS - - LDAP server location information is to be stored using DNS Service - Location Record (SRV)[6]. The data in a SRV record contains the DNS - name of the server that provides the LDAP service, corresponding Port - number, and parameters that enable the client to choose an - appropriate server from multiple servers according to the algorithm - described in the SRV protocol[6]. The name of this record always has - the following format: - - _._. - - where is always "ldap", is a protocol that can - be either "udp" or "tcp", and is the domain hosted by the - LDAP Server. Note that "ldap" is the symbolic name for the LDAP - service in Assigned Numbers [7], as required by the SRV Protocol[6]. - - Presence of such records enables clients to find the LDAP servers - using standard DNS query [3]. As an example, a client that searches - for an LDAP server in the example.net domain that supports TCP protocol + The LDAPv3 protocol [1] is designed to be a lightweight access + protocol for directory services supporting X.500 models. As a + distributed directory service, the complete set of directory + information (known as the Directory Information Base) is spread + across many different servers. Hence there is the need to + determine, when initiating or processing a request, which servers + hold the relevant information. In LDAP, the Search, Modify, Add, + Delete, ModifyDN, and Compare operations all specify a Distinguished + Name (DN) [2] on which the operation is performed. A client, or a + server acting on behalf of a client, must be able to determine the + server(s) that hold the naming context containing that DN, since + that server (or one of that set of servers) must receive and process + the request. This determination process is called "server + location". To support dynamic distributed operation, the + information needed to support server location must be available via + lookups done at request processing time, rather than, for example, + as static data configured into each client or server. + + It is possible to maintain the information needed to support server + location in the directory itself, and X.500 directory deployments + typically do so. In practice, however, this only permits location + of servers within a limited X.500-connected set. LDAP-specific + methods of maintaining server location information in the directory + have not yet been standardized. This document defines an + alternative method of managing server location information using the + Domain Name System. This method takes advantage of the global + deployment of the DNS, by allowing LDAP server location information + for any existing DNS domain to be published by creating the records + described below. A full discussion of the benefits and drawbacks of + the various directory location and naming methods is beyond the + scope of this document. + + RFC 2247[3] defines an algorithm for mapping DNS domain names into + DNs. This document defines the inverse mapping, from DNs to DNS + domain names, based on the conventions in [3], for use in this + server location method. The server location method described in + this document is only defined for DNs that can be so mapped, i.e., + those DNs that are based on domain names. In practice this is + reasonable because many objects of interest are named with domain + names, and use of domain-name-based DNs is becoming common. + + +3. Mapping Distinguished Names into Domain Names + + This section defines a method of converting a DN into a DNS domain + name for use in the server location method described below. Some + DNs cannot be converted into a domain name. Converted DNs result + in a fully qualified domain name. + + The output domain name is initially empty. The DN is processed in + right-to-left order (i.e., beginning with the first RDN in the + sequence of RDNs). An RDN is able to be converted if it (1) + consists of a single AttributeTypeAndValue; (2) the attribute type + is "DC"; and (3) the attribute value is non-null. If it can be + converted, the attribute value is used as a domain name component + (label). The first such value becomes the rightmost (i.e., most + significant) domain name component, and successive converted RDN + values extend to the left. If an RDN cannot be converted, + processing stops. If the output domain name is empty when + processing stops, the DN cannot be converted into a domain name. + + For DN: + + cn=John Doe,ou=accounting,dc=example,dc=net + + The client would convert the DC components as defined above into + DNS name: + + example.net. + + The determined DNS name will be submitted as a DNS query using the + algorithm defined in section 4. + + +4. Locating LDAP servers through DNS + + LDAP server location information is to be stored using DNS Service + Location Record (SRV)[5]. The data in a SRV record contains the DNS + name of the server that provides the LDAP service, corresponding + Port number, and parameters that enable the client to choose an + appropriate server from multiple servers according to the algorithm + described in [5]. The name of this record has the following format: + + _._. + + where is always "ldap", and is a protocol that can + be either "udp" or "tcp". is the domain name formed by + converting the DN of a naming context mastered by the LDAP Server + into a domain name using the algorithm in Section 3. Note that + "ldap" is the symbolic name for the LDAP service in Assigned + Numbers[6], as required by [5]. + + Presence of such records enables clients to find the LDAP servers + using standard DNS query [4]. A client (or server) seeking an LDAP + server for a particular DN converts that DN to a domain name using + the algorithm of Section 3, does a SRV record query using the DNS + name formed as described in the preceding paragraph, and interprets + the response as described in [5] to determine a host (or hosts) to + contact. As an example, a client that searches for an LDAP server + for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol will submit a DNS query for a set of SRV records with owner name: - - _ldap._tcp.example.net. - The client will receive the list of SRV records published in DNS - that satisfy the requested criteria. The following is an example - of such record: + _ldap._tcp.example.net. + + The client will receive the list of SRV records published in DNS + that satisfy the requested criteria. The following is an example of + such a record: - _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net. + _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net. - The set of returned records may contain multiple records in the - case where multiple LDAP servers serve the same domain. + The set of returned records may contain multiple records in the case + where multiple LDAP servers serve the same domain. If there are no + matching SRV records available for the converted DN the client SHOULD + NOT attempt to 'walk the tree' by removing the least significant + portion of the constructed fully qualified domain name. -4. Security Considerations +5. Security Considerations + + DNS responses can typically be easily spoofed. Clients using this + location method SHOULD ensure, via use of strong security + mechanisms, that the LDAP server they contact is the one they + intended to contact. See [7] for more information on security + threats and security mechanisms. This document describes a method that uses DNS SRV records to discover LDAP servers. All security considerations related to DNS SRV records are inherited by this document. See the security - considerations section in [6] for more details. + considerations section in [5] for more details. + +6. References -5. References + [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol(v3)", RFC 2251, December 1997. - [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol(v3)". RFC 2251, December 1997. + [2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. - [2] S. Kille, M. Wahl, "Using Domains in LDAP/X.500 Distinguished - Names". RFC 2247, January 1998. + [3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500 + Distinguished Names", RFC 2247, January 1998. - [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES, - November, 1987. - - [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND - SPECIFICATION, November, 1987. + [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC + 1034, STD 13, November 1987. - [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255 December 1997. + [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. - [6] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the - location of services (DNS SRV)". - http://www.ietf.org/internet-drafts/draft-ietf- - dnsind-rfc2052bis-05.txt, November 1999. + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. - [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994 + [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R., + "Authentication Methods for LDAP", RFC 2829, May 2000. -6. Authors' Addresses +7. Authors' Addresses Michael P. Armijo One Microsoft Way @@ -161,5 +217,17 @@ Status of this Memo Redmond, WA 98052 levone@microsoft.com - Expires July, 2000 + RL "Bob" Morgan + University of Washington + 4545 15th Ave NE + Seattle, WA 98105 + US + + Phone: +1 206 221 3307 + EMail: rlmorgan@washington.edu + URI: http://staff.washington.edu/rlmorgan/ + + Expires February 25, 2001 + +