per pam service ldap config support?

[Brian Kroth <bpkroth [at] gmail.com>]

Hi,

I've been off and on looking into migrating our existing standalone pam_ldap configs over to nslcd based pam_ldap over the years.

The one feature that I've always found missing was support for per pam service stack configuration tweaks.  Standalone pam_ldap.so allows this through a config=/path/to/alternative/conf parameter within the individual /etc/pam.d/${service} stack config.

With that one can, for instance, redirect sudo authentications to use a separate shadow copy of the user object that exists in a different ou and has a different password (ie: a sort of poor man's multi factor authentication).

Or, have sshd authn/authz some users, cups authn/authz a separate set, smtp and imap yet another, etc.  Some of these services can handle doing that via group membership, but it's less easy to do if that access control is handled through specialized attributes (in our case an acl attribute on the account).

Currently, nslcd based pam_ldap doesn't provide this sort of flexibility from what I can tell.  At best it has a sort of pam authz services attribute, but that's not nearly as flexible.

Anyways, I was wondering if it would be possible to provide this sort of configuration override support on a per pam service basis?

The two possible options I could see would be support for individual param=newvalue keywords on the pam_ldap.so stack config line, though that could get pretty messy, so a better method would be a full blown extra config=/path/to/alternative/service/config parameter that includes all the new/overrided settings from the default conf.  In both cases I think difficulties in caching and efficiency issues may come in to play (that's part of why standalone pam_ldap isn't allowed to be called more than once in the same pam stack for instance).

As a workaround, currently it's possible to divert the standalone pam_ldap.so to a new name like pam_ldap_standalone.so in the appropriate /lib/ directory and mix nslcd pam_ldap.so along with it on a per pam service stack config basis in order to get the missing functionality, however that's obviously not ideal.  For one, you lose the benefits of keeping extra libs and things that standalone pam_ldap.so brings in out of the service processes memory space and you have to workaround the local distro's package manager to get both libs there in the first place (since they generally conflict with one another).  It'd be much nicer to have per service pam ldap config support from nslcd directly.

Anyways, any thoughts would be appreciated.

Thanks,

Brian

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