-
Notifications
You must be signed in to change notification settings - Fork 0
LDAP
Traditionally, LDAP directory entries are arranged in a hierarchical structure that reflects organizatinoal boundaries.
Each directory entry has a special attribute called objectClass. This attribute controls which attributes are required and allowed in an entry. i.e. the values of the objectClass attribute determine the schema rules the entry must obey.
LDAP refers to entries with Distinguished Names (DNs). DNs consist of the name of the entry itself as well as the names, in order from bottom to top, of the objects above it in the directory. E.g. the complete DN for the entry in the bottom left corner is cn=Tim Jones, o=IBM, c=US.
Each entry has at least one attribute that is used to name the entry. This naming attribute is called the Relative Distinguished Name (RDN) of the entry. (<- is this Tivoli specific term?)
("root")
o=ibm, c=us / \
---------------------------------------------------------------
/ \ objectClass=country
(c = US) (c = UK)
/\ \
---------------------------------------------------------------
/ \ \ objectClass=organization
/ \ \
(o = IBM) (o= Lotus) (o = Tivoli)
/
---------------------------------------------------------------
/ objectClass=person
(cn = Tim Jones)
mail=tjones@ibm.com
telephoneNumber=555-555-1234
To give an LDAP server the capability to manage part of an LDAP directory, you specify the hightest level parent distinguished names in the configuration of the server. These distinguished names are called suffixes. The server can access all objects in the directory that are below the specified suffix in the directory hierarchy. E.g. if an LDAP server contained the directory shown above, it would need to have the suffix o=ibm, c=us specified in its configuration in order to be able to answer client queries regarding Tim Jones.
You are not limited to the traditional hierarchy when structuring your directory. The domain component structure, for example, is gaining popularity. With this structure, entries are composed of the parts of TCP/IP domain. E.g. dc=ibm,dc=com may be preferable to o=ibm,c=us
Some notes: in this context the
dcrefers to "domain component"cnrefers to "common name",snfor surname,
Say that you want to create a directory using the domain component structure that will contain employee data such as names, telephone numbers, and email addresses. You use the suffix or naming context based on the TCP/IP domain. This directory might be visualized as something similar to the following:
/
|
+- ibm.com
|
+- employees
|
+- Tim Jones
| 555-555-1234
| tjones@ibm.com
|
+- John Smith
555-555-1235
jsmith@ibm.com
When entered in the Directory Server this data might actually look similar to the following:
# suffix ibm.com
dn: dc=ibm,dc=com
objectclass: top
objectclass: domain
dc: ibm
# employees directory
dn: cn=employees,dc=ibm,dc=com
objectclass: top
objectclass: container
cn: employees
# employee Tim Jones
dn: cn=Tim Jones,cn=employees,dc=ibm,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: publisher
objectclass: ePerson
cn: Tim Jones
cn: "Jones, Tim"
sn: Jones
givenname: Tim
telephonenumber: 555-555-1234
mail: tjones@ibm.com
# employee John Smith
dn: cn=John Smith,cn=employees,dc=ibm,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: publisher
objectclass: ePerson
cn: John Smith
cn: "Smith, John"
sn: Smith
givenname: John
telephonenumber: 555-555-1235
mail: jsmith@ibm.com
You will notice that the each entry contains attribute values called objectclass. The objectclass values define what attributes are allowed in the entry, such as telephonenumber or givenname. The allowed object classes are defined in the schema.
The schema is a set of rules that defines the type of entries allowed in the database.