Service Search Descriptors (SSDs) and Schema Mapping
Note - If you use schema mapping, you must do so in a very
careful and consistent manner. Make sure the syntax of the mapped attribute is
consistent with the attribute it is mapped to. In other words, make sure
that single-valued attributes map to single-valued attributes, that the attribute syntaxes are in agreement,
and that mapped object classes have the correct mandatory (possibly mapped) attributes.
As previously discussed, LDAP naming services expect, by default, the DIT to be
structured in a certain way. If you want, you can instruct the Solaris
LDAP naming service to search in other locations than the default locations in
the DIT. Additionally, you can specify that different attributes and object classes be
used in place of those specified by the default schema. For a list
of default filters, see Default Filters Used by LDAP Naming Services.
Description of SSDs
The serviceSearchDescriptor attribute defines how and where an LDAP naming service client should
search for information for a particular service. The serviceSearchDescriptor contains a service name, followed
by one or more semicolon-separated base-scope-filter triples. These base-scope-filter triples are used
to define searches only for the specific service and are searched in order.
If multiple base-scope-filters are specified for a given service, then when that
service looks for a particular entry, it will search in each base with
the specified scope and filter.
Note - The default location is not searched for a service (database) with an SSD
unless it is included in the SSD. Unpredictable behavior will result if
multiple SSDs are given for a service.
In the following example, the Solaris LDAP naming service client performs a one-level
search in ou=west,dc=example,dc=com followed by a one-level search in ou=east,dc=example,dc=com for the passwd service.
To look up the passwd data for a user's username, the default LDAP
filter (&(objectClass=posixAccount)(uid=username)) is used for each BaseDN.
In the following example, the Solaris LDAP naming service client would perform a
subtree search in ou=west,dc=example,dc=com for the passwd service. To look up the
passwd data for user username, the subtree ou=west,dc=example,dc=com would be searched with the
LDAP filter (&(fulltimeEmployee=TRUE)(uid=username)).
It is also possible to associate multiple containers with a particular service type.
In the following example, the service search descriptor specifies searching for the password
entries in three containers.
Note that a trailing ',' in the example implies that the defaultSearchBase
is appended to the relative base in the SSD.
The Solaris LDAP naming service allows one or more attribute names to be
remapped for any of its services. (The Solaris LDAP client uses the well-known
attributes documented in Chapter 14, LDAP General Reference (Reference).) If you map an attribute, you must be
sure that the attribute has the same meaning and syntax as the original
attribute. Note that mapping the userPassword attribute might cause problems.
There are a couple of reasons you might want to use schema
You want to map attributes in an existing directory server
If you have user names that differ only in case, you must map the uid attribute, which ignores case, to an attribute that does not ignore case
The format for this attribute is service:attribute-name=mapped-attribute-name.
If you want to map more than one attribute for a given
service, you can define multiple attributeMap attributes.
In the following example, the employeeName and home attributes would be used
whenever the uid and homeDirectory attributes would be used for the passwd
There exists one special case where you can map the passwd service's
gecos attribute to several attributes. The following is an example.
attributemap: gecos=cn sn title
This maps the gecos values to a space separated list of the cn,
sn, and title attribute values.
The Solaris LDAP naming service allows object classes to be remapped for any
of its services. If you want to map more than one object class
for a given service, you can define multiple objectclassMap attributes. In the following example,
the myUnixAccount object class is used whenever the posixAccount object class is used.