- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
LDAP Naming Model
Understanding the LDAP naming model is key to knowing how to configure and administer native Solaris LDAP. Most Solaris administrators are unfamiliar with this model and often are tripped up by some of the naming conventions. While the LDAP naming model may seem cryptic at first, keep in mind the goals of LDAP. It is designed to be flexible, but at the same time to provide a structure so that LDAP clients can access data in any LDAP-compliant directory.
Before a client can access data in a directory it must know how to locate that data. Unlike a Solaris file system where a search can always be initiated from the root file system (/), LDAP begins a search by specifying one specific entry, such as dc=blueprints, dc=com, as a search base. The entry name is specified as a distinguished name (DN) which is a series of relative distinguished names (RDNs). Each directory server contains a single root directory specific entry (DSE) which contains basic information about the LDAP server. The DSE is specified during base level searches on a directory when you do not know the name of a particular suffix.
As previously mentioned, each entry is identified by its DN. The DN is similar to a Solaris file system pathname, but is specified in the reverse order. However, for directory entries, unlike files, it is the value of their attributes which make each entry unique. To understand the role of attributes, a discussion on the structure of directory entries is useful.
Directory Objects and Attributes
The structure of a directory entry is defined by the object class to which it belongs. An object class defines a set of attributes that can be stored in a directory entry. LDAP object classes are extensible by creation of a new class that is a child of an existing one. All the attributes defined in the parent class are inherited by the child. The name of an object class must be unique within the directory server and can be registered as a standard LDAP object. These objects are assigned a numeric object identifier (OID) to ensure they will not conflict with another object class.
Attribute names are unique within the directory server and can be contained in more than one object class. The type of data that can be stored in an attribute is well-defined, as is the way LDAP searches treat the data. For example, data stored in a string can either be case sensitive or not. If the data is not case sensitive any combination of upper and lowercase characters in a string results in a match. If the data is case sensitive, an exact match is required. Attributes can also contain more than one value and can have aliases.
To promote interoperation, a set of standard LDAP object classes and attributes have been defined. Definitions of these ship with most LDAP servers in the form of schema configuration files. If they do not exist on a server, you can add the content of these schema files to your LDAP configuration files. For example, to use native LDAP, you need to add extra object classes and attributes to the iPlanet Directory Server configuration files, as discussed in Chapter 5, "Solaris 8 Native LDAP Configuration."
Directory Schema
The information specified in a directory schema includes the object class name, required and allowed attributes, an optional OID number, and the allowable syntax. TABLE 2-5 shows the schema definition for the posixAccount object class attributes that stores Solaris user account information.
TABLE 2-5 posixAccountAttributes
|
Attribute |
Description |
Syntax |
|
cn(commonName) |
Common Name of the POSIX account |
cis (1-many) |
|
gidNumber |
Unique integer identifying group membership |
int (single) |
|
homePhone |
The entry's home phone number |
tel |
|
uid(userID) |
The user's login name |
cis, 1 |
|
uidNumber |
An integer uniquely identifying a user |
int |
|
description |
A human-readable description of the object. |
cis |
|
gecos |
GECOS comment field |
cis |
|
loginShell |
Path to the login shell |
ces (single) |
|
userPassword |
Entry's password and encryption method |
bin, 1 |
In this example, cn is a case-insensitive string that can contain multiple values. The gidNumber and uidNumber are integers, and homePhone is represented by a special data type used for telephone numbers. Note that the LDAP uid, which is a string, is not the same as the numeric Solaris UID, which is represented by the LDAP attribute uidNumber. A complete description of all iPlanet Directory Server schema definitions can be found under documentation on the iPlanet Web site: iplanet.com.
Distinguished Names
Recall that a directory entry is identified by its DN, which is similar to a file system path name. However, entries are composed of many attributes, some of which are the same as other entries. To distinguish between entries that may have the same values for some attributes, one attribute is usually singled out as being unique. For user account entries defined in the posixAccount object class, that attribute is uid. To prevent duplicate values being used, the iPlanet Directory Server is configured by default to enforce uid attribute uniqueness. Entries that do not have a uid attribute are typically identified by the commonName (cn) attribute, which is available in most object classes, but is not required by all object classes such as organization (o) and organization unit (ou).
The form of a DN is:
attribute=value,container,suffix
where there may be multiple containers depending on the DIT topology. An example of a DN for an user account is:
cn=Cathy Miller,ou=People,dc=blueprints,dc=com
The RDN specifies the left-most portion of the DN, which uniquely identifies the entry relative to its parent. For example:
cn=Cathy Miller
In this case, cn=Cathy Miller has to be unique within the ou=People container.