The mapping for naming service data to LDAP is defined in three Internet Engineering Task Force (IETF) schemas. These are:
In addition to these, there are two Solaris OE schemas. These are:
The schema definitions are provided in the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP. This book is part of Solaris 9 9/02 OE release).
It should be noted that schema definitions only define object classes and attributes that are either required or allowed. They do not specify how the corresponding entries are created. That is, they do not specify a distinguished name (DN), which is used to identify entries. The next section discusses the significance of DNs.
Entries are identified by a DN which is analogous to a path name in a Solaris OE file system, only in reverse order. The left most component of the DN is called the Relative Distinguished Name (RDN) and consists of one or more naming attributes and their values. The naming attribute can be any attribute contained in the entry. The components to the right of the RDN identify the tree or subtree where the entry resides. The RDN only needs to be unique within a container, although in most cases you would want to make it unique within the entire directory. For example, you may want to separate users in different subtrees, but you would want to give each one a unique uid attribute value. The following is an example of an entry's DN:
The component uid=mhaines is the RDN, and the components ou=people , dc= example , dc=com represent where in the directory information tree (DIT) the entry is stored. The attribute uid is used as the naming attribute, although another attribute like cn would work. The reason uid is commonly used is that most enterprises have established unique user identifiers for all their computer users.
RDNs can also be multivalued. In this case, you would have more than one naming attribute. While multivalued RDNs are not common, they are used to represent Solaris hosts entries because the same IP address can be associated with multiple host names . By specifying both the host name and IP address in the RDN, unique entries can be created.
How Clients Use Entry DNs
Most LDAP clients do not reference an entry DN directly. Instead, a search is made specifying some attribute, like uid , as part of a filter and requesting the DN to be returned. The DN can then be used for authentication by attempting an LDAP bind operation with the returned DN as the bind DN. For example, if a Solaris OE user logs in using pam_ldap , the following sequence occurs:
LDAP client programs such as ldapaddent actually create entries. When an entry is created, a DN must be specified. To create the DN, predetermined default naming attributes are chosen . While the Secured LDAP Client can work with entries created that use a different naming attribute, for compatibility it is best to stick with this convention. The next section describes how to use the ldapaddent command to create LDAP entries.