Re: Support for pam_ldap configuration

[Ted Cheng <tedcheng [at] symas.com>]

On Jul 3, 2012, at 1:24 PM, Arthur de Jong wrote:

On Mon, 2012-07-02 at 16:07 -0700, Ted Cheng wrote:

I am submitting a patch, attached, for consideration to be included in

the nss-pam-ldapd release:

Added pam_ldap configuration support with an additional

NSLCD_ACTION_PAM_CONFIG protocol call to the server.

The call takes two types of requests:

(1) NSLCD_PAM_CONFIG_INIT: request for all available configuration

   flags, returned as an integer.

(2) Request for individual config parameter value. Currently

   NSLCD_PAM_PWD_PROHIBIT_MSG is implemented, which disallows

   passwd changes when pam_password_prohibit_msg paramter is

   specified on on server side.

The pam_ldap client side changes are #ifdef'ed

NSLCD_PAM_CONFIG_SUPPORT. The OpenLDAP nssov server side

implementation is provided in server_pam_config.c for reference.

Thanks, this looks very interesting. Perhaps it is a good idea to make
it a bit more generic. I have been struggling a bit with a way to have
the PAM module query nslcd whether the root user can modify a user's
password (basically whether the rootpwmoddn and rootpwmodpw options are
set). Something like this could also be even used to pass configuration
information to the NSS module if needed.

The design is meant for generic use, i.e., the first call returns all available configuration flags,

not only the password_prohibit_msg flag, though the submitted patch only implements one.

Additional flags, e.g., NSLCD_PAM_PWDMGR_DN and NSLCD_PAM_PWDMGR_PWD,

can also be returned in the same call.

The second call is made when a client needs to retrieve the value of a specific configuration

parameter.

As to root making end-user password changes, we have done the following on the nssov side,

sync'ing up with pam_ldap:

If pwdmgr-dn and pwdmgr-pwd are configured, allow root to change end user passwords, e.g.,

# passwd testuser

New password:

Retype new password:

If pwdmgr-dn is configured, but not  pwdmgr-pwd, query pwdmgr pwd before allowing the change:

# passwd testuser

LDAP administrator password:

New password:

Retype new password:

Anyway, I have a few notes on your patch:
- why did you split the request into two parts? wouldn't it be simpler
 to just do error handling for the second request?

See above.

- the requests could probably be done in the pam_sm_chauthtok() function
 since they aren't needed for all PAM calls

- currently the enforcement check is in pam_sm_authenticate() but
 shouldn't it be in pam_sm_chauthtok() instead? I don't think this
 handles the case where the password is changed by another application
 and it could cause problems for password modification of non-LDAP
 accounts.

The idea of checking password_prohibit_msg in pam_sm_authenticate as well, specifically

for the "passwd" service, is to have a "clean" handling of the case, i.e., users will

be re-directed immediately, e.g,

 # passwd testuser
   Please change your password via www.example.com
   Permission denied

In this case, pam_ldap should be configured as the first on pam stack (auth).

Otherwise, other modules would query authentication credentials, and eventually pam

re-directs.

nssov does implement the checking in pam_pwmod() as well.

- how is this implemented in the LDAP server? is it an attribute
 somewhere or is it in the nssov configuration option? (just curious)

nssov offers a configuration parameter, i.e.,

nssov-pam-password-prohibit-message <msg>

- it doesn't gracefully handle the case where the server side (nslcd)
 doesn't implement the request; this could be an issue during upgrades
 where the client-side has been upgraded but the server hasn't been
 restarted yet

Attached is an untested patch with an alternative implementation based
on your idea. It uses a single request and only uses the result if there
was no error in getting the configuration. What do you think?

Looks good. This should handle the upgrade situations as well.

pam_ldap should deliver password-prohibit msg to the end user.

Btw, I have been playing with the idea to change the nslcd protocol but
have been putting this off due to compatibility issues (both during
upgrades and compatibility with nssov).

One issue that needs to be addressed is that integers will have to be
sent in network byte order instead of host byte order for multiarch
systems with that support mixed endianness (see
http://bugs.debian.org/659488).

Another is that I don't really like some of the small inconsistencies in
the PAM protocol. Not all request parameters are always in the same
order and I don't like passing the userdn back and forth much (nslcd
currently ignores the userdn for most requests). Also, the password
modification request doesn't really work very well with password
modification as root.

We are more than willing to sync up efforts with you.

Do you have any preference on how to handle this from the nssov side or
have any ideas on this? It is not something I want to rush into.

nssov is using nss-pam-ldapd 0.8.3. We'd like to upgrade to the version with 

the pam config features merged in. After that, we can sync up the effort and

upgrade nssov the same time as nss-pam-ldapd.

Thanks,

Ted C. Cheng

Symas Corporation

 

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/