Understanding LDAP (part 1) - Treating Entries As Objects (
Page 4 of 5 )
So that
(hopefully) takes care of understanding how LDAP entries are structured. Now,
let's go one level deeper, into the actual content of each
entry.
Consider the following sample entry, shamelessly copied from the
previous page:
dn: mail=joe@melonfire.com, dc=melonfire, dc=com
objectclass: inetOrgPerson
cn: Joe
sn: Somebody
mail: joe@melonfire.com
telephoneNumber: 1 234 567 8912
As you can see, this entry, which represents a person,
consist of several attributes: common name ("cn"), surname ("sn"), email address
("mail") and telephone number ("telephoneNumber"). Contrary to what you might
think, these attributes have not been created by me willy-nilly - rather, they
correspond to pre-existing definitions for what an LDAP entry must
contain.
Where is this definition, and how does LDAP know what each entry
should and should not contain, you ask wonderingly?
The answer lies in
the second line of the entry above, in the "objectclass" attribute:
objectclass: inetOrgPerson
You see, LDAP is a very object-oriented beast. Every entry in
an LDAP database is an instance of an object, and must therefore correspond to
the rules laid down for the attributes of that object. These rules are very
precise, clearly stating the allowed attribute names for an object, which
attributes are mandatory and which are optional, and the allowed data types for
the value of each attribute.
In the example above, the entry for Joe
Somebody has been specified as an instance of the object class "inetOrgPerson",
and must therefore correspond to the rules laid down in the definition, or
"schema", for that class. Here it is:
# InetOrgPerson (RFC2798)
#
# Depends upon
# Definition of an X.500 Attribute Type and an Object Class to Hold
# Uniform Resource Identifiers (URIs) [RFC2079]
# (core.schema)
#
# A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256]
# (core.schema)
#
# The COSINE and Internet X.500 Schema [RFC1274] (cosine.schema)
# carLicense
# This multivalued field is used to record the values of the license or #
registration plate associated with an individual. attributetype (
2.16.840.1.113730.3.1.1
NAME 'carLicense'
DESC 'RFC2798: vehicle license or registration plate'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# departmentNumber
# Code for department to which a person belongs. This can also be #
strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123). attributetype
( 2.16.840.1.113730.3.1.2
NAME 'departmentNumber'
DESC 'RFC2798: identifies a department within an organization'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# displayName
# When displaying an entry, especially within a one-line summary list, it #
is useful to be able to identify a name to be used. Since other attri- #
bute types such as 'cn' are multivalued, an additional attribute type is #
needed. Display name is defined for this purpose. attributetype (
2.16.840.1.113730.3.1.241
NAME 'displayName'
DESC 'RFC2798: preferred name to be used when displaying entries'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# employeeNumber
# Numeric or alphanumeric identifier assigned to a person, typically based #
on order of hire or association with an organization. Single valued.
attributetype ( 2.16.840.1.113730.3.1.3
NAME 'employeeNumber'
DESC 'RFC2798: numerically identifies an employee within an
organization'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# employeeType
# Used to identify the employer to employee relationship. Typical values #
used will be "Contractor", "Employee", "Intern", "Temp", "External", and #
"Unknown" but any value may be used. attributetype ( 2.16.840.1.113730.3.1.4
NAME 'employeeType'
DESC 'RFC2798: type of employment for a person'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# jpegPhoto
# Used to store one or more images of a person using the JPEG File #
Interchange Format [JFIF]. # Note that the jpegPhoto attribute type was
defined for use in the # Internet X.500 pilots but no referencable
definition for it could be # located. attributetype (
0.9.2342.19200300.100.1.60
NAME 'jpegPhoto'
DESC 'RFC2798: a JPEG image'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
# preferredLanguage
# Used to indicate an individual's preferred written or spoken # language.
This is useful for international correspondence or human- # computer
interaction. Values for this attribute type MUST conform to # the
definition of the Accept-Language header field defined in # [RFC2068] with
one exception: the sequence "Accept-Language" ":" # should be omitted.
This is a single valued attribute type. attributetype (
2.16.840.1.113730.3.1.39
NAME 'preferredLanguage'
DESC 'RFC2798: preferred written or spoken language for a person'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
# userSMIMECertificate
# A PKCS#7 [RFC2315] SignedData, where the content that is signed is #
ignored by consumers of userSMIMECertificate values. It is # recommended
that values have a `contentType' of data with an absent # `content' field.
Values of this attribute contain a person's entire # certificate chain and
an smimeCapabilities field [RFC2633] that at a # minimum describes their
SMIME algorithm capabilities. Values for # this attribute are to be stored
and requested in binary form, as # 'userSMIMECertificate;binary'. If
available, this attribute is # preferred over the userCertificate attribute
for S/MIME applications. ## OpenLDAP note: ";binary" transfer should NOT be
used as syntax is binary attributetype ( 2.16.840.1.113730.3.1.40
NAME 'userSMIMECertificate'
DESC 'RFC2798: PKCS#7 SignedData used to support S/MIME'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
# userPKCS12
# PKCS #12 [PKCS12] provides a format for exchange of personal identity #
information. When such information is stored in a directory service, # the
userPKCS12 attribute should be used. This attribute is to be stored # and
requested in binary form, as 'userPKCS12;binary'. The attribute # values
are PFX PDUs stored as binary data. ## OpenLDAP note: ";binary" transfer
should NOT be used as syntax is binary attributetype (
2.16.840.1.113730.3.1.216
NAME 'userPKCS12'
DESC 'RFC2798: personal identity information, a PKCS #12 PFX'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
# inetOrgPerson
# The inetOrgPerson represents people who are associated with an #
organization in some way. It is a structural class and is derived # from
the organizationalPerson which is defined in X.521 [X521].
objectclass ( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
)Scary, huh?
Very fundamentally, a schema defines an
object class, naming and describing the attributes that constitute that object,
and also specifying the allowed data types for each. Don't worry too much about
it - schema decryption and design is strictly outside the scope of this
tutorial, so you don't need to lose sleep over the syntax and structure of the
gobbledygook above. Simply note the last line,
objectclass ( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
)which lists the attributes required for any object instance
claiming to belong to this class - the keyword MUST specifies the required
attributes, the keyword MAY specifies the optional attributes and the keyword
SUP specifies the parent of this class.
Which brings me, rather neatly,
to inheritance.
