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 https://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.
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 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 via 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.