Related slides on offer

Figure 1053. Openldap server documentation Slide presentation

Exercises are based on the OpenLDAP server implementation.

Related material at

Figure 1054. What is LDAP anyway? Slide presentation
  • Lightweight Directory Access Protocol

  • Vendor independent

  • IETF standard:

    Clients interact with servers using a directory access protocol

Figure 1055. LDAP Server cli bind Slide presentation
Command Result
ldapsearch \
  -h localhost  \
  -D "cn=admin,dc=betrayer,dc=com" \
  -w password -x \
  -b "dc=betrayer,dc=com" \
  -s sub  \
dn: dc=betrayer,dc=com 
objectClass: top
objectClass: dcObject
objectClass: organization
o: Betrayers heaven 
dc: betrayer 

dn: cn=admin,dc=betrayer,dc=com 
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin 
description: LDAP administrator
userPassword:: e1NT...dE53N1E= 

An LDAP server's DNS name or IP address (host).

The bind DN. This path is being required to uniquely identify an existent user entry on the server in question. This corresponds to a login name when using e.g. web gui authentication.

The corresponding password to the given bind DN. The user entry must contain a corresponding userPassword hash value. The -x indicates using simple password based rather than SASL authentication.

The search will start from this uniquely defined node within the servers DIT. In the current example we simply choose the tree's top level node.

The search scope. See The LDAP Search Operation for details.

Suppress verbose search information.

The DIT's top level node.

Your organization's name

The administrative user of the server. This entry will typically be created at installation time.

The administrative user's common name. Note this entry corresponds to on the Command side of this table.

The administrative user password's hash value. Note the double colon :: indicating a base64 encoded binary value.

Figure 1056. Document Information Tree (DIT) Slide presentation

Figure 1057. Relative and absolute DNs Slide presentation

Figure 1058. User example Slide presentation
dn: uid=clark,ou=finance,dc=betrayer,dc=de 
cn: Sandy Clark
homeDirectory: /home/clark
sn: Clark
uid: clark 
uidNumber: 21101
givenName: Sandy
loginShell: /bin/bash
postOfficeBox: 10G
userPassword: {SSHA}noneOfYourBusiness

The entry's absolute distinguished name (DN). This name/value list uniquely identifies an entry (an its position) within a given DIT.

This key/value combination is guaranteed to be unique within respect to the given parent node. It allows to identify each node with respect to its parent. So in a relational model the clark entry would become a weak entity having an identifying ownership relation to its parent organisational unit by virtue of its uid value.

In other words: There is only one such entry below ou=finance,dc=betrayer,dc=de having an uid attribute of value clark.

LDAP allows for multi valued attributes.

Figure 1059. objectClass Slide presentation
  • Structuring LDAP entry data.

  • Categories:

    • Structural

    • Auxiliary

    • Abstract

Figure 1060. objectClass clarifications Slide presentation
Abstract classes:

To be extended by other classes

Structural classes:
  • Each entry requires exactly one.

  • Specify the main type of object.

  • Must not inherit from auxiliary classes.

Auxiliary classes:
  • Provide non-conflicting supplementary information.

  • Think of (Java) interfaces.

  • Must not inherit from structural classes.

Figure 1061. Augmenting inetOrgPerson by posixAccount Slide presentation
Class                       |   Instance uid=clark,ou=finance,dc=betrayer,dc=de
inetOrgPerson (structural)  |                   
   sn                       |    sn: Clark
   cn                       |    cn: Sandy Clark
  ...                       |     
posixAccount (auxiliary)    |     
  cn                        |   see above 
  gidNumber                 |   gidNumber: 23113
  homeDirectory             |   homeDirectory: /home/clark
  uid                       |   uid: clark
  uidNumber                 |   uidNumber: 21101
  userPassword              |   userPassword: {SSHA}noneOfYourBusiness

The cn attribute is being defined both in object class inetOrgPerson and posixAccount. This requires data type definitions to be compatible.

Figure 1062. Structural objectClass definitions Slide presentation

Figure 1063. Search scopes Slide presentation

Figure 1064. Predicate based queries Slide presentation

RFC 4520 defines predicate based queries using RPN style:

  • (| (cn=k*) (uidNumber < 2000))

Figure 1065. LDAP bind types Slide presentation
  • Anonymous bind: No user credentials.

    Note: This typically provides limited privileges.

  • Simple bind: User's DN + password:

    DN: uid=clark,ou=finance,dc=betrayer,dc=de
    password: 123456789

Figure 1066. LDIF exchange format Slide presentation
  • Ldap Data Interchange Format.

  • Importing and exporting LDAP Data.

  • Modifying existing entries (CRUD operations).

  • Pure ASCII.

Figure 1067. LDIF sample Slide presentation
dn: uid=clark,ou=finance,dc=betrayer,dc=de
objectClass: posixAccount
objectClass: inetOrgPerson
cn: Sandy Clark
homeDirectory: /home/clark
sn: Clark
uid: clark 
uidNumber: 21101
givenName: Sandy
loginShell: /bin/bash
postOfficeBox: 10G
userPassword: {SSHA}noneOfYourBusiness

Figure 1068. OpenLdap server architecture Slide presentation
  • An OpenLdap server may host multiple DITs each being represented by its own database backend.

  • The server's configuration is itself being stored as a separate tree.

  • Each tree refers to a separate database backend. Thus the above example featuring two trees is being implemented by two database instances.