LDAP presents a distributed tree of information

Writing things down: LDIF

dn: gn=John+sn=Doe,ou=Research & Development,ou=Pe
 ople,dc=example,dc=com
objectClass: addressbookPerson
gn: John
sn: Doe
street: Back alley
postOfficeBox: 123
postalCode: 54321
postalAddress: Backstreet
st: NY
l: New York City
c: US

Writing things down: LDIF

dn: gn=John+sn=Smith,ou=Marketing,ou=People,
 dc=example,dc=com
objectClass: addressbookPerson
gn: John
sn: Smith
telephoneNumber: 555-1234
facsimileTelephoneNumber: 555-1235
description: This is a description that can span multi
 ple lines as long as the non-first lines are inden
 ted in the LDIF.

Object-oriented look at LDAP entries

A lot of similarities with OO programming languages, but some big differences, too.

• An LDAP entry corresponds with an object.

• Whereas object are usually instances of a single class, LDAP entries can "implement" multiple objectClasses.

• objectClasses can inherit zero, one or many objectClasses, just like programming classes.

• objectClasses have a root class, known as top; many object oriented programming languages have a root class, e.g. named Object.

• objectClasses are either STRUCTURAL or AUXILIARY; entries can only implement one STRUCTURAL objectClass.

• The objectClasses of an entry can be changed at will; you only need to take care that the entry has all the MUST attribute types, and no attribute types outside of the ones that are MUST or MAY.

  Note that e.g. OpenLDAP doesn't implement this.

• Attributes of an entry closely match attributes of objects in programming languages; however, LDAP attributes may have multiple values.

Search inputs

• The base DN for the search
• A search filter, specifying criteria an entry must fulfill to match.
• Scope of the search, either look at the base DN only, only look one level below it, or look at the whole subtree rooted at the base DN.
• Size limit of at most how many matching entries to return.
• Attributes to return, or none for all attributes the matching entries happen to have.

An example search filter:

(cn=John Smith)

Phases of the protocol chat

1. Open and bind
2. Search (possibly many times)
3. Unbind and close

Opening and binding

Doing a search

Doing multiple searches

Unbinding and closing

A complex search filter

(&(objectClass=person)
    (!(telephoneNumber=*))
    (|(cn=*a*b*)(cn=*b*a*)))

Objectclasses

• Special attribute objectClass lists all the objectclasses an LDAP entry manifests.
• Objectclass defines
  • what attributetypes an entry MUST have
  • what attributetypes an entry MAY have
• An entry in a phonebook must have a name and a telephone number, and may have a fax number and street address.

Schema

• a configuration file included in the LDAP server configuration.
• a combination of attribute type and object class definitions.
• stored as plain text
• can be requested over an LDAP connection

Attribute type

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
        DESC 'RFC2256: last (family) name(s) for
              which the entity is known by'
        SUP name )

Can also contain

• content data type
• comparison and sort mechanism
• substring search mechanism
• whether multiple values are allowed

Object class

objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber
                $ seeAlso $ description ) )

Creating schemas

• Anyone can create their own schema
• Need to be globally unique
• But try to use already existing ones

Thank You

Questions?