System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

The Directory Server (NIS+ to LDAP)

The LDAP mapping portion of the rpc.nisd daemon uses LDAP protocol version 3 to talk to the LDAP server. The default mapping configuration (/var/nis/NIS+LDAPmapping.template) expects that the LDAP server supports an extended version of RFC 2307. RFCs can be retrieved from While the mapping between NIS+ and LDAP data can be modified using NIS+LDAPmapping(4), there is a basic assumption that the LDAP data is organized along the principles laid out in RFC 2307.

For example, in order to share account information between direct LDAP clients and NIS+ clients, the LDAP server must support storing account (user) passwords in the UNIX crypt format. If the LDAP server cannot be configured to do so, you can still store NIS+ data, including accounts, in LDAP. However, you will not be able to fully share account information between NIS+ users and LDAP bindDNs.

Configuring the Sun Java System Directory Server

Refer to the Sun Java System Directory Server Collection for detailed instructions on the installation, setup and administration of Sun Java System Directory Server.

You can use idsconfig(1M) to configure Sun Java System Directory Server for LDAP clients using LDAP as a naming service. The setup provided by idsconfig(1M) is also appropriate when using NIS+ with an LDAP data repository.

Note –

If you are using an LDAP server other than Sun Java System Directory Server, you must manually configure the server to support the RFC 2307 schemas.

Assigning Server Address and Port Number

The /etc/default/rpc.nisd file is set up to use a local LDAP server at port 389. If this is not correct in your configuration, establish a new value for the preferredServerList attribute. For example, to use an LDAP server at IP address and port 65535, you specify the following.


Security and Authentication

Authentication between NIS+ clients and the NIS+ server is not affected when the NIS+ server is obtaining data from LDAP. However, in order to maintain the integrity of the NIS+ data when it is stored in LDAP, consider configuring authentication between the rpc.nisd daemon and the LDAP server. Several different types of authentication are available, depending on the capabilities of the LDAP server.

The LDAP authentication supported by the rpc.nisd daemon includes the following.

The authentication methods that actually provide at least some security typically require that you associate a shared secret (a password or key) with a DN in LDAP. The DN you select for use by the rpc.nisd daemon can be unique, or can also be used for other purposes. It should have appropriate capabilities to support the expected LDAP traffic. For example, if the rpc.nisd daemon should be able to write data to LDAP, the selected DN must have the right to add/update/delete LDAP data in the containers used for the NIS+ data. Also, the LDAP server might, by default, impose limitations on resource usage (such as search time limits or search result size limitations). If this is the case, the selected DN must have sufficient capabilities to support enumeration of the NIS+ data containers.

Using SSL

The rpc.nisd daemon also supports transport layer encryption of LDAP traffic using SSL. Consult your LDAP server documentation to generate an SSL certificate for LDAP server authentication. Store the certificate in a file on the NIS+ server (/var/nis/cert7.db, for example) and modify /etc/default/rpc.nisd as follows.


Be sure to protect the certificate file from unauthorized access. Note that the above provides session encryption and authentication of the LDAP server to the rpc.nisd. It does not provide authentication of the rpc.nisd to the LDAP server, since the certificate does not contain anything that identifies the LDAP client (rpc.nisd). However, you can combine SSL with another authentication method (simple, sasl/digest-md5 ) in order to achieve mutual authentication.

Performance and Indexing

When the rpc.nisd daemon is asked to enumerate an NIS+ table (using niscat(1) for example) that is mapped from LDAP, it will enumerate the corresponding LDAP container if at least one entry in the table has an expired TTL. Although this container enumeration is done in the background, so that LDAP performance is of limited importance, it can nevertheless be beneficial to establish LDAP indices to speed up container enumeration for large containers.

To obtain an estimate of the amount of time required for enumeration of a particular container, you can use a command like the following.

% /bin/time ldapsearch -h server-address -D bind-DN -w password \

-b container, search-base 'cn=*' /dev/null


The “real” value printed by /bin/time is the elapsed (wall-clock) time. If this value exceeds a significant fraction (25 percent or more) of the TTL for the corresponding table entries (see Authentication and Security), it might be beneficial to index the LDAP container.

The rpc.nisd supports the simple page and VLV indexing methods. Refer to your LDAP server documentation to find out which indexing methods it supports, and how to create such indices.