Mapping Naming Service Data to LDAP Entries

The mapping for naming service data to LDAP is defined in three Internet Engineering Task Force (IETF) schemas. These are:

• RFC 2307 bis Network Information Service Schema

• LDAP Mailgroups Internet Draft Schema

• Internet Print Protocol Draft Schema

In addition to these, there are two Solaris OE schemas. These are:

• Solaris OE Project Schema

• Roles-Based Access Control (RBACK) Schema

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.

Entry Formats

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:

1. The user's uid is sent to the directory server as part of a search filter that includes a search base.

2. Starting at the specified search base, a search is performed for an entry that has a uid value matching the one sent to it.

3. The user's entry is returned to the client.

4. The client binds to the directory with the DN of that entry.

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.