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 http://www.ietf.org/rfc.html. 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.

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 192.0.0.1 and port 65535, you specify the following.

preferredServerList=192.0.0.1:65535

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.

• none

  The none authentication method is the default. While using none requires no setup, it also provides no security. It is only suitable for use in environments that have no security requirements at all.

  To use the none authentication, make sure that the authenticationMethod attribute has the following value.

  authenticationMethod=none

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.

• simple

  The simple authentication method provides authentication by unencrypted exchange of a password string. Since the password is sent in the clear between the LDAP client (the rpc.nisd daemon) and LDAP server, the simple method is suitable only when information exchange between the NIS+ and LDAP servers is protected by some other method.

  For instance, transport layer encryption of LDAP traffic, or the special case where the NIS+ and LDAP server is one and the same system, and the NIS+/LDAP traffic stays in the kernel, protected from the eyes of unauthorized users.

  Modify the configuration of the rpc.nisd daemon with the DN and password to use for the simple authentication. For example, if the DN is cn=nisplusAdmin,ou=People,dc=some,dc=domain, and the password aword, establish the following.

  authenticationMethod=simple
  nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain
  nisplusLDAPproxyPassword=aword

  Be sure to protect the place where the password is stored from unauthorized access. Remember that if the password is specified on the rpc.nisd command line, it might be visible to any user on the system by commands such as ps(1).

• sasl/digest-md5

  The sasl/digest-md5 authentication method provides authentication using the digest/md5 algorithm.

  Consult your LDAP server documentation for information on how to set up an authorization identity for use with digest-md5, and modify the /etc/default/rpc.nisd file to specify this identity and its associated password.

  authenticationMethod=sasl/digest-md5
  nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain
  nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

• sasl/cram-md5

  Authentication using the cram/md5 algorithm. Probably only supported by the obsolete SunDS LDAP server.

  Consult your LDAP server documentation for information on how to set up a bind DN for use with cram-md5, and modify the /etc/default/rpc.nisd file to specify this DN and its associated password.

  authenticationMethod=sasl/cram-md5
  nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain
  nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

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.

nisplusLDAPTLS=ssl
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db

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

where

• server-address

  IP address portion of preferredServerList value from /etc/default/rpc.nisd

• bind-DN

  nisplusLDAPproxyUser value from /etc/default/rpc.nisd

• password

  nisplusLDAPproxyPassword value from /etc/default/rpc.nisd

• container

  One of the RFC 2307 container names (ou=Services, ou=Rpc, and so on)

• search-base

  defaultSearchBase value from /etc/default/rpc.nisd

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.