(presented on 2004-06-09)
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
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.
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.
An example search filter:
(&(objectClass=person) (!(telephoneNumber=*)) (|(cn=*a*b*)(cn=*b*a*)))
attributetype ( 184.108.40.206 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )
Can also contain
objectclass ( 220.127.116.11 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )