Basic concepts of LDAP

Lightweight Directory Access Protocol is a client/server X.500 Directory Service Access Protocol Based on the computing model. LDAP is developed based on the X.500 Directory Access Protocol, which simplifies X.500. The main difference between LDAP and X.500 is:

1. LDAP is based on TCP/IP, while X.500 is based on OSI network protocol stack. OSI has few real applications.
2. LDAP deletes some of the complex and uncommon functions in X.500.
3. LDAP uses a more concise string to represent data, rather than the more complex structured syntax ASN1 (Abstract Syntax Notation One)

The general process of interaction between the LDAP client and the LDAP server

1. The LDAP client initiates a connection request to establish a session with the LDAP server. The LDAP term is binding ). When creating a binding, the client usually needs to specify the user to access the directory information on the server.
2. The LDAP client sends out directory query, new, update, delete, move directory entries, and compare directory entries.
3. The LDAP client ends the session with the server, that is, unbinding)

LDAP and RFC documents
The LDAP protocol version is currently 3.0, which is composed of a series of RFC:
Rfc2251 light-weight Directory Access Protocol
It mainly defines LDAP operations and the format of messages exchanged between the client and the server. To better support internationalization, it requires data to be expressed in UTF-8. In addition, the referral function is added to rfc2133 of the earlier version, and the schema itself is stored in the directory so that the client can read the schema information.
Rfc2252 light-weight Directory Access Protocol -- attribute syntax definition

Rfc2253 light-weight Directory Access Protocol -- UTF-8 string representation of distinguished names

Rfc2254 light-weight Directory Access Protocol -- the string representation of LDAP search filters

Rfc2255 light-weight Directory Access Protocol -- the ldap url format

Rfc2256 a summary of X.500 user schema for use with LDAP v3
Some common objectclasses and attributes have been defined by X.500. The RFC summarizes these objectclasses used in LDAP.

LDAP layer-4 Model

1. Information Model describes the LDAP directory structure
2. Naming model describes the unique identification method of directory entries
3. Functional Model describes operations supported by LDAP
4. Security description access control of directory information

Information Model
A directory entry is the most basic unit of information in LDAP. Each directory entry can have more than one attribute. Different from the attributes defined in programming languages and database types, attributes in LDAP allow multiple values. Each attribute belongs to one type. The type specifies the constraints for the values that the attribute can store, and also specifies the rules for comparing data of this type, this is similar to collation of relational databases. In LDAP, the syntax (syntax) is used to set value constraints and comparison rules for table properties. Commonly used LDAP syntax includes:

Bin binary information
CES case sensitive comparison, that is, the so-called Directory string
CIS case insensitive comparison
Tel phone number. The space and minus signs in the string will be removed during comparison.
DN ID
Generalized Time
Postal address

Attributes are globally defined in LDAP. Attribute names are usually abbreviated as follows:
CommonName, cn cis John Smith
Surname, Sn CIS Smith
Telephonenumber Tel 021-34354576
Organizationalunitname, ou CIS it
Owner DN Cn = John Smith, O = sun, c = Cn
Organization, o cis sun
Jpegphoto Bin

On the basis of attributes, LDAP also uses schema to further restrict directory entries. Schema is a type definition mechanism. Each type definition becomes an objectclass, which specifies other constraints such as mandatory and optional attributes of a directory entry instance of this type. Similar to object-oriented programming languages, objectclass supports inheritance, and all objectclasses are top subtypes, because top defines the required attributes of objectclass, therefore, all directory entry instances have the objectclass attribute. The following are common objectclasses:
Inetorgperson, organizationalunit, organization
Extensibleobject allows any attribute.

Naming Model
DN is the name that identifies a directory entry without ambiguity. The dn syntax is as follows:

Distinguishedname = [name]
Name = Name-component * (, name-component)
Name-Component = attributetypeandvalue * ("+" attributetypeandvalue)
Attributetypeandvalue = attributetype "=" attributevalue
Attributetype = (alpha 1 * keychar)/OID
Keychar = alpha/digit /"-"
Oid = 1 * digit * ("." 1 * digit)
Attributevalue = string
...
Therefore, if there are multiple attributes in rdn, connect them with the plus sign "+. For example, Cn = John Smith + L = Shanghai, O = sun, c = cn. In addition, attributes can also be represented by OID. For example, Cn = John Smith is equivalent to 2.5.4.2 = John Smith.
The following lists the meanings of common attribute names (in LDAP, attribute names are case-insensitive ):
Common CN names, often part of DN
L place name, usually the city name
Name of the St state or province
O Organization Name
Ou Organization Unit
Country C
Street street address
DC Domain Name Composition
UID user ID

Suffix is the DN of the top-level node in the directory information tree. an LDAP server can store multiple suffixes.
Referral is a mechanism to connect the directory information subtree distributed on different LDAP servers to a complete logical tree. Create a referral to add an objectclass with the value "referral" to the directory entry, and set the attribute ref to the ldap url of the referenced directory tree. The procedure is as follows:
The LDAP client sends a query request.
The LDAP server finds that the requested directory information is not on the server, but the server saves the reference of this information, the server returns a reference, and uses the ldap url to tell the client the location of the real information source.
After accepting the reference, the LDAP client determines whether to send a request to the real directory information source based on the reference.

Chaining corresponds to referral. The difference between chaining and referral is that referral requires the client to parse the reference, while chaining is done by the server. The general steps of the chaining process are as follows:
The LDAP client sends a query request.
The LDAP server finds that the requested directory information is not on the server, but the server stores the reference information. The server sends a request to the information source to obtain the information and return it to the client.
LDAP client response

Referral is defined in LDAP v3, But chaining is not in the LDAP v3 category.

LDAP v3 specifies that the LDAP server must store its own information under a special DN (also known as root DSE). The main information is:
Server storage suffix
DN for schema Storage
LDAP versions supported by this server
Supported SASL security mechanisms

Functional Model
Functional Model refers to the mechanism for accessing and updating LDAP directory information. There are basically three types of LDAP operations: Query, update, and authentication.
Query is the most complex operation in LDAP. It allows the client to specify the start point of the query, the depth of the query, the conditions to be met for the attributes, and the attributes contained in the finally returned directory entries.
The query start point is specified through base DN. The query depth is three types of baseobjects, singlelevel and wholesubtree. Baseobject only queries the directory entries specified by the base DN; singlelevel only queries the direct subnodes of the base DN; wholesubtree queries all subnodes of the base DN (including the base DN. The conditions that attributes must meet are expressed using search filter. In addition, you can specify the alias resolution (aliase dereferrencing) and query result set size limitation and query time limitation.
The basic search filter syntax is:
Attribute operator Value
The main operators are: =, >=, <=, = *,~ = Where = * Indicates matching the substring ,~ = Approximately equal. In this example, Sn = * indicates all directory entries with Sn values. CN = J * SMI *, Sn ~ = Smit.
Multiple simple filters can use Relational operators to form a composite expression. The basic syntax is:
(& (Filter1) (filter2)... (filtern ))
(| (Filter1) (filter2)... (filtern ))
(! (Filter ))
Example: (| (Sn = miler) (Sn = Smith), (| (Sn = miler) (& (ou = Austin) (Sn = Smith )))

Update operation
LDAP defines the following update operations:
Add create a new directory entry to the directory tree
Delete: delete directory entries. Only leaf nodes can be deleted. Deleting aliases does not affect referenced nodes.
Modify modifies the attributes of a directory entry, including adding or deleting attributes.
Modify DN move directory tree

Authentication operation
LDAP defines the following authentication operations:
Bind this operation is used to establish a session between the LDAP client and the server
Unbind. This operation ends an LDAP session.
Abandon this operation is used to discard the previous operation

Control and extended Operation
Control and extended operation are used to extend the LDAP function without modifying the LDAP protocol itself. Control is used to modify the operation behavior, and extended operation is used to add new operations. Each control consists of the identifier, parameter, and importance. If the importance is true, the server either processes the control or does not support the control. If the importance is false, the servers that cannot support the control can ignore the control. Extended operation consists of identifiers and parameters.

Ldif File Format
The LDAP protocol defines the ldif file format for data exchange between different LDAP products. The character encoding of ldif must be a UTF-8. The basic format of the ldif file is as follows:
[ ]
DN:
Objectclass:
Objectclass:
...
Attributetype [; language tag]: attributevalue
Attributetype [; language tag]: attributevalue
...

In the ldif file, base64 encoding is required for binary data. Base64 encoded data must start with two colons, for example, jpegphoto ::

. The Rows starting with & ldquo # & rdquo are comment rows. The Rows starting with a single space are logically the same as those of the previous row.