Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Native LDAP standalone tools (Duckwater)
1.2. Name of Document Author/Supplier:
Author: Nicolas Williams
1.3 Date of This Document:
11 April, 2008
4. Technical Description
I'm sponsoring this fasttrack for Tomas Heran. The timer is set to
expire on April 18, 2008. The requested release binding is 'patch'.
Duckwater Standalone LDAP naming client utilities
BACKGROUND
==========
The Duckwater project (see PSARC/2007/694 and PSARC/2006/247) intends to
deliver simplified naming services configuration and management by
updating old tools, and introducing new tools and components that
leverage SMF to store naming configurations, and provide consistent
'SMF-like' cfg/adm interfaces for administrative use.
This case provides for separate delivery of a phase 0 sub-component of
the duckwater project that has no dependencies on SMF or other duckwater
enhancements that are planned for subsequent phases. This separate
delivery is needed to address some high call generating CRs and improve
some serious approachability issues in LDAP setup and configuration
immediately.
PROBLEM
=======
There are four highly visible issues with LDAP naming services that
are documented/tracking by the following CRs:
4880322 TLSv1/SSL support needs to become integrated in all LDAP client
programs
4942874 RFE: native ldap client with ssl restricted to ports 636/389
5035244 Make ldapaddent a standalone tool
6227396 *ldaplist* should refer to ldapclient(1M) when ldap not
configured
These issues can be summarized as:
[1] Administrators are unable to upload naming data into directory
server using ldapaddent(1M) unless the system running ldapaddent,
has first been configured for LDAP naming. This implies that the
Initial state of the network repository must be empty, and the
client using the repository must be configured to use the empty
repository before the repository can be loaded with data from an
existing repository (i.e., existing NIS data).
ldaplist(1) has same limitation. You can not query a repository
to see if it has naming data unless your client is configured to
use that naming data. This is a serious administration design flaw
and approachability issue in LDAP naming today.
[2] The tool used to initialize the client machine ldapclient(1M)
has no provision to specify authentication credentials or
credential type when initializing a client. This forces all
directory servers to support open (port 389 with no security)
binds to the directory server to initialize clients. Customers
that want to secure a directory server to use only TLS/SSL
for all access to the directory server are unable to do so.
[3] Related to [2], ldap_cachemgr(1M) currently requires anonymous
(open port 389) non-TLS access to the RootDSE of any directory
server even if other access is specified as TLS/SSL.
[4] Users wishing to use TLS/SSL are required to use port 636 (the
default LDAP TLS/SSL port). Even though LDAP servers typically
allow other ports to be specified, the current implementation only
supports port 636.
[Note: The standard method for using TLS with LDAP ("StartTLS")
is not supported by Solaris' libldap5.so. More on this
below.]
SOLUTION
========
To address problems [1] and [2], ldapclient(1M), ldapaddent(1M) and
ldaplist(1) will be updated to support a common set of command line
options that are both consistent amongst all three programs and also
consistent with the other LDAP tool interfaces delivered by the Solaris
and directory server product lines. [I.e., the ldapsearch(1),
ldapadd(1), ldapdelete(1), ldapmodify(1), ldapmodrdn(1) command line
APIs].
The following command line options to be supported are:
-h LDAP_server[:serverPort] An address (or a name) and a port
of the LDAP server in which the
entries will be stored. The
current naming service specified
in the nsswitch.conf file is
used. The default value for the
port is 389, except when TLS is
specified in the authentication
method. In this case, the default
LDAP server port number is 636.
-M domainName The name of a domain served by
the specified server. If not
specified, the default domain
name will be used. This is used
to derive a base DN for searches.
-N profileName Specify the DUAProfile name. A
profile with such a name is
supposed to exist on the server
specified by -h option.
Otherwise, a default DUAProfile
will be used. The default value
is default.
-P certifPath The certificate path for the
location of the certificate
database. The value is the path
where security database files
reside. This is used for TLS
support, which is specified in
the authenticationMethod and
serviceAuthen- ticationMethod
attributes. The default is
/var/ldap.
-D bindDN Specifies an entry which has read
(and write in case of
ldapaddent(1M)) permission to
appropriate part of the DIT.
-w bind_password Password to be used for
authenticating the bindDN. If
this parameter is missing, the
command will prompt for a
password. NULL passwords are not
supported in LDAP.
When you use -w bind_password to
specify the password to be used
for authentication, the password
is visible to other users of the
system by means of the ps
command, in script files or in
shell history.
If the value of "-" is supplied
as a password, the command will
prompt for a password.
-j filename Specify a file containing the
password for the bind DN or the
password for the SSL client's key
database. To protect the
password, use this option in
scripts and place the password in
a secure file. This option is
mutually exclusive of the -w opt-
ion.
Man page diffs listing which of the commands ldaplist(1),
ldapaddent(1M) and ldapclient(1M) will receive which new command
line options are provided in the materials directory.
The interface stability level of ldapaddent(1M), ldaplist(1) and
ldapclient(1M) remain Committed.
In addition to modifying the command line tools, internal enhancements
will be made to the Contracted Consolidation Private private interfaces
in the libsldap library and in ldap_cachemgr(1M) to support the new
command line options of the modified tools and to address the problems
in [3] and [4].
Enhancements to libsldap will not affect existing contracted interfaces.
All new enhancements will be considered Contracted Consolidation
private. All existing contracts with libsldap will remain in effect.
The specific enhancements are provided in the revised libsldap API
document and provided in the case materials for reference.
Currently libldap.so.5, the default libldap in Solaris, lacks the
necessary ldap TLS APIs, that allow a TLS session to be enabled after a
unsecured LDAP connection has been made (START-TLS).
These APIs will be delivered when the current Mozilla libldap,
libldap.so.6, currently delivered by the directory server team
(Directory Server 6 [WSARC/2005/285] and later) is integrated into
Solaris, replacing libldap.so.5.
A future project will address this limitation once the new TLS APIs from
libldap.so.6 are available.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ONNV
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
