Content deleted Content added
m format RFCs |
|||
Line 1:
{{short description|Network protocol supporting distributed directory information services}}
{{Infobox networking protocol
| is stack = no
| purpose = [[Directory service]]
| based on = [[X.500]]
| ports = 389 (ldap), 636 (ldaps)
| rfcs = {{IETF RFC|4510|4511|plainlink=yes}}
}}
{{IPstack}}
The '''Lightweight Directory Access Protocol''' ('''LDAP''' {{IPAc-en|ˈ|ɛ|l|d|æ|p}}) is an open, vendor-neutral, industry standard [[application protocol]] for accessing and maintaining distributed [[Directory service|directory information services]] over an [[Internet Protocol]] (IP) network.<ref>{{cite web|url=https://tools.ietf.org/rfc/rfc4511.txt |title=Network Working Group RFC 4511 |publisher=IETF.org |date=2006-06-01|access-date=2014-04-04}}</ref> [[Directory service]]s play an important role in developing [[intranet]] and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network.<ref>{{cite web |url=https://docs.oracle.com/cd/A87860_01/doc/ois.817/a83729/adois09.htm |title=Directory Services LDAP |publisher=Oracle.com |access-date=2014-04-04}}</ref> As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate [[email]] directory. Similarly, a [[telephone directory]] is a list of subscribers with an address and a phone number.
LDAP is specified in a series of [[Internet Engineering Task Force]] (IETF) Standard Track publications known as [[Request for Comments]] (RFCs), using the description language [[ASN.1]]. The latest specification is Version 3, published as [https://datatracker.ietf.org/doc/html/rfc4511 RFC 4511]<ref name="gracion">[http://www.gracion.com/server/whatldap.html What is LDAP?]. Gracion.com. Retrieved on 2013-07-17.</ref> (a road map to the technical specifications is provided by [https://tools.ietf.org/html/rfc4510 RFC4510]).
A common use of LDAP is to provide a central place to store usernames and passwords. This allows many different applications and services to connect to the LDAP server to validate users.<ref>{{cite web|title=Introduction to OpenLDAP Directory Services|url=http://www.openldap.org/doc/admin24/intro.html|website=OpenLDAP|access-date=1 February 2016}}</ref>
LDAP is a simpler ("lightweight") subset of the standards in the [[X.500|X.500 series]], particularly the X.511 [[Directory Access Protocol]].{{ref RFC|4511|quote=The core protocol operations defined in this document can be mapped to a subset of the X.500 (1993) Directory Abstract Service [X.511]. However, there is not a one-to-one mapping between LDAP operations and X.500 Directory Access Protocol (DAP) operations.}}<ref>{{cite web |url=https://www.redhat.com/en/topics/security/what-is-ldap-authentication |title=What is lightweight directory access protocol (LDAP) authentication? |publisher=[[Red Hat]] |date=3 June 2022}}</ref> Because of this relationship, LDAP is sometimes called ''X.500 Lite''.<ref>{{cite web|url=http://www.webopedia.com/TERM/L/LDAP.html |title=LDAP - Lightweight Directory Access Protocol |date=4 December 1996 |publisher=Webopedia.com |access-date=2014-04-05}}</ref>
==History==
Telecommunication companies' understanding of directory requirements were well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to [[information technology]] and [[computer networking]], their input culminating in the comprehensive [[X.500]] specification,<ref>The [[X.500]] series - ITU-T Rec. X.500 to X.521</ref> a suite of protocols produced by the [[International Telecommunication Union]] (ITU) in the 1980s.
X.500 directory services were traditionally accessed via the X.511 Directory Access Protocol (DAP), which required the [[Open Systems Interconnection]] (OSI) [[OSI protocols|protocol stack]]. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) [[TCP/IP]] protocol stack. This model of directory access was borrowed from the [[DIXIE]] and [[Directory Assistance Service]] protocols.
The protocol was originally created<ref>{{cite web |last=Howes |first=Tim |url=http://www.openldap.org/pub/umich/ldap.pdf |title=The Lightweight Directory Access Protocol: X.500 Lite |access-date=26 December 2012}}</ref> by [[Tim Howes]] of the [[University of Michigan]], [[Steve Kille]] of Isode Limited, [[Colin Robbins (software engineer)|Colin Robbins]] of [[Nexor]] and [[Wengyik Yeong]] of [[Performance Systems International]], circa 1993, as a successor<ref>{{cite web|title=Pre-History of LDAP|url=http://cybermatters.info/2013/04/09/prehistory-of-ldap/|website=Cyber Matters|access-date=5 October 2014|date=2013-04-09}}</ref> to [[DIXIE]] and [[Directory Assistance Service|DAS]]. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the [[Internet Engineering Task Force]] (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the [[Simple Authentication and Security Layer]], and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the [[IETF]].
In the early engineering stages of LDAP, it was known as ''Lightweight Directory Browsing Protocol'', or ''LDBP''. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its ''Lightweight'' name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the Internet due to its relatively modest bandwidth usage.
LDAP has influenced subsequent Internet protocols, including later versions of X.500, [[XML Enabled Directory]] (XED), [[Directory Service Markup Language]] (DSML), [[Service Provisioning Markup Language]] (SPML), and the [[Service Location Protocol]] (SLP). It is also used as the basis for [[Microsoft]]'s [[Active Directory]].
==Protocol overview==
A client starts an LDAP session by connecting to an LDAP server, called a [[Directory System Agent]] (DSA), by default on [[Transmission Control Protocol|TCP]] and [[
The client may request the following operations:
* [[StartTLS]] – use the LDAPv3 [[Transport Layer Security]] (TLS) extension for a secure connection
* Bind – [[authenticate]] and specify LDAP protocol version
* Search – search for and/or retrieve directory entries
* Compare – test if a named entry contains a given attribute value
* Add a new entry
* Delete an entry
* Modify an entry
* Modify Distinguished Name (DN)
* Abandon
* Extended Operation
* Unbind
In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before the connection is timed out.
A common alternative method of securing LDAP communication is using an [[Secure Sockets Layer|SSL]] [[tunneling protocol|tunnel]]. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003.<ref>[http://tools.ietf.org/html/rfc3494 RFC3494]</ref>
==Directory structure==
The protocol
* An entry consists of a set of attributes.
* An attribute has a name (an ''attribute type'' or ''attribute description'') and one or more values. The attributes are defined in a ''schema'' (see below).
* Each entry has a unique identifier: its ''Distinguished Name'' (DN). This consists of its ''Relative Distinguished Name'' (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as the [[full path|full file path]] and the RDN as its relative filename in its parent folder (e.g. if <code>/foo/bar/myfile.txt</code> were the DN, then <code>myfile.txt</code> would be the RDN).
A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a [[UUID]] might be provided in the set of the entry's ''operational attributes''.
An entry can look like this when represented in [[LDAP Data Interchange Format]] (LDIF), a plain text format (as opposed a [[binary protocol]] such as LDAP itself):
<syntaxhighlight lang="ldif">
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
</syntaxhighlight>
"<code>dn</code>" is the distinguished name of the entry; it is neither an attribute nor a part of the entry. "<code>cn=John Doe</code>" is the entry's RDN (Relative Distinguished Name), and "<code>dc=example,dc=com</code>" is the DN of the parent entry, where "<code>dc</code>" denotes '[[Domain Name System|Domain Component]]'. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "<code>cn</code>" for common name, "<code>dc</code>" for ___domain component, "<code>mail</code>" for email address, and "<code>sn</code>" for surname.<ref>{{FOLDOC|Lightweight+Directory+Access+Protocol}}</ref>
A server holds a subtree starting from a specific entry, e.g. "<code>dc=example,dc=com</code>" and its children. Servers may also hold references to other servers, so an attempt to access "<code>ou=department,dc=example,dc=com</code>" could return a ''referral'' or ''continuation reference'' to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support ''chaining'', which means the server contacts the other server and returns the results to the client.
LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions - an entry is defined as a [[set (computer science)|set]] of attributes, and an attribute is a set of values, and sets need not be ordered.
==Operations==
===Add===
The ADD operation inserts a new entry into the directory-server database.<ref>[http://tools.ietf.org/html/rfc4511#section-4.7 Add section of RFC4511]</ref> If the distinguished name in the add request already exists in the directory, then the server will not add a duplicate entry but will set the result code in the add result to decimal 68, "entryAlreadyExists".<ref>[http://tools.ietf.org/html/rfc4511#appendix-A LDAP result codes]</ref>
* LDAP-compliant servers will never dereference the distinguished name transmitted in the add request when attempting to locate the entry, that is, distinguished names are never de-aliased.
* LDAP-compliant servers will ensure that the distinguished name and all attributes conform to naming standards.
* The entry to be added must not exist, and the immediate superior must exist.
<syntaxhighlight lang="ldif">
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
</syntaxhighlight>
In the above example, <code>uid=user,ou=people,dc=example,dc=com</code> must not exist, and <code>ou=people,dc=example,dc=com</code> must exist.
===Bind (authenticate)===
When an LDAP session is created, that is, when an LDAP client connects to the server, the '''authentication state''' of the session
is set to anonymous. The BIND operation establishes the authentication state for a session.
Simple BIND and SASL PLAIN can send the user's DN and password in [[plaintext]], so the connections utilizing either Simple or SASL PLAIN
should be encrypted using [[Transport Layer Security]] (TLS). The server typically checks the password against the <code>userPassword</code>
attribute in the named entry. Anonymous BIND (with empty DN and password) resets the connection to anonymous state.
[[Simple Authentication and Security Layer|SASL]] (Simple Authentication and Security Layer) BIND provides authentication services through a
wide range of mechanisms, e.g. [[Kerberos (protocol)|Kerberos]] or the [[client certificate]] sent with TLS.<ref>[https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml SASL Mechanisms at IANA]</ref>
BIND also sets the LDAP protocol version by sending a version number as an integer. If the client requests a version that the server does not support, the server must set the result code in the BIND response to the code for a protocol error. Normally clients should use LDAPv3, which is the
default in the protocol but not always in LDAP libraries.
BIND had to be the first operation in a session in LDAPv2, but is not required as of LDAPv3. In LDAPv3, each
successful BIND request changes the authentication state of the session and each unsuccessful BIND request resets the authentication state of the session.
===Delete===
To delete an entry, an LDAP client transmits a properly formed delete request to the server.<ref>[http://tools.ietf.org/html/rfc4511#section-4.8 RFC4511: delete request]</ref>
* A delete request must contain the distinguished name of the entry to be deleted
* Request controls may also be attached to the delete request
* Servers do not dereference aliases when processing a delete request
* Only leaf entries (entries with no subordinates) may be deleted by a delete request. Some servers support an operational attribute <code>hasSubordinates</code> whose value indicates whether an entry has any subordinate entries, and some servers support an operational attribute <code>numSubordinates</code><ref>[http://tools.ietf.org/html/draft-boreham-numsubordinates-01 Boreham Draft (numSubordinates)]</ref> indicating the number of entries subordinate to the entry containing the <code>numSubordinates</code> attribute.
* Some servers support the subtree delete request control permitting deletion of the DN and all objects subordinate to the DN, subject to access controls. Delete requests are subject to access controls, that is, whether a connection with a given authentication state will be permitted to delete a given entry is governed by server-specific access control mechanisms.
===Search and
The Search operation is used to both search for and read entries. Its parameters are:
; filter : Criteria to use in selecting elements within scope. For example, the filter <code>(&(objectClass=person)(|(givenName=John)(mail=john*)))</code> will select "persons" (elements of objectClass <code>person</code>) where the matching rules for <code>givenName</code> and <code>mail</code> determine whether the values for those attributes match the filter assertion. Note that a common misconception is that LDAP data is case-sensitive, whereas in fact matching rules and ordering rules determine matching, comparisons, and relative value relationships. If the example filters were required to match the case of the attribute value, an ''extensible match filter'' must be used, for example, <code>(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))</code>
The server returns the matching entries and
The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.
===
The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries.<ref>[http://tools.ietf.org/html/rfc4511#section-4.6 Modify Section of RFC4511]</ref> Attempts to modify entries that do not exist will fail. MODIFY requests are subject to access controls as implemented by the server.
The MODIFY operation requires that the distinguished name (DN) of the entry be specified, and a sequence of changes. Each change in the sequence must be one of:
* add (add a new value, which must not already exist in the attribute)
* delete (delete an existing value)
* replace (replace an existing value with a new value)
[[LDIF]] example of adding a value to an attribute:
<syntaxhighlight lang="ldif">
dn: dc=example,dc=com
changetype: modify
add: cn
cn: the-new-cn-value-to-be-added
-
</syntaxhighlight>
To replace the value of an existing attribute, use the <code>replace</code> keyword. If the attribute is multi-valued, the client must specify the value of the attribute to update.
To delete an attribute from an entry, use the keyword <code>delete</code> and the changetype designator <code>modify</code>. If the attribute is multi-valued, the client must specify the value of the attribute to delete.
There is also a Modify-Increment extension<ref>{{cite IETF|title=LDAP Modify-Increment Extension|rfc=4525|first=K.|last=Zeilenga}}</ref> which allows an incrementable attribute value to be incremented by a specified amount. The following example using LDIF increments <code>employeeNumber</code> by <code>5</code>:
<syntaxhighlight lang="ldif">
dn: uid=user.0,ou=people,dc=example,dc=com
changetype: modify
increment: employeeNumber
employeeNumber: 5
-
</syntaxhighlight>
When LDAP servers are in a replicated topology, LDAP clients should consider using the post-read control to verify updates instead of a search after an update.<ref>{{Cite IETF|title = Lightweight Directory Access Protocol (LDAP) Read Entry Controls|rfc = 4527|publisher = [[IETF]]|last = Zeilenga|first = K.}}</ref> The post-read control is designed so that applications need not issue a search request after an update – it is bad form to retrieve an entry for the sole purpose of checking that an update worked because of the replication [[eventual consistency]] model. An LDAP client should not assume that it connects to the same directory server for each request because architects may have placed load-balancers or LDAP proxies or both between LDAP clients and servers.
===Modify DN===
Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag that indicates whether to delete the value(s) in the entry that match the old RDN. The server may support renaming of entire directory subtrees.
An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the meantime. Servers may implement extensions<ref>[http://tools.ietf.org/html/draft-zeilenga-ldap-txn-15 INTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15.txt]</ref> that support this, though.
===Extended operations===
The Extended Operation is a generic LDAP operation
====StartTLS====
The [[StartTLS]] operation establishes [[Transport Layer Security]] (the descendant of [[Transport Layer Security|SSL]]) on the connection. It can provide data confidentiality (to protect data from being observed by third parties) and/or data integrity protection (which protects the data from tampering). During TLS negotiation the server sends its [[X.509]] certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use [[Simple Authentication and Security Layer|SASL]]/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive its identity from credentials provided at a lower level (such as TLS). Though technically the server may use any identity information established at any lower level, typically the server will use the identity information established by TLS.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in two ways:
1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a StartTLS operation) and
2) the LDAPS connection must be closed upon TLS closure.
Some "LDAPS" client libraries only encrypt communication; they do not check the host name against the name in the supplied certificate.<ref>[http://shibboleth.net/community/advisories/secadv_20120227.txt Shibboleth Security alert 20120227]</ref>
===Abandon===
The Abandon operation requests that the server
===Unbind===
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin
Clients can abort a session by simply closing the connection, but they should use Unbind.<ref>[http://tools.ietf.org/html/rfc4511#section-5.3 Tools.ietf.org]</ref> Unbind
==
An LDAP [[
ldap://host:port/DN?attributes?scope?filter?extensions
Most of the components described below are optional.
* ''host'' is the [[FQDN]] or IP address of the LDAP server to search.
* ''port'' is the [[network port]] (default port 389) of the LDAP server.
* ''DN'' is the distinguished name to use as the search base.
* ''attributes'' is a comma-separated list of attributes to retrieve.
* ''scope'' specifies the search scope and can be "base" (the default), "one" or "sub".
* ''filter'' is a search filter. For example, <code>(objectClass=*)</code> as defined in RFC 4515.
* ''extensions'' are extensions to the LDAP URL format.
For example, "<code>ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com</code>" refers to all user attributes in John Doe's entry in <code>ldap.example.com
There is a similar non-standard <code>ldaps</code> URI scheme for LDAP over SSL. This should not be confused with LDAP with TLS, which is achieved using the StartTLS operation using the standard <code>ldap</code> scheme.
==Schema==
The contents of the entries in a subtree
The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:
* Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
* Matching Rules—Provide information about how to make comparisons against attribute values.
* Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
* Attribute Types—Define an [[object identifier]] (OID) and a set of names that may refer to a given attribute, and associates that attribute with a syntax and set of matching rules.
* Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.
* Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
* Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
* Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
The schema defines ''object classes''. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or ___domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.
For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values that define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a [[Class (computer science)|class]] definition and an [[Instantiation (computer science)|instance]] in [[Object-oriented programming]], representing LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An ''operational attribute'' describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)
Server administrators can
==Security vulnerabilities==
===LDAP injection===
LDAP injection is a [[cyberattack|computer security attack]] similar to [[SQL injection]] that can occur when an application implementing LDAP fails to properly sanitize user input.<ref>{{cite web |url=https://owasp.org/www-community/attacks/LDAP_Injection |publisher=OWASP Foundation |website=[[OWASP]] |title=LDAP Injection Description }}</ref>
As an example, consider an LDAP search query that allows the user to search people by their name, the <code>cn</code> attribute. A malicious user might replace a valid name with the <code>*</code> character, which matches any object with the <code>cn</code> attribute. If the application is vulnerable to this attack, it may display attributes that the searching user is not authorized to see.<ref>{{cite book |url=https://books.google.com/books?id=cTI9EQAAQBAJ&dq=ldap+injection&pg=SA10-PA51 |title=A Beginner's Guide To Web Application Penetration Testing |first=Ali |last=Abdollahi |year=2025 |isbn=9781394295609 |publisher=Wiley }}</ref>
LDAP injection vulnerabilities are mitigated by [[escape sequence|escaping]] variables. Escaping is accomplished with two distinct encoding functions {{mdash}} one for Distinguished Names and one for search strings {{mdash}} because they each allow different special characters. Some web frameworks come with escaping built in.<ref>{{cite report |url=https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html |publisher=OWASP Foundation |title=LDAP Injection Prevention Cheat Sheet }}</ref>
===Man-in-the-middle attacks===
Like other parts of TCP/IP, LDAP was originally created without encryption. This makes it vulnerable to [[man-in-the-middle]] attacks, in which attackers intercept credentials during the bind process. This attack can be mitigated by requiring LDAPS or StartLDAP during every bind involving credentials.<ref>{{cite book |url=https://books.google.com/books?id=j4FiEQAAQBAJ&dq=ldap+man+in+the+middle&pg=PT224 |title=LDAP Architecture and Implementation: Definitive Reference for Developers and Engineers
|first=Richard |last=Johnson |year=2025 |publisher=HiTeX Press }}</ref>
==Variations==
Much of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.
For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. ''Controls'' may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have ''options'' that may modify their semantics.
==
As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed varies. For example, there is software to access [[SQL]] databases through LDAP, even though LDAP does not readily lend itself to this.<ref>[http://www.openldap.org/doc/admin24/backends.html#SQL Openldap.org]</ref> X.500 servers may support LDAP as well.
Similarly, data previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via [[Pluggable Authentication Modules|PAM]] and [[Name Service Switch|NSS]] modules. LDAP is often used by other services for authentication and/or authorization (what actions a given already-authenticated user can do on what service). For example, in Active Directory Kerberos is used in the authentication step, while LDAP is used in the authorization step.
An example of such data model is the GLUE Schema,<ref>[https://www.ogf.org/documents/GFD.218.pdf Open Grid Forum : Project Home<!-- Bot generated title -->]</ref> which is used in a distributed information system based on LDAP that enable users, applications and services to discover which services exist in a Grid infrastructure and further information about their structure and state.
==
An LDAP server may return referrals to other servers for requests that it cannot fulfill itself. This requires a naming structure for LDAP entries so one can find a server holding a given distinguished name (DN), a concept defined in the X.500 Directory and also used in LDAP. Another way of locating LDAP servers for an organization is a DNS [[SRV record|server record]] (SRV).
An organization with the ___domain example.org may use the top level LDAP DN <code>dc=example, dc=org</code> (where ''dc'' means ___domain component). If the LDAP server is also named ldap.example.org, the organization's top level LDAP URL becomes <code>ldap://ldap.example.org/dc=example,dc=org</code>.
Primarily two common styles of naming are used in both X.500 [2008] and LDAPv3. These are documented in the ITU specifications and IETF RFCs. The original form takes the top level object as the country object, such as <code>c=US</code>, <code>c=FR</code>. The ___domain component model uses the model described above. An example of country based naming could be <code>l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR</code>, or in the US: <code>cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US</code>.
==See also==
* [[Ambiguous name resolution]]
* [[CCSO Nameserver]]
* [[Federated Naming Service]]
* [[Hesiod (name service)]]
* [[Hierarchical database model]]
* [[Key server (cryptographic)]]
* [[LDAP Application Program Interface]]
* [[List of LDAP software]]
* [[Simple Authentication and Security Layer]] (SASL)
==References==
{{
===Sources===
* [[Abstract syntax notation one|ITU-T Rec. X.680]], "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994
* [[Basic encoding rules]] (BER) - ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994
* {{IETF RFC|3641|link=no}} - [[Generic String Encoding Rules]] (GSER) for ASN.1 Types
* {{IETF RFC|4346|link=no}} - The [[Transport Layer Security|TLS]] Protocol Version 1.1
* {{IETF RFC|4422|link=no}} - Simple Authentication and Security Layer ([[Simple Authentication and Security Layer|SASL]])
* SASL mechanisms registered at IANA
==
* {{Cite book | last=Arkills | first=B | title=LDAP Directories Explained: An Introduction and Analysis | publisher=[[Addison-Wesley Professional]] | year=2003 | isbn=978-0-201-78792-4 | url=http://www.informit.com/store/ldap-directories-explained-an-introduction-and-analysis-9780201787924 }}
* {{Cite book | last=Carter | first=G | title=LDAP System Administration | publisher=[[O'Reilly Media]] | year=2003 | isbn=978-1-56592-491-8 | url=https://archive.org/details/ldapsystemadmini00cart | url-access=registration }}
* {{Cite book | last=Donley | first=C | title=LDAP Programming, Management, and Integration | publisher=[[Manning Publications]] | year=2002 | isbn=978-1-930110-40-3 }}
* {{Cite book | last1=Howes | first1=T | last2=Smith | first2=M | last3=Good | first3=G | title=Understanding and Deploying LDAP Directory Services | publisher=[[Addison-Wesley Professional]] | year=2003 | isbn=978-0-672-32316-4 | url=http://www.informit.com/store/understanding-and-deploying-ldap-directory-services-9780672323164}}
* {{Cite book | last=Rhoton | first=J | title=Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP | publisher=Elsevier | year=1999 | isbn=978-1-55558-212-8}}
* {{Cite book | last=Voglmaier | first=R | title=The ABCs of LDAP: How to Install, Run, and Administer LDAP Services | publisher=Auerbach Publications | year=2003 | isbn=978-0-8493-1346-2}}
==External links==
*List of public LDAP Servers (2013): {{Cite web|url=https://ldapwiki.com/wiki/Public%20LDAP%20Servers|title=Ldapwiki: Public LDAP Servers|website=ldapwiki.com|access-date=2020-01-18|date=2013}}
{{Open Group standards}}
{{Query languages}}
{{Authority control}}
{{DEFAULTSORT:Ldap}}
[[Category:Application layer protocols]]
[[Category:Directory services]]
[[Category:Internet protocols]]
[[Category:Internet
[[Category:
| |||