Since LDAP is a directory service, its basic data element is known as an “entry.” Like a phone book entry, there are a number of attributes that are associated with the entry when regarded as an object. For example, a phone directory object has a surname, first name, address, and phone number that together comprise a single entry when instantiated. The overall organization of entries in an LDAP directory is defined by a schema, which consists of a ruleset that determines what attributes can be associated with different object types. Although it is possible to define your own schemas and data models, all LDAP servers support a standard schema that promotes interoperability—and is the basis for the LDAP standard as proposed in RFC 2307. Alternatively, your application can extend the standard schema with some additional object attributes, although these may not be accessible by other servers.
LDAP is used in Solaris 9 as a naming service that is compatible with existing NIS and NIS+ services. This allows integration at the present time, but also suggests future deprecation of the NIS and NIS+ services. iDS contains a set of objects and their attributes that are able to store all of the data contained within NIS/NIS+ maps and tables.
Additional schema data must also be stored within the LDAP directory to support client operations.
The directory structure for LDAP is arranged hierarchically, from a single top node within the Directory Information Tree (DIT) to as many levels of abstraction as are required to support an organization’s directory requirements. The tree structure might, for example, be based on purely geographical information, with the top node representing a country. Or, it might be based on organizational lines, with the top node corresponding to a company name. All entries within the tree can be identified by their Distinguished Name (DN), and each attribute of the entry can be described as a Relative Distinguished Name (RDN). Figure 31-1 shows an example DIT, with all of the common elements found therein.
At the first level, the country c is defined as US, so the DN would simply be c=US. At the second level, the organization o is defined as cassowary.net, so the DN is defined as dc=cassowary, dc=net, c=US, where dc represents the Domain Component (DC). On the third level, the organizational unit ou is defined as Engineering, so the DN is defined as ou=Engineering, dc=cassowary, dc=net, c=US. On the fourth level, an individual user is identified by a Common Name (CN) of Paul Watters, and a corresponding UID of paul. Thus, the DN is uid=paul, ou=Engineering, dc=cassowary, dc=net, c=US. Thus, it is possible to clearly distinguish individuals belonging to organizations and departments in specific countries from each other by simply using a DN if the DIT is defined at a fine-grained level, assuming that no two users in the same department have exactly the same name.
You should be able to identify and interpret elements of a DIT for the exam.
Exercise 31-2 DIT Creation Create a sample DIT for yourself and your organization, following the example given previously.
iDS stores all data in LDIF files. This standard is used by all LDAP directory servers and many messaging systems to store user and group data. Thus, it is possible to export an LDIF file with an organization’s data from a previous version of iDS and import it here. Alternatively, third-party products may be able to export LDIF files, which can also be read into iDS, to initialize the directory structure. Let’s look at an example entry in an LDIF file for the directory entry we’ve defined previously:
dn: cn=Paul Watters, o=cassowary.net, c=US cn: Paul Watters sn: Watters mail: email@example.com objectClass: people
As you can see, the LDIF file structure simply reflects the attributes that are defined within the directory, written sequentially to the file immediately following the DN.
You should be able to identify and interpret elements of an LDIF for the exam.