RFC 3088

OpenLDAP Root Service An experimental LDAP referral service

📅 published April 2001, from ietf

OpenLDAP Root Service 🎀

RFC 3088: An experimental LDAP referral service 🦋 Network Working Group Author: K. Zeilenga (OpenLDAP Foundation) 💅 Category: Experimental 🧪 Date: April 2001 📅 This header has no Obsoletes or Updates line, so this doc doesn't replace or update anything. 🙈

Status of this Memo 📜

okay so this memo defines an Experimental Protocol for the Internet community 🧪 It is NOT an Internet standard of any kind, and feedback and suggestions for improvement are literally requested 🫶 Distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 💖

Abstract 🌸

The OpenLDAP Project runs an experimental LDAP (Lightweight Directory Access Protocol) referral service called the "OpenLDAP Root Service" 🦋 An automated system makes referrals from service location info published in DNS SRV RRs (Domain Name System location of services resource records) ✨ This doc explains how the service works 💅

1. Background 🧠

LDAP [RFC2251] directories use a hierarchical naming scheme that was inherited from X.500 [X500] 🌳 Traditionally, X.500 deployments used a geo-political naming scheme, like CN=Jane Doe,OU=Engineering,O=Example,ST=CA,C=US 🗺️ But the registration infrastructure and location services in lots of parts of the naming hierarchy are inadequate or just don't exist 💀

Building a global directory needs a robust registration infrastructure and location service 👑 Using Internet domain-based naming [RFC2247] (for example, UID=jdoe,DC=eng,DC=example,DC=net) lets LDAP directory services piggyback on the existing DNS [RFC1034] registration infrastructure 🎀 And DNS SRV [RFC2782] resource records can be used to find services [LOCATE] 🔥 main character energy for DNS, honestly.

1.1. The Glue 🧷

Most existing LDAP implementations don't support locating directory services with DNS SRV resource records 😭 But most servers do support generating referrals to "superior" server(s) 🌈 This service is a "root" LDAP service that servers can use as their superior referral service 🫶

Clients can also use the service directly to find services associated with an arbitrary Distinguished Name [RFC2253] inside the domain-based hierarchy 🧚

Notice: The mechanisms used by this service are experimental 🧪 The descriptions in this document are not definitive. Definitive mechanisms shall be published in Standard Track document(s). 🚨

2. Generating Referrals based upon DNS SRV RRs 🍓

This service returns referrals that are generated from DNS SRV resource records [RFC2782] ✨

2.1. DN to Domain Name Mapping 🗺️

The service maps a DN [RFC2253] to a fully qualified domain name using the algorithm below 💅

    domain = null;
    foreach RDN left-to-right        // [1]

    {
        if not multi-valued RDN and
            RDN.type == domainComponent
        {
            if ( domain == null || domain == "." )
            {   // start
                domain = "";
            }
            else
            {   // append separator
                domain .= ".";
            }

            if ( RDN.value == "."  )
            {   // root
                domain = ".";
            }
            else
            {   // append domainComponent
                domain .= RDN.value;
            }
            continue;
        }
        domain = null;
    }

Examples 👀

    Distinguished Name              Domain
    -----------------------------   ------------
    DC=example,DC=net               example.net
    UID=jdoe,DC=example,DC=net      example.net
    DC=.                            .            [2]
    DC=example,DC=net,DC=.          .            [3]
    DC=example,DC=.,DC=net          net          [4]
    DC=example.net                  example.net  [5]
    CN=Jane Doe,O=example,C=US      null
    UID=jdoe,DC=example,C=US        null
    DC=example,O=example,DC=net     net
    DC=example+O=example,DC=net     net
    DC=example,C=US+DC=net          null

Notes 📝

  1. A later incarnation will use a Standard Track mechanism. 🎓
  2. A later incarnation of this service may use a right-to-left algorithm. ↩️
  3. RFC 2247 doesn't say how you map the domain that represents the root of the domain tree to a DN 🤷‍♀️ We suggest mapping the root of the domain tree to "DC=." and that this be reversable.
  4. RFC 2247 says that domain "example.net" should map to the DN "DC=example,DC=net", not to "DC=example,DC=net,DC=." 🙅‍♀️ Since it's not our intent to introduce or support an alternative domain-to-DN mapping, the algorithm ignores domainComponents to the left of "DC=.".
  5. RFC 2247 says that domain "example.net" should map to the DN "DC=example,DC=net", not to "DC=example,DC=.,DC=net" 🙄 Same deal: no alternative mappings from us, so the algorithm ignores domainComponents to the left of "DC=." and "DC=." itself if more domainComponents show up on the right.
  6. RFC 2247 says the value of a DC attribute type is a domain component, so it shouldn't contain multiple domain components 🚫 A later incarnation of this service may map this domain to null or be coded to return an invalid DN error.

If the domain is null or ".", the service stops further processing and returns noSuchObject 🛑 A later incarnation of this service may stop processing if the resulting domain is a top-level domain. 🌐

2.2. Locating LDAP services 🔍

The root service finds services for a given fully qualified domain name by asking the Domain Name System for LDAP SRV resource records 🧭 For the domain example.net, the service would issue an SRV query for the domain "_ldap._tcp.example.net" 📨 A successful query returns one or more resource records that look like this:

  _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.

If no LDAP SRV resource records come back, or any DNS error happens, the service stops further processing and returns noSuchObject 😬 Later incarnations of this service will handle transient errors better. 🫠

2.3. Constructing an LDAP Referrals 🧩

For each DNS SRV resource record returned for the domain, an LDAP URL [RFC2255] gets built 🛠️ For the resource record above, the URL would be:

  ldap://ldap.example.net:389/

These URLs are then returned in the referral 💌 Right now the URLs get returned in resolver order, which means the server itself doesn't use the priority or weight info in the SRV resource records ⚖️ A later incarnation of this service may do that. 👀

3. Protocol Operations 🎬

This section explains how the service performs basic LDAP operations 💖 The service supports operations that are extended through certain controls, described in a later section ✨

3.1. Basic Operations 🧱

Basic operations (add, compare, delete, modify, rename, search) return a referral result if the target (or base) DN can be mapped to a set of LDAP URLs as described above 🎯 Otherwise, a noSuchObject response or some other appropriate response is returned. 🙃

3.2. Bind Operation 🔐

The service accepts "anonymous" binds that specify version 2 or version 3 of the protocol 👌 Every other bind request returns a non-successful resultCode 🙅‍♀️ In particular, clients that submit clear text credentials get sent an unwillingToPerform resultCode, along with cautionary text about giving passwords to strangers 🫣 bestie, don't hand your password to random servers.

Because this service is read-only, LDAPv3 authentication [RFC2829] is not supported. 🔒

3.3. Unbind Operations 👋

When an unbind request is received, the server abandons all outstanding requests made by the client and disconnects. 🚪

3.4. Extended Operations ✨

The service currently doesn't recognize any extended operation 🤷‍♀️ Later incarnations of the service may support Start TLS [RFC2830] and other operations. 🔜

3.5. Update Operations ✏️

A later incarnation of this service may return unwillingToPerform for all update operations, since this is an unauthenticated service. 🙈

4. Controls 🎛️

The service supports the ManageDSAit control. Unsupported controls are handled per RFC 2251. 💅

4.1. ManageDSAit Control 🎀

The server recognizes and honors the ManageDSAit control [NAMEDREF] when it's provided with operations 🫶

If DNS location information is available for the base DN itself, the service returns unwillingToPerform for non-search operations 🚫 For search operations, an entry is returned if it's within scope and matches the provided filter. Here's an example:

    c: searchRequest {
        base="DC=example,DC=net"
        scope=base
        filter=(objectClass=*)
        ManageDSAit
    }

    s: searchEntry {
        dn: DC=example,DC=net
        objectClass: referral
        objectClass: extensibleObject
        dc: example
        ref: ldap://ldap.example.net:389/
        associatedDomain: example.net
    }
    s: searchResult {
        success
    }

If DNS location information is available for the DC portion of a subordinate entry, the service returns noSuchObject with the matchedDN set to the DC portion of the base, for search and update operations 🧐

    c: searchRequest {
        base="CN=subordinate,DC=example,DC=net"
        scope=base
        filter=(objectClass=*)
        ManageDSAit
    }

    s: searchResult {
        noSuchObject
        matchedDN="DC=example,DC=net"
    }

5. Using the Service 🌷

Servers may be configured to refer superior requests to <ldap://root.openldap.org:389> 💜

Clients can use the service directly, but that's not encouraged 🙅‍♀️ Clients should use a local service and only use this one when they're referred to it. 🫶

The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over TCP/IPv4 🌐 Future incarnations of this service may support TCP/IPv6 or other transport/internet protocols. 🔮

6. Lessons Learned 📚

6.1. Scaling / Reliability 🏗️

This service currently runs on a single host 🖥️ That host and its associated network resources aren't exhausted yet 💪 If they do get exhausted, the authors believe they can easily scale to meet demand through common distributed load balancing technics. The service can also easily be duplicated locally. 🧬

6.2. Protocol interoperability 🤝

This service has been able to avoid known interoperability issues while supporting variants of LDAP 🥰

6.2.1. LDAPv3 💎

The server implements all features of LDAPv3 [RFC2251] that are necessary to provide the service. ✅

6.2.2. LDAPv2 🕰️

LDAPv2 [RFC1777] doesn't support returning referrals, so it may not be referred to this service 🙅‍♀️ An LDAPv2 client could connect and send requests to this service, but it would treat any referral returned to it as an unknown error. 💀

6.2.3. LDAPv2+ 🧃

LDAPv2+ [LDAPv2+] adds a bunch of extensions to LDAPv2, including referrals ✨ Like LDAPv3, LDAPv2+ doesn't require a bind operation before issuing other operations 🙌 Since the referral representation differs between LDAPv2+ and LDAPv3, the service returns LDAPv3 referrals in this case. Still, commonly deployed LDAPv2+ clients issue bind requests (for compatibility with LDAPv2 servers), so this hasn't caused any interoperability issues (yet). 🤞

A future incarnation of this service may drop support for LDAPv2+ (and LDAPv2). 🔜

6.2.4. CLDAP 🙃

CLDAP [RFC1798] doesn't support returning referrals, so it isn't supported here. 🚫

7. Security Considerations 🔐✨

Okay bestie, this is the section where things get real 😭 The service gives info to "anonymous" clients 🫶, and that info comes from the public directories, aka the Domain Name System 🌸

Authentication would make clients hand info over to the service. That would be an unnecessary invasion of privacy 🙈 so no thanks.

No encryption means anyone can eavesdrop on client requests and responses 💀. A later version may support encryption, like via Start TLS [RFC2830] 🔒

The service doesn't provide information integrity protection 😬 It's exposed to various forms of DNS spoofing and attacks. LDAP session or operation integrity would give a false sense of security about DNS info, and ngl that's a trap 🪤. A later version may support DNSSEC and provide integrity protection (via SASL, TLS, or IPSEC) 🦋

The service is open to a variety of denial of service attacks 🚨 It can block access based on a number of factors, but that capability hasn't been used yet and would likely be ineffective against sophisticated attacks 💅. Later versions will likely need much better protection from these attacks 👑

8. Conclusions 🎀

DNS is good glue 🧚 By leveraging the Domain Name System, global LDAP directories may be built without needing a protocol-specific registration infrastructure.

Also, using DNS service location means global directories can be built "ad hoc" 🌈 Anyone with a domain name can participate. There is no requirement that the superior domain participate.

9. Additional Information 📚

More info about the OpenLDAP Project and the OpenLDAP Root Service is at <http://www.openldap.org/> 🍓

10. Author's Address 💌

Kurt Zeilenga
OpenLDAP Foundation

EMail: kurt@openldap.org

11. Acknowledgments 🫶

Internet hosting for this experiment is provided by the Internet Software Consortium <http://www.isc.org/>. Computing resources came from Net Boolean Incorporated <http://www.boolean.net/>. This experiment would not have been possible without tons of volunteers from the open source community 🌻 The mechanisms described here are based on the ones introduced in [RFC2247] and [LOCATE] ✨

References 📖

  • [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • [RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
  • [RFC1798] Young, A., "Connection-less Lightweight Directory Access Protocol", RFC 1798, June 1995.
  • [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998.
  • [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
  • [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
  • [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
  • [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
  • [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
  • [LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS", Work in Progress.
  • [LDAPv2+] University of Michigan LDAP Team, "Referrals within the LDAPv2 Protocol", August 1996.
  • [NAMEDREF] Zeilenga, K. (editor), "Named Subordinate References in LDAP Directories", Work in Progress.
  • [X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993.

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🌈

📦 where this page comes from