GetWiki
Lightweight Directory Access Protocol
ARTICLE SUBJECTS
being →
database →
ethics →
fiction →
history →
internet →
language →
linux →
logic →
method →
news →
policy →
purpose →
religion →
science →
software →
truth →
unix →
wiki →
ARTICLE TYPES
essay →
feed →
help →
system →
wiki →
ARTICLE ORIGINS
critical →
forked →
imported →
original →
Lightweight Directory Access Protocol
please note:
- the content below is remote from Wikipedia
- it has been imported raw for GetWiki
{{short description|Network protocol supporting distributed directory information services}}- the content below is remote from Wikipedia
- it has been imported raw for GetWiki
factoids | |
---|---|
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,The X.500 series - ITU-T Rec. X.500 to X.521 a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s.X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) 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 createdWEB, Howes, Tim,weblink The Lightweight Directory Access Protocol: X.500 Lite, 26 December 2012, by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of Performance Systems International, circa 1993, as a successorWEB, Pre-History of LDAP,weblink Cyber Matters, 5 October 2014, 2013-04-09, to DIXIE and 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 TCP and UDP port 389, or on port 636 for LDAPS (LDAP over TLS/SSL, see below).WEB,weblink Service Name and Transport Protocol Port Number Registry, Internet Assigned Numbers Authority, IANA, 24 March 2021, The client then sends an operation request to the server, and a server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER).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) â move or rename an entry
- Abandon â abort a previous request
- Extended Operation â generic operation used to define other operations
- Unbind â close the connection (not the inverse of Bind)
Directory structure
The protocol provides an interface with directories that follow the 1993 edition of the X.500 model:- 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 file path and the RDN as its relative filename in its parent folder (e.g. if /foo/bar/myfile.txt were the DN, then myfile.txt would be the RDN).
Operations
Add
The ADD operation inserts a new entry into the directory-server database.Add section of RFC4511 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".LDAP result codes- 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.
Bind (authenticate)
When an LDAP session is created, that is, when an LDAP client connects to the server, the authentication state of the sessionis 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 PLAINshould be encrypted using Transport Layer Security (TLS). The server typically checks the password against the userPasswordattribute in the named entry. Anonymous BIND (with empty DN and password) resets the connection to anonymous state.SASL (Simple Authentication and Security Layer) BIND provides authentication services through awide range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.SASL Mechanisms at IANABIND also sets the LDAP protocol version by sending a version number in the form of 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 thedefault 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, eachsuccessful BIND request changes the authentication state of the session and each unsuccessful BIND request resets the authentication stateof the session.Delete
To delete an entry, an LDAP client transmits a properly formed delete request to the server.RFC4511: delete request- 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 hasSubordinates whose value indicates whether an entry has any subordinate entries, and some servers support an operational attribute numSubordinatesBoreham Draft (numSubordinates) indicating the number of entries subordinate to the entry containing the numSubordinates 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 compare
The Search operation is used to both search for and read entries. Its parameters are:- baseObject : The name of the base object entry (or possibly the root) relative to which the search is to be performed.
- scope : What elements below the baseObject to search. This can be BaseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).
- filter : Criteria to use in selecting elements within scope. For example, the filter (&(objectClass=person)(|(givenName=John)(mail=john*))) will select "persons" (elements of objectClass person) where the matching rules for givenName and mail 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, (&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))
- derefAliases : Whether and how to follow alias entries (entries that refer to other entries),
- attributes : Which attributes to return in result entries.
- sizeLimit, timeLimit : Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit.
- typesOnly : Return attribute types only, not attribute values.
- scope : What elements below the baseObject to search. This can be BaseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).
Modify
The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries.Modify Section of RFC4511 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)
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 extensionsINTERNET-DRAFT LDAP Transactions draft-zeilenga-ldap-txn-15.txt that support this, though.Extended operations
The Extended Operation is a generic LDAP operation that can define new operations that were not part of the original protocol specification. StartTLS is one of the most significant extensions. Other examples include Cancel and Password Modify.{{cn|date=January 2024}}StartTLS
The StartTLS operation establishes Transport Layer Security (the descendant of 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 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) and2) 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.Shibboleth Security alert 20120227Abandon
The Abandon operation requests that the server abort an operation named by a message ID. The server need not honor the request. Neither Abandon nor a successfully abandoned operation send a response. A similar Cancel extended operation does send responses, but not all implementations support this.Unbind
The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin, and is not the opposite of the Bind operation.Tools.ietf.orgClients can abort a session by simply closing the connection, but they should use Unbind.Tools.ietf.org Unbind allows the server to gracefully close the connection and free resources that it would otherwise keep for some time until discovering the client had abandoned the connection. It also instructs the server to cancel operations that can be canceled, and to not send responses for operations that cannot be canceled.Tools.ietf.orgURI scheme
An LDAP uniform resource identifier (URI) scheme exists, which clients support in varying degrees, and servers return in referrals and continuation references (see RFC 4516):
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, (objectClass=) as defined in RFC 4515.
- extensions are extensions to the LDAP URL format.
Schema
The contents of the entries in a subtree are governed by a directory schema, a set of definitions and constraints concerning the structure of the directory information tree (DIT).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.
Variations
A lot 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 has been work on it and 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.Other data models
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.Openldap.org 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 PAM and 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,Open Grid Forum : Project Home 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.Usage
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 server record (SRV).An organization with the domain example.org may use the top level LDAP DN dc=example, dc=org (where dc means domain component). If the LDAP server is also named ldap.example.org, the organization's top level LDAP URL becomes ldap://ldap.example.org/dc=example,dc=org.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 c=US, c=FR. The domain component model uses the model described above. An example of country based naming could be l=Locality, ou=Some Organizational Unit, o=Some Organization, c=FR, or in the US: cn=Common Name, l=Locality, ou=Some Organizational Unit, o=Some Organization, st=CA, c=US.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
{{Reflist}}Sources
- 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 TLS Protocol Version 1.1
- {{IETF RFC|4422|link=no}} - Simple Authentication and Security Layer (SASL)
- SASL mechanisms registered at IANA
Further reading
- BOOK, Arkills, B, LDAP Directories Explained: An Introduction and Analysis, Addison-Wesley Professional, 2003, 978-0-201-78792-4,weblink
- BOOK, Carter, G, LDAP System Administration, O'Reilly Media, 2003, 978-1-56592-491-8,weblink registration,
- BOOK, Donley, C, LDAP Programming, Management, and Integration, Manning Publications, 2002, 978-1-930110-40-3,
- BOOK, Howes, T, Smith, M, Good, G, Understanding and Deploying LDAP Directory Services, Addison-Wesley Professional, 2003, 978-0-672-32316-4,weblink
- BOOK, Rhoton, J, Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP, Elsevier, 1999, 978-1-55558-212-8,
- BOOK, Voglmaier, R, The ABCs of LDAP: How to Install, Run, and Administer LDAP Services, Auerbach Publications, 2003, 978-0-8493-1346-2,
External links
- List of public LDAP Servers (2013): WEB,weblink Ldapwiki: Public LDAP Servers, ldapwiki.com, 2020-01-18, 2013,
- content above as imported from Wikipedia
- "Lightweight Directory Access Protocol" does not exist on GetWiki (yet)
- time: 7:32am EDT - Sat, May 18 2024
- "Lightweight Directory Access Protocol" does not exist on GetWiki (yet)
- time: 7:32am EDT - Sat, May 18 2024
[ this remote article is provided by Wikipedia ]
LATEST EDITS [ see all ]
GETWIKI 23 MAY 2022
The Illusion of Choice
Culture
Culture
GETWIKI 09 JUL 2019
Eastern Philosophy
History of Philosophy
History of Philosophy
GETWIKI 09 MAY 2016
GetMeta:About
GetWiki
GetWiki
GETWIKI 18 OCT 2015
M.R.M. Parrott
Biographies
Biographies
GETWIKI 20 AUG 2014
GetMeta:News
GetWiki
GetWiki
© 2024 M.R.M. PARROTT | ALL RIGHTS RESERVED