Home > Articles > Networking

Principles of LDAP Schema Design

📄 Contents

  1. Typical Problems with LDAP Schema Design
  2. An Example
  3. Summary
Discover how to design entries and attributes to form a schema and then apply your SQL database normalization skills to reduce redundancy and unwanted data retrieval.
This chapter is from the book

An LDAP accessible Directory may be thought of as an object store. In LDAP terminology, the stored objects are known as entries. The entries are arranged in a hierarchical fashion. Every entry in a Directory has exactly one parent entry and zero or more child entries. Entries with no children are termed leaf entries. All of the children of an entry are siblings and are said to reside in the same container. Each entry stores some set of information. This information is stored as a set of attribute-value pairs. In every entry, at least one of the attribute-value pairs is used to uniquely identify the entry among all of its siblings. For example, in a Directory storing information about people, the email address attribute could be used as the naming attribute. This scheme assumes that everyone in the Directory has an email address. Unfortunately, this is often but not always the case. For example, in a manufacturing division of a company, you typically don't find many employees with email, yet applications need to have information on these employees. Since information is hierarchical, the naming attributes of all of an entry's ancestors up the tree can be strung together to create a unique name for the entry among all entries in the Directory. This unique name is known as the entry's distinguished name (dn for short).

Not only is the LDAP data hierarchical, but the LDAP metadata is hierarchical as well. LDAP metadata is defined by creating object class and attribute type definitions. The entry's object class defines the different attributes that may be stored in an entry. An object class is defined by listing:

  • Name. The string of characters by which the object class is known

  • Mandatory attributes. Attributes that must be present in any entry of the object class

  • Optional attributes. Attributes that may be present in any entry of the object class

  • Superclass. The name of an object class from which this object class inherits all mandatory and optional attributes

  • Type. Indicates whether objects of the type can be created in the Directory (structural) and whether the object class can be used only as a superclass in the creation of other object classes (abstract). The type also indicates whether the object class is used to augment an entry that is already stored in the Directory (auxiliary).

For example, consider the following object class definitions, taken from RFC 2256.2:

( NAME 'top' ABSTRACT MUST objectClass )
( NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY 
( userPassword $ telephoneNumber $ seeAlso $ description ) )

In these definitions, there are two names given for each object class. The numerical object identifier is followed by a textual name. Then the superclass, if any, is given, which is then followed by the object class type. Finally, the mandatory and optional attributes are listed. Note that the "$" character is used as a separator. Notice that entries with the object class "person" inherit the "objectClass" attribute from the superclass. Since the "Top" object class is abstract, then no entries can be created of that class. However, entries that are of the "person" object class may be created. In the "person" object class, the "cn" attribute is short for common name and is normally used to give the entry the unique name within the container.

Attribute types are defined similarly. The most important parts of an attribute type are

  • Name. The string of characters by which the attribute is known

  • Syntax. The definition of the legal values for an attribute (e.g., character string, Boolean, etc.)

  • Number of values allowed. Indicates whether there can be more than one value for the attribute in a single object class

In LDAP, most attributes are multivalued. For example, any entry with the object class "person" would have an attribute type of "objectClass" with two values:

  • "top"

  • "person"

Now, consider the following object class definition, which will be used in the creation of an example Directory tree:

( NAME 'department' SUP top STRUCTURAL MUST departmentName MAY description )

Notice that the numerical name of the object class has been omitted for brevity. Figure 4.1 shows a pictorial view of the information in an example Directory.

Figure 4.1Figure 4.1 Example Directory information.

In the figure, the object class names are given using the oc attribute type. In this example, there are seven entries, with the following dn's, with object class names given in parentheses after the dn:

  • departmentName = uc (department, top)

  • departmentName = cs, departmentName = uc (department, top)

  • departmentName = art, departmentName = uc (department, top)

  • departmentName = cafe, departmentName = uc (department, top)

  • cn = pablo, departmentName = art, departmentName = uc (per-_son, top)

  • cn = henri, departmentName = art, departmentName = uc (person, top)

  • cn = augustus, departmentName = art, departmentName = uc (person, top)

Note that the description attribute in the entry for "cn = pablo" has two distinct values. Information is retrieved from a Directory by using the LDAP Search operation. A Search operation can be used to retrieve attributes from a single entry, from entries in the container immediately below an entry, or from an entire subtree of entries. There are four parameters of interest to the Search operation (there are actually eight parameters, but the others don't affect the normalization discussion):

  • Base object. The starting point for the search. This is a distinguished name.

  • Scope. Indicates whether the search is for single object, container, or subtree

  • Filter. Describes the conditions that must be fulfilled for an entry to be retrieved by the Search operation. The filter either matches or doesn't match an entry.

  • Attributes. Gives the list of attributes that are to be returned from entries that match the filter. If an attribute is listed, then all of the values for that attribute are returned in the Search result. If no attributes are listed, then this is an indication that all attributes in the matching entries are to be returned.

Consider the following example Search operations that are applied to the sample Directory information in Figure 4.1:

  • Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *sculptor"

    • This search would match the one entry: cn = augustus, departmentName = art, departmentName = uc.

  • Base Object = "departmentName = uc," Scope = single level, Filter = "description = *sculptor"

    • This search would not match any entries at all.

  • Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *artist"

    • This search would match the two entries:

      • cn = pablo, departmentName = art, departmentName = uc (person, top),

      • cn = henri, departmentName = art, departmentName = uc (person, top).

  • Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *"

    • This search would match every entry in the example Directory tree.

Typical Problems with LDAP Schema Design

The typical problems that can affiict an LDAP schema design are similar to those that arise in the design of a relational database schema design.1 These problems are

  • Data redundancy
  • Delete anomalies
  • Update anomalies
  • Retrieval of unwanted data

Data redundancy occurs when the same information is repeated in many objects throughout the Directory. Collecting the information in common into a separate entry can often eliminate this data redundancy. Thus, when the common information needs to be changed, it has to be changed only in one entry, not in many entries throughout the Directory.

A delete anomaly occurs when a source object points to a target object and the target object is deleted from the Directory. This can happen frequently in Directories, since many entries have attributes that are the distinguished names of other entries in the Directory.

An update anomaly occurs when the source or target object is modified and the relationship implied by the pointer is no longer valid. Consider the situation in which an entry has an attribute that indicates a user's department number and department administrator. If the user switches departments, both of these attributes must be changed for the entry to remain valid. Similarly, whenever the department changes administrators, the entry for each user in that department must be updated with the new administrator's name.

Retrieval of unwanted data occurs when the LDAP server returns attribute values that are not needed by the LDAP client. This occurs in LDAP because the standard LDAP search operation does not allow for the retrieval of individual attribute values. In LDAP, all of the values of a particular multivalued attribute are returned to the client or none of them are. In the following sections, examples of LDAP schemas with these problems, and suggested solutions to resolve these problems, are presented.

Relational Database Normalization

In relational databases, normalizing the relational tables solves these problems. A relational database is made up of tables. The data types of a table are defined by the column definition. Each row in the table must conform to the definitions of the column. For example, consider a table used to represent suppliers of parts that can be ordered. In its simplest form there might just be a supplier name column and a city name column. Both of these columns are strings. In this case, the supplier name column would be considered a primary key since it uniquely identifies the row. This means that there can't be two rows in the table with the same supplier name.

There are many normalization rules in database theory, but the basic, most widely used are first, second, and third normal forms. These rules are summarized here:

  • First normal form. A table is said to be in first normal form if all of the cells in the table contain only atomic values. This means that sets of value are not allowed in individual cells.

  • Second normal form. A table is said to be in second normal form if every nonkey attribute is fully dependent on the primary key. It must also be in first normal form.

  • Third normal form. A table is said to be in third normal form if all nonkey attributes are dependent only on the primary key. If a nonkey attribute is dependent on an attribute in addition to the primary key attribute, this can lead to the update anomalies mentioned above.

In moving from second normal form to third normal form an additional table (or more) is created. The typical example uses a table to hold user address information. This table would have the following five columns:

  1. User Name (key)
  2. Street Address
  3. City
  4. State
  5. Zip Code

This table is in second normal form since the user name determines columns 2–"5. It is not in third normal form since columns 2–"4 always determine the zip code in column 5. Thus, to move to third normal form, this table must be split into two separate tables, each of which obeys the rules of third normal form above.

These three rules of normalization can be applied to LDAP schema design in order to eliminate some of the common problems. In order to apply the normalization rules to LDAP schema design, simply replace table in the rules with object class, replace primary key with relative distinguished name (RDN), _and replace cell with attribute value. This gives these rules for LDAP Schema Normalization:

  • First normal form. An object class is said to be in first normal form if all of the attribute values in the object class contain only atomic values. This means that sets of values are not allowed in an individual attribute value.

  • Second normal form. An object class is said to be in second normal form if every nonkey attribute is fully dependent on the RDN. It must also be in first normal form.

  • Third normal form. An object class is said to be in third normal form if all nonkey attributes are dependent only on the RDN. If a nonkey attribute is dependent on an attribute in addition to the RDN attribute, this can lead to the update anomalies mentioned above.

Data Redundancy

Consider the following enhanced person object class definition:

( NAME 'enhancedPerson' SUP person STRUCTURAL MUST ( email ) 
MAY ( streetAddress $ city $ state $ postalCode ) )

Using this schema definition, every person in the Directory would have data stored about their mailing address. In organizational directories where virtually all users have common address information, this is a tremendous waste of space and has the potential for inconsistent data. A better solution is to eliminate the redundancy by normalizing2 the postal information into a separate object class.

>( NAME 'enhancedPerson' SUP person STRUCTURAL MUST ( email ) 
MAY postalInformationDN ) ( NAME 'postalInformation' SUP top STRUCTURAL MUST
( cn $ streetAddress $ city $ state $ postalCode ) )

Notice that the person information only stores the name of some other object in the Directory that holds the actual information. The postalInformation object class is specifically designed to hold this information.

Figure 4.2 shows an example Directory with this information.

Figure 4.2Figure 4.2 Eliminating data redundancy.

Retrieval of Unwanted Data

In LDAP, all values of an attribute are returned in a search result if the attribute type name is listed in the attributes field of the search filter. This can be a problem if an entry has numerous values for an attribute and the LDAP client is really only interested in one or two of the values. Consider the scenario of secure email. In typical public-key technology implementation, if one user named Alice wants to send an encrypted message to another user named Bob, Alice must first retrieve Bob's public key.3 When the public-key information is stored in a Directory, it is often stored in a special format, known as a Certificate.4

A typical LDAP schema definition allows Bob's certificate to be stored in his Directory entry using the following object class definition:

( NAME 'strongAuthenticationUser SUP top AUXILIARY MAY _( userCertificate ) )
( NAME 'userCertificate' SYNTAX )

Since the definition of userCertificate doesn't specify the number of values, the attribute can hold any number of values. In certain military and highly secure environments, a single user can hold many hundreds of certificates.5 In this situation, even if the LDAP client wants only to retrieve a single certificate, all of the user's certificates are retrieved and must be examined one at a time in order to find the desired certificate. Not only are all the certificates returned by the LDAP server, they are returned unordered, so the LDAP client may have to examine each certificate in the entry to find the desired certificate. A typical certificate is about 2K bytes. Thus, the LDAP result containing 250 certificates would contain about 500K of data. Thus, in addition to the computational overhead of examining each certificate in order to find the right one, the network overhead would certainly slow down the response time. A better situation is to enhance the schema and revise the DIT. An alternate schema to solve this problem is proposed in a current Internet Draft.6 This schema contains the following object class definition:

( NAME 'certificateType' SUP top STRUCTURAL MUST typeName MAY ( serialNumber $ 
issuer $ validityNotBefore $ validityNotAfter $ subject $ subjectPublicKeyInfo $
certificateExtension $ otherInfo ))

This definition extracts many fields from the certificate data structure in order that they may be easily searchable by standard LDAP search operations. All of the fields except for certificateExtension are defined as SINGLE-VALUE. Notice that it does not include a certificate attribute. This is because the certificate is still attached to the certificateType entry using an auxiliary object class, such as strongAuthenticationUser. This new design for the DIT places all of a user's certificates in a container beneath the user's entry in the DIT rather than directly attached to the entry as in the previous design. Figure 4.3 illustrates this new DIT.

Figure 4.3Figure 4.3 Normalized DIT for holding user certificates.

In this DIT the user henri has three certificates, which are found in the entries immediately beneath that entry in the DIT. They have these distinguished names:

  • tn = Visa, cn = henri, departmentName = art, departmentName = uc

  • tn = Master Card, cn = henri, departmentName = art, departmentName = uc

  • tn = American Express, cn = henri, departmentName = art, departmentName = uc

This allows an LDAP search operation to retrieve exactly the certificates that it wants and no more. For example, to retrieve henri's Visa certificate, this search could be issued:

  • Base Object = "cn = henri, departmentName = art, departmentName = uc," Scope = single level, Filter = "typeName = Visa"

    • This search would match only tn = Visa, cn = henri, departmentName = art, departmentName = uc

If the alternate schema had been used, all of the certificates for the user henri would have been stored in the userCertificate attribute. The LDAP client would have to retrieve all of the certificates and parse through them to find the one that had been issued by Visa. Notice that this still allows for the easy retrieval of all of henri's certificates. This is done using the following search operation:

  • Base Object = "cn = henri, departmentName = art, departmentName = uc," Scope = single level, Filter = "objectClass = certificateType"

    • This search would match all three certificateType entries in the DIT below bruceg's entry.

This same mechanism of restructuring the DIT and redefining classes can be used anywhere that attributes can have numerous values and LDAP clients need to retrieve the values only a few at a time. This mechanism also makes it simple to find all of the certificates from a single issuer or a certain type. For example, to find all of the certificates in the art department that are from Visa, the following search operation is used:

  • Base Object = "departmentName = art, departmentName = uc," Scope = subtree, Filter = "typeName = Visa"

    • This would match the three Visa certificateType entries in the DIT.

      • tn = Visa, cn = henri, departmentName = art, departmentName = uc

      • tn = Visa, cn = pablo, departmentName = art, departmentName = uc

      • tn = Visa, cn = augustus, departmentName = art, departmentName = uc

In these examples, the entire certificateType entry is retrieved. Note that it is possible to just retrieve the certificate itself by naming the userCertificate attribute type in the attributes field of the Search operation. Note that if there are multiple Visa certificates for a single user, then the userCertificate attribute would have multiple values for this certificateType entry. If this situation arises, a new naming scheme for the certificateType entries should be employed.

Delete and Update Anomalies

Delete and Update Anomalies occur in LDAP when there is a reference in one entry to the distinguished name of another entry. When the referenced distinguished name is deleted or renamed, the entries references are no longer valid. Some LDAP implementations go to great pains when entries are deleted or moved to make sure that all objects that reference the modified or deleted _entry are updated as appropriate.

A better solution that eliminates these anomalies is to restructure the DIT to take advantage of the hierarchy. Some object classes use the technique of placing the distinguished names of the referenced entries directly in the entry as in this standard LDAP object class:

( NAME 'groupOfNames' SUP top STRUCTURAL MUST _
( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

where the member attribute has this definition:

( NAME 'member' SUP distinguishedName )

The use of the SUP designation in the attribute type definition is similar to its use in the object class definition. It is an indication that the syntax and matching rules in the specified SUP attribute type are to be used in this attribute type definition. Using this definition, each time a member in the groupOfNames is deleted or renamed, the groupOfNames object must be updated so that all of the member attribute values are valid. A better solution is to remove the member attribute from the groupOfNames object class and to place all member entries in the DIT beneath the groupOfNames object. Unfortunately, this is not a general solution since it does not allow the same member entry to enjoy membership in multiple groups. However, there are many applications in which restructuring the DIT in this way can be achieved.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020