Re: Support for pam_ldap configuration
[Date Prev][Date Next] [Thread Prev][Thread Next]Re: Support for pam_ldap configuration
- From: Arthur de Jong <arthur [at] arthurdejong.org>
- To: Ted Cheng <tedcheng [at] symas.com>
- Cc: nss-pam-ldapd-users <nss-pam-ldapd-users [at] lists.arthurdejong.org>, Howard Chu <hyc [at] symas.com>
- Subject: Re: Support for pam_ldap configuration
- Date: Tue, 03 Jul 2012 22:24:29 +0200
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. 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? - 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. - how is this implemented in the LDAP server? is it an attribute somewhere or is it in the nssov configuration option? (just curious) - 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? 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. 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. Thanks, -- -- arthur - arthur@arthurdejong.org - http://arthurdejong.org --
Attachment:
nss-pam-ldapd-implement-config-request.patch
Description: Text Data
-- To unsubscribe send an email to nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see http://lists.arthurdejong.org/nss-pam-ldapd-users/
- Re: memberUid mappings in AD, (continued)
- Re: memberUid mappings in AD,
steve
- Re: memberUid mappings in AD,
steve
- Re: memberUid mappings in AD, Arthur de Jong
- Support for pam_ldap configuration, Ted Cheng
- Re: Support for pam_ldap configuration, Arthur de Jong
- Re: Support for pam_ldap configuration, Ted Cheng
- Re: Support for pam_ldap configuration, Arthur de Jong
- Re: Support for pam_ldap configuration, Ted Cheng
- Re: Support for pam_ldap configuration, Arthur de Jong
- Re: memberUid mappings in AD,
steve
- Re: memberUid mappings in AD,
steve
- Prev by Date: Support for pam_ldap configuration
- Next by Date: Re: Support for pam_ldap configuration
- Previous by thread: Support for pam_ldap configuration
- Next by thread: Re: Support for pam_ldap configuration