I'm sponsoring this fast track for Michen Chang (and the name services team).
It adds missing functionality to the use of a directory server as a
passwd(4)/shadow(4) name service database server. When nss_ldap and
client ldap were integrated they only supported the posixAccount object
class and the userPassword field from the shadowAccount object class.
This matched NIS (YP), but not files or NIS+. This case seeks to bring
parity between the files and nss_ldap functionality by supporting
the missing shadowAccount fields defined by RFC 2307bis. ldap(1) seems
to claim compliance with RFC 2307bis for all forms of use. Some similar
functionality to what this case will offer appears to be offered with
the PADL implementation on Linux.
The case requests a Committed interface stability and a patch release binding.
There are customer escalations for S10 (6715171), thus it is likely a
backport will be done.
I've set the timer for 10 Dec. 2008
Full diff marked man pages for ldapclient(1M) and passwd(1) are in the
case directory.
==============================================================================
Summary:
Due to the length and excellent detail of Michen's proposal, in addition
to the comments above, I've tried to summarized the high points:
1) All the shadowAccount fields will be supported with parity to
shadow(4) for files. Thus passwd(1) and pam_unix*(5) function
the same for users in the files or ldap repositories.
2) To provide this support a new LDAP admin identity (DN) and
password are implemented -- in the same fashion as the present
LDAP proxy identity (DN) and password. (N.B. neither are Unix
identities.)
3) The proxy identity is used for read access to public fields
(modulo bug 4904603).
4) The admin identity is used for read/write access to security
relevant fields. To prevent privilege escalation, the caller's
credentials are verified to allow for the same access to
/etc/shadow.
5) ldapclient(1M) is updated to add the admin identity and
password to the existing /var/ldap/ldap_client_cred file
and idsconfig(1M) to configure the directory server.
6) If Kerberos is used for communication with the directory server,
the admin identity is unused (and unneeded).
7) Though, not noted in the details, just as before this case,
ldap_client_cred is unchanged by upgrade. Unless explicitly
enabled (ldapclient(1M)), there is no change in functionality.
Gary..
==============================================================================
1. Introduction
1.1. Project/Component Working Name:
Full shadow support in LDAP password repository
1.2. Name of Document Author/Supplier:
Author: Michen Chang
1.3 Date:
24 November, 2008
2. Background
When Native LDAP (PSARC/1998/361 and PSARC/2000/363) introduced the
LDAP password repository into Solaris, it did not implement the
equivalent functionality of the files password repository. It only
provided the use of LDAP as a backing store for the passwd/shadow
passwd field databases, but not updating and making use of the shadow
information for account management (account valid-locked; password
expired; etc). Enhanced account management and password change in
LDAP were later implemented with (PSARC/2002/270), but were designed
to use the LDAP directory server BIND as the account authority and Sun's
directory server as the policy engine, the shadow information was
not used at all for account management. Because of this, there's
still no equivalent functionality of the files password repository
in LDAP, thus passwd(1) and pam_unix*(5).
Customers requesting this equivalent functionality can not move away
from nisplus without loss of functionality. It has lead to customers
having a mixed environment with dissatisfaction both in terms of
functionality and integration with management tools.
3. Proposal
Enable parity between the files password repository and LDAP
password repository. Enhance the Native LDAP client to update and
make use of all the LDAP shadowAccount object class attributes
(password, last change, min aging, max aging, warn period, inactive,
expiry, flag -- used for failed login counting), so that password
aging, notification, account expiry, failed login account locking,
as in files, are available, and missing options (-dluNfnwx) for the
LDAP repository will be supported by passwd(1).
4. Configuration
o The Solaris native LDAP client will be configured to enable the
shadow information updates with a new switch, enableShadowUpdate.
In addition, two new configuration parameters, adminDN and adminPasswd
need to be configured, if the client is not using the self credential
Level (enabled by PSARC/2005/133). If the self credential Level is
used, the Kerberos host principal/credential will be used in place
of the Admin DN/Password.
If this enableShadowUpdate switch is not set or OFF, the current
functionality will work as is and there will be no change of behavior.
o All the three new configuration parameters will be stored in
the existing Native LDAP client configuration file,
/var/ldap/ldap_client_cred, where the existing proxyDN and
proxyPassword parameters are stored. As is done for proxyPasswd,
the adminPassword will be encrypted with libsldap.so' own NS1
encryption algorithm before writing to the file. This file has a
permission of 400 and the owner is root. For security reason, the
adminDN and adminPasswd parameters will only be read and used within
the existing ldap_cachemgr(1M) daemon, which must run on every Native
LDAP client.
As with the proxyDN and proxyPasswd parameters, the enableShadowUpdate,
adminDN, and adminPassword are local configuration parameters, they
won't be part of the client profiles which are stored on the LDAP
server.
o The ldapclient(1M) utility will be modified to handle these three
new configuration parameters. The idsconfig(1M) tool will be
changed to help users add, and set the necessary Access Control
List for, the adminDN user.
o The Access Control List configured on the LDAP server will be:
no read/write access to the shadow information for any regular
users, only read access for the proxy (proxyDN) user, and
read/write access for the Admin user (adminDN).
5. Updating and using the shadow information
When the enableShadowUpdate switch is ON:
o nss_ldap.so will return all fields of the shadow information
when any one of the getsp* APIs are called. This is to allow the
pam_unix* modules and passwdutil.so to read and use all the
shadow fields.
o libsldap.so reads the shadow information with the configured
authentication methods and either a credential level of proxy
or self as is supported today. No changes in the lookup path.
For updates, if the credential level is proxy, the Admin
credential will be used together with the configured
name/password base authentication methods to bind to the
server. If the credential level is self and authentication method
is sasl/GSSAPI, then the Kerberos host principal will be used.
o libsldap.so within a door client process will forward any shadow
information update (via the private libsldap __ns_ldap_repAttr
API) to the ldap_cachemgr(1M) daemon, which will in turn check
the door client's euid ( == 0) or privileges ( == ALL), and then
use the libsldap.so to access the Admin DN/password to bind
and send the modify request to the LDAP server.
o For the __ns_ldap_repAttr API, a new flag, NS_LDAP_UPDATE_SHADOW,
will be introduced and used by passwdutil.so to indicate such a
shadow update. Similarly, a new service type,
NS_ADMIN_SHADOW_UPDATE, will be used by ldap_cachemgr to request
the libsldap.so running within the process to use the Admin
credential for the modify operation.
o passwdutil.so will perform the following shadow information
updates, using the Admin credential (adminDN/adminPassword)
indirectly:
- update the password and lastchg fields at the same time,
whenever the password field changes
- in support of failed login account locking, lock and unlock
the password field; increment and clear the failed login count
(the flag field in the shadow entry)
o Same as passwdutil.so, passwd(1) will be able to perform the
following shadow information updates:
- set users' password to a new one or make it locked, unlocked,
no login, and update the lastchg field at the same time.
- set the min, max, warn, inactive, expire, lstchg, and flag
fields.
o Users can not directly change their own password and any related
shadow information with their own credential. passwdutil.so and
passwd(1) will be used to perform the tasks using the Admin
credential on behalf of them. When passwd(1) is invoked by the
user, it can only change the user's password and nothing else.
6. limitation and restriction
o Since the configuration for this new feature calls for no user
read/write access to the password and all other shadow fields,
the LDAP server being used may need to be a dedicated one. It may not
be usable to serve any web, email, or other applications that require
any access to the user passwords.
o Since the configuration of pam_ldap and pam_unix conflicts with
each other, there must be no mix use of pam_ldap and pam_unix
anywhere in the same LDAP naming domain. No one system using
pam_ldap and another using pam_unix. No mix use of pam_ldap and
pam_unix on the same Native LDAP client system either.
This restriction is unlikely to be of practical impact. Sites
seem to separate policies of direct authentication to a directory
server (pam_ldap) from use of a directory server as a database for
local system authentication (pam_unix).
o Since the LDAP password repository is a network repository, the
semantics of the shadow fields will become a little different
than that of the files repository for local accounts. The LDAP
shadow information for name service accounts now applies to all
the systems in the same LDAP naming domain, and no longer is
per-system. For example, the failed login count may reach maximum
faster, if user tries to login from different system and does not
have a name service user_attr(4) entry, yet the default lockout
policy could still be local as per the LOCK_AFTER_RETRIES parameter
specified in /etc/security/policy.conf. Also, number of days of
inactivity allowed for a user will still be determined on a system
locally, as information about the last login is taken from a machine's
lastlog file. Password construction requirements are still
per-system as specified in /etc/default/passwd (pam_authtok_check(5)).
7. Risks
o Storing the Admin credential on every Native LDAP client system
could be viewed as risky. Even though it is encrypted and kept in
a file that can only read by root, the possibilty of it being
compromised or misused by any user who can assume the superuser role
is larger than keeping it only on the LDAP server. A compromised Admin
credential will allow any user to use and change other's password on
any system that support the LDAP protocol.
This risk can be mitigated by use of RBAC.
o A current weakness of the Native LDAP implementation (4904603) is
that a user can use the ldaplist(1) utility or a program making call
to the libsldap library to display other user's encrypted crypt(3c)
password. This is because the shadow database is treated like any
other naming database as a public one and accessed with the proxy
identity. This will not be fixed by this proposal but later with
another project. With the full support of the shadow information
in LDAP, in addition to user password, users can read even more
relevant shadow information.
It should be noted that NIS displays all fields in the yp database
and that 4904603 is planned to be fixed.
8. Relevant CRs and ARC cases
o 6715171 nss_ldap and passwdutil do not support all shadowAccount
attributes
o 6725038 SMC needs to support account management with LDAP scope
o 5074475 passwd aging not working with LDAP server with pam.unix.so
o 4904603 disable ldaplist to not show userpassword attribute or
just user logged in
o 4851236 pam_unix became unaccessible to shadow attributes of LDAP
user entry
o 4660019 nss_ldap.so may return non '-1' values for getspnam()
o PSARC/2005/133 Sparks: Name Service Switch 2
o PSARC/2000/363 NativeLDAP Phase II
o PSARC/1998/361 Native LDAP
9. Supporting Documents
ldapclient.1M.txt - Modified ldapclient(1M) man page
passwd.1.txt - Modified passwd(1) man page
In addition to the above, the Solaris admin guide will be updated
to document the new feature.
=============
ldapclient(1M) diffs:
NAME
ldapclient - initialize LDAP client machine or output an
LDAP client profile in LDIF format
SYNOPSIS
/usr/sbin/ldapclient
+ [-a enableShadowUpdate=true or false]
+ [-a adminDN=adminDN]
+ [-a adminPassword=adminPassword]
+ [-j passwdFile] [-y passwdFile]
+ [-z adminrPasswdFile] LDAP_server[:port_number]
DESCRIPTION
The ldapclient utility can be used to:
o initialize LDAP client machines
o restore the network service environment on LDAP
clients
o list the contents of the LDAP client cache in human
readable format.
Regardless of which method is used for initialization, if a
client is to be configured to use a proxy credentialLevel,
proxy credentials must be provided using -a proxyDN=proxyDN
and -a proxyPassword=proxyPassword options. However, if -a
proxyPassword=proxyPassword is not specified, ldapclient
will prompt for it. Note that NULL passwords are not allowed
in LDAP. If a self credentialLevel is configured, authenti-
cationMethod must be sasl/GSSAPI.
+ Similarly, if a client is to be configured to enable shadow
+ information update and use a proxy credentialLevel, administrator
+ credentials must be provided using -a adminDN=adminDN and
+ -a adminPassword=adminPassword. However, shadow information update
+ does not need the administrator credentials if a self credentialLevel
+ is configured.
The list form of the ldapclient utility is used to list the
LDAP client configuration. The output will be human read-
able. LDAP configuration files are not guaranteed to be
| human readable. Note that for security reason, the value of
+ adminDN and adminPassword will not be displayed.
The genprofile option is used to write an LDIF formatted
configuration profile based on the attributes specified on
the command line to standard output. This profile can then
be loaded into an LDAP server to be used as the client pro-
file, which can be downloaded by means of the ldapclient
init command. Loading the LDIF formatted profile to the
directory server can be done through ldapadd(1), or through
any server specific import tool. Note that the attributes
+ proxyDN, proxyPassword, certificatePath, domainName,
+ enableShadowUpdate, adminDN, and adminPassword are not part
+ of the configuration profile and thus are not permitted.
To access the information stored in the directory, clients
can either authenticate to the directory, or use an unau-
thenticated connection. The LDAP client is configured to
have a credential level of either anonymous or proxy. In the
first case, the client does not authenticate to the direc-
tory. In the second case, client authenticates to the direc-
+ tory using a proxy identity for read access, and using a
+ administrator identity for write access if enableShadowUpdate
+ is configured. In the third case, client
authenticates to the directory using a Kerberos principal
that is mapped to an LDAP identity by the LDAP server. Refer
to the chapter on implementing security in the Sun ONE
Directory Server Administration Guide or your appropriate
directory server documentation for identity mapping details.
If a client is configured to use an identity, you can con-
figure which authentication method the client will use. The
LDAP client supports the following authentication methods:
none
simple
sasl/CRAM-MD5
sasl/DIGEST-MD5
sasl/GSSAPI
tls:simple
tls:sasl/CRAM-MD5
tls:sasl/DIGEST-MD5
Attributes
The following attributes are supported:
+ adminDN
+ Specify the Bind Distinguished Name for the administrator
+ identity which is used for shadow information update.
+ This option is required if the credential level is
+ proxy, and enableShadowUpdate is set to true. There is no
+ default value.
+ adminPassword
+ Specify the administrator password. This option is required
+ if the credential level is proxy, and enableShadowUpdate
+ is set to true. There is no default value.
credentialLevel
Specify the credential level the client should use to
contact the directory. The credential levels supported
are either anonymous or proxy. If a proxy credential
level is specified, then the authenticationMethod attri-
bute must be specified to determine the authentication
mechanism. Further, if the credential level is proxy and
at least one of the authentication methods require a
bind DN, the proxyDN and proxyPassword attribute values
+ must be set. In addition, if enableShadowUpdate is set
+ to true, the adminDN and adminPassword values
must be set. If a self credential level is specified,
the authenticationMethod must be sasl/GSSAPI.
+ enableShadowUpdate=true | false
+ Specify whether the client is allowed to update shadow
+ information. if set to true and the credential level is
+ proxy, adminDN and adminPassword must be specified.
OPTIONS
The following options are supported:
+ -z adminrPasswdFile
+ Specify a file containing the password for the adminDN.
+ To protect the password, use this option in scripts and
+ place the password in a secure file. This option is
+ mutually exclusive of the -a adminPassword option.
===================
passwd(1) diffs:
NAME
passwd - change login password and password attributes
SYNOPSIS
+ passwd [-r ldap] -s [-a]
+ passwd [-r ldap] -s [name]
+ passwd -r ldap [-d | -l | -u | -N] [-f] [-n min] [-w warn]
+ [-x max] name
DESCRIPTION
The passwd command changes the password or lists password
attributes associated with the user's login name. Addition-
ally, privileged users can use passwd to install or change
passwords and attributes associated with any login name.
If all requirements are met, by default, the passwd command
consults /etc/nsswitch.conf to determine in which reposi-
tories to perform password update. It searches the passwd
and passwd_compat entries. The sources (repositories) asso-
ciated with these entries are updated. However, the password
update configurations supported are limited to the following
cases. Failure to comply with the configurations prevents
users from logging onto the system. The password update con-
figurations are:
o passwd: files ldap
o passwd: compat (==> files ldap)
passwd_compat: ldap
Network administrators, who own the NIS+ password table, can
+ change any password attributes. The administrator configured
+ for updating LDAP shadow information, can also change any
+ password attributes. See ldapclient(1M).
When a user has a password stored in one of the name ser-
vices as well as a local files entry, the passwd command
updates both. It is possible to have different passwords in
the name service and local files entry. Use passwd -r to
change a specific password repository.
In the files case, super-users (for instance, real and
effective uid equal to 0, see id(1M) and su(1M)) can change
any password. Hence, passwd does not prompt privileged users
for the old password. Privileged users are not forced to
comply with password aging and password construction
requirements. A privileged user can create a null password
by entering a carriage return in response to the prompt for
a new password. (This differs from passwd -d because the
password prompt is still displayed.) If NIS is in effect,
superuser on the root master can change any password without
being prompted for the old NIS passwd, and is not forced to
+ comply with password construction requirements. If LDAP is in
+ effect, superuser on any Native LDAP client system can change
+ any password without being prompted for the old LDAP passwd,
+ and is not forced to comply with password construction
+ requirements.
OPTIONS
The following options are supported:
-a Shows password attributes for all entries.
Use only with the -s option. name must not
be provided. For the nisplus repository,
this shows only the entries in the NIS+
password table in the local domain that the
invoker is authorized to read. For the
+ files and ldap repository, this is restricted to the
superuser.
-s name Shows password attributes for the login
name. For the nisplus repository, this
+ works for everyone. However for the files and ldap
repository, this only works for the
superuser. It does not work at all for the
nis repository which does not support pass-
word aging.
Privileged User Options
Only a privileged user can use the following options:
-d Deletes password for name and unlocks the
account. The login name is not prompted for pass-
+ word. It is only applicable to the files and ldap reposi-
tory.
NOTES
| Changing a password in the files and ldap repository clears the
failed login count.
