Basic Components and Concepts (Overview)

This chapter covers the following topics.

• "Default Schema"

• "Default Directory Information Tree (DIT)"

• "Service Search Descriptors (SSDs) and Schema Mapping"

• "Client Profiles"

• "ldap_cachemgr Daemon"

• "LDAP Naming Service Security Model"

Default Directory Information Tree (DIT)

By default, Solaris LDAP clients access the information assuming that the DIT has a given structure. For each domain supported by the LDAP server, there is an assumed subtree with an assumed structure. This default structure, however, can be overridden by specifying Service Search Descriptors (SSDs). For a given domain, the default DIT will have a base container that holds a number of subtrees containing entries for a specific information type. See the following table for the names of these subtrees.

Table 13-1 DIT Default Locations

Default Schema

Schemas are definitions describing what types of information can be stored as entries in an LDAP directory. To support Solaris 9 LDAP naming clients, the directory server's schema might need to be extended. Detailed information about IETF and Solaris specific schemas is included in Chapter 18, General Reference. The various RFCs can also be accessed on the IETF web site http://www.ietf.org.

Service Search Descriptors (SSDs) and Schema Mapping

Note - If you use schema mapping, you must do so in a very careful and consistent manner.

As discussed above, the Solaris LDAP naming service expects, by default, the DIT to be structured in a certain way. If you wish, 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 Naming Services".

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 - Note that the default location is not searched for a service (database) with a SSD unless it is included in the SSD. Unpredictable behavior will result if multiple SSDs are given to 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 lookup the passwd data for a user's username, the default LDAP filter (&(objectClass=posixAccount)(uid=username)) is used for each BaseDN.

serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east, dc=example,dc=com

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 lookup 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)).

serviceSearchDescriptor: passwd:ou=west,dc=example, dc=com?sub?fulltimeEmployee=TRUE

It is also possible to associate multiple container with a particular service type.

For example, the service search descriptor

defaultSearchBase: dc=example,dc=com serviceSearchDescriptor: \ passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com

specifies that the three containers, ou=myuser,dc=example,dc=com, ou=newuser,dc=example,dc=com, and ou=extuser,dc=example,dc=com are searched for the password entries. Note that a trailing ',' implies that the defaultSearchBase is appended to the relative base in the SSD.

Attribute Map

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 18, General 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 may cause problems.

There are a couple of reasons you might want to use schema mappings.

• 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 is service:attribute-name=mapped-attribute-name.

If you wish 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 for the passwd service.

attributeMap: passwd:uid=employeeName attributeMap: passwd:homeDirectory=home

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

The above maps the gecos values to a space-separated list of the cn, sn and title attribute values.

objectClass Map

The Solaris LDAP naming service allows object classes to be remapped for any of its services. If you wish 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.

objectclassMap: passwd:posixAccount=myUnixAccount

Client Profiles

To simplify Solaris client setup, and avoid having to reenter the same information for each and every client, create a single client profile on the directory server. This way, a single profile defines the configuration for all clients configured to use it. Any subsequent change to the profile attributes is propagated to the clients at a rate defined by the refresh interval.

These client profiles should be stored in a well-known location on the LDAP server. The root DN for the given domain must have an object class of nisDomainObject and a nisDomain attribute containing the client's domain. All profiles are located in the ou=profile container relative to this container. These profiles should be readable anonymously.

Client Profile Attributes

The following lists the Solaris LDAP client's profile attributes, which can be set automatically when you run idsconfig. See "Initializing a Client Manually" for information on how to set a client profile manually.

Table 13-2 Client Profile Attributes