The specifications of LDAP v.3 provide facilities for simple authentication using a cleartext password as well as any SASL mechanism.SASL allows for integrity and privacy services to be negotiated (RFC 2251, www.ietf.org/rfc/rfc2251.txt).

Use of cleartext password is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties.

The protocol allows other security mechanisms like SASL to be implemented in LDAP. The protocol also permits that the server can return its credentials to the client, if it chooses to do so.

This article is a TRIZ based study on patents on Lightweight Directory Access Protocol (LDAP) security. The objective of this article is to find the major concerns in LDAP data security, find the IFR and trends of evolution and predict the future inventions on LDAP data security.

This article is a part of the main study made on LDAP based on 60 patents selected from US patent database. (Ref “Inventions on LDAP- A study based on US Patents”, by Umakant Mishra, published in http://www.trizsite.com, July 2006.)

The data model of LDAP is same as X.500 data model. The LDAP protocol assumes there are one or more servers, which jointly provide access to a Directory Information Tree (DIT). The tree is made up of entries. Entries have relative distinguished name (RDN), which must be unique among all its siblings. The concatenation of the relative distinguished names from a particular entry to an immediate subordinate of the root of the tree forms the Distinguished Name (DN) for that entry. (IETF, RFC 2251).

LDAP provides add, delete and modify operations for data modification. Each of these LDAP update operation is atomic. That means the whole operation is processed as a single unit of work. If a modify request is supposed to affect multiple attributes within an entry, it has to either affect all the attributes or none of the attributes.

As LDAP does not specify any specific mechanism for data storage, different venders implement different storage mechanism, which causes incompatibility in certain operations like directory merging or integration.

This article is a TRIZ based study of patents on Lightweight Directory Access Protocol (LDAP) data management. The objective of this article is to find the major concerns in managing LDAP directories, find the IFR and trends of evolution in LDAP data management and predict the future lines of inventions on data management in LDAP directories.

This article is a part of the main study made on LDAP based on 60 patents selected from US patent database. (For more details on the study please refer to the article “Inventions on LDAP- A study based on US Patents”, by Umakant Mishra, published in http://www.trizsite.com, July 2006.)

Lightweight Directory Access Protocol (LDAP) is an IETF open standard to provide directory services in the network. LDAP was initially developed at the University of Michigan with an objective to include most of the features of X.500 directory structure, while eliminating the burdens and difficulties of the same.

The LDAP protocols offer the following basic functional operations, viz., add, delete, modify, bind, unbind, search, compare, modify distinguished name, abandon and extended operations.

The LDAP server stores the directory information in a database. It offers a rich set of searching capabilities and provides the capability for directory information to be queried (or updated). The client makes a TCP/IP connection and sends requests to an LDAP server. The LDAP server executes the search (or update) command and returns a response to the client. LDAP servers use a default port 389 to provide their service.

This article is a TRIZ based study of patents on LDAP administration. This analyzes patents on LDAP administration, finds the trends of evolution and predicts the future lines of inventions on LDAP administration.

This article is a part of the main study made on LDAP based on 60 patents selected from US patent database. (For more details on the study please refer to the article “Inventions on LDAP- A study based on US Patents”, by Umakant Mishra, published in http://www.trizsite.com, July 2006.)

Searching is one of the most basic operation provided by an LDAP server. LDAP offers a rich set of searching capabilities. The search operation allows a client to request the server to perform a search on its behalf. The search operation locates specific users or services in the directory tree. The LDAP server executes the search (or update) command and returns a response to the client.

Upon receipt of a Search Request, a server will perform the necessary search of the DIT. The server will then return to the client a sequence of responses in separate LDAP messages. The search responses may contain SearchResultEntry (the attributes and values satisfying the search conditions), SearchResultReference (URL of the referral servers), ExtendedResponse or SearchResultDone (success or failure of search operation) data types.

Faster searching increases server load and network traffic. An overloaded server and congested network slows down the performance. This makes a loop of contradiction. It is necessary to reduce server load and reduce network traffic while increasing speed of searching.

This article is a TRIZ based study of patents on Lightweight Directory Access Protocol (LDAP) data Searching. Data searching is one of the most important operations of LDAP. The objective of this article is to find the major concerns in LDAP data searching, find the IFR and trends of LDAP data searching and predict the future lines of inventions on LDAP searching.

This article is a part of the main study made on LDAP based on 60 patents selected from US patent database. (For more details on the study please refer to the article “Inventions on LDAP- A study based on US Patents”, by Umakant Mishra, published in http://www.trizsite.com, July 2006.)

LDAP server may store data in a Flat file, in RDBMS or in any other database. The LDAP client applications can use LDAP directory interface without having knowledge on the underlying data storage mechanism. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in LDAP interface.

The individual entries are stored in the directory server. But different clients may need the same data in different format. LDAP specification does not provide any mechanism of accessing data in different format.

This article is a TRIZ based study of patents on LDAP access interface. The article analyses the patents which try to improve various aspects of interfacing an LDAP directory. It tries to find the IFR, Trends of evolution and predict future inventions on data access interface.

This article is a part of the main study made on LDAP based on 60 patents selected from US patent database. (For more details on the study please refer to the article “Inventions on LDAP- A study based on US Patents”, by Umakant Mishra, published in http://www.trizsite.com, July 2006.)