>>>>> "Steve" == Steve Langasek <vorlon@netexpress.net> writes:
Steve> And the 'A' and the 'M' say 'authentication modules', which
Steve> succinctly defines the scope of PAM. Retrieving group
Steve> lists is not an authentication problem.
OK, fair enough... However, a lot of the session management stuff has
nothing to do with authentication either:
session optional pam_motd.so # [1]
session optional pam_mail.so standard noenv # [1]
session required pam_limits.so
pam_limits is closer to initgroups than it is to authentication!
Since session management has always been part of PAM, I think it might
be a case of finding a cute acronym that fits pretty well... :-)
>> No, I want to make sure that pam_ldap is not used for authenticating
>> non-LDAP-based accounts!
Steve> Easily done:
Steve> auth sufficient pam_unix.so
Steve> auth required pam_ldap.so use_first_pass
Steve> -- and that's it. If the account is local, pam_ldap will never be
Steve> invoked with the above configuration. Likewise, list
Steve> 'files' before 'ldap' in nsswitch.conf, to give optimal
Steve> lookup times for getpwnam()/getgrgid() calls on local
Steve> accounts.
However, I started this thread using almost exactly the same example,
except for account modules. That doesn't work... :-(
Steve> The one slowdown will be with initgroups() (yes, I meant
Steve> initgroups() earlier, not getgroups()). There's no way
Steve> around that; you can lower your timeouts in nss_ldap, or
Steve> you can modify your login app to not call initgroups().
... except that the pam_unix account management does NSS calls...
Steve> Those are your only two options, unless you do choose to
Steve> modify the PAM API; and there would have to be a very good
Steve> reason for Linux-PAM to break compatibility with other PAM
Steve> implementations.
True. I believe that FreeBSD is running its own PAM implementation,
but I don't know if the API has changed...
peace & happiness,
martin
