JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Naming and Directory Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Naming and Directory Services (Overview)

2.  Name Service Switch (Overview)

3.  Managing DNS (Tasks)

4.  Setting Up Oracle Solaris Active Directory Clients (Tasks)

Part II NIS Setup and Administration

5.  Network Information Service (Overview)

6.  Setting Up and Configuring NIS (Tasks)

7.  Administering NIS (Tasks)

8.  NIS Troubleshooting

Part III LDAP Naming Services

9.  Introduction to LDAP Naming Services (Overview)

Audience Assumptions

Suggested Background Reading

Additional Prerequisite

LDAP Naming Services Compared to Other Naming Services

Advantages of LDAP Naming Services

Restrictions of LDAP Naming Services

LDAP Naming Services Setup (Task Map)

LDAP Data Interchange Format

Using Fully Qualified Domain Names With LDAP

Default Directory Information Tree

Default LDAP Schema

Service Search Descriptors and Schema Mapping

Description of SSDs

attributeMap Attributes

objectclassMap Attribute

LDAP Client Profiles

LDAP Client Profile Attributes

Local LDAP Client Attributes

ldap_cachemgr Daemon

LDAP Naming Services Security Model

Transport Layer Security

Assigning Client Credential Levels

LDAP anonymous Credential Level

LDAP proxy Credential Level

LDAP proxy anonymous Credential Level

LDAP per-user Authentication

enableShadowUpdate Switch

Credential Storage for LDAP Clients

Choosing Authentication Methods for the LDAP Naming Service

Specifying Authentication Methods for Specific Services in LDAP

Pluggable Authentication Methods

pam_unix_* Service Modules

Kerberos Service Module

LDAP Service Module

PAM and Changing Passwords

LDAP Account Management

LDAP Account Management With the pam_unix_* Modules

10.  Planning Requirements for LDAP Naming Services (Tasks)

11.  Setting Up Oracle Directory Server Enterprise Edition With LDAP Clients (Tasks)

12.  Setting Up LDAP Clients (Tasks)

13.  LDAP Troubleshooting (Reference)

14.  LDAP Naming Service (Reference)

15.  Transitioning From NIS to LDAP (Tasks)



Service Search Descriptors 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 LDAP naming service to search in other locations than the default locations in the DIT by using service search descriptors (SSDs). 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 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.

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

In the following example, the 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)).

serviceSearchDescriptor: passwd:ou=west,dc=example,

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.

defaultSearchBase: dc=example,dc=com
serviceSearchDescriptor: \

attributeMap Attributes

The LDAP naming service allows one or more attribute names to be remapped for any of its services. (The LDAP client uses the well-known attributes documented in Chapter 14, LDAP Naming Service (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 mappings.

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 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

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

objectclassMap Attribute

The 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.

objectclassMap: passwd:posixAccount=myUnixAccount