[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LDAP authentication with PAM



[suggest follow-ups to pam-list@redhat.com or debian-user@l.d.o, since while I
hope this thread has been enlightening, it doesn't have much bearing on Debian
development]

On 15 Apr 2001, Brian May wrote:

> >>>>> "Steve" == Steve Langasek <vorlon@netexpress.net> writes:

>     Steve> session    [success=1 default=ok] pam_unix.so
>     Steve> session    required   pam_ldap.so

> Thanks. I think that is just what I was looking for. Errr... except I
> think you meant default=ignore, not default=ok, as OK seems to mean
> return the error.

The meanings of the special tokens are not clearly expressed in English.  Only
'die' and 'done' cause an immediate return to the application; 'bad',
'ignore', and 'ok' will all cause libpam to continue on with the next module
in the stack, and differ only in how they use the return value of the current
module.  In the case described here the differences are moot, because for any
return value of pam_unix other than PAM_SUCCESS, pam_ldap will effectively
override it.

> Ok. Now I have:

> [auth stuff removed]

> auth    required                        pam_nologin.so
> auth    [success=1 default=ignore]      pam_ldap.so
> auth    required                        pam_unix.so try_first_pass
> auth    optional                        pam_krb5.so try_first_pass
> auth    optional                        pam_group.so

Interesting.  I would be inclined to reduce the administrative complexity here
by removing one of the three databases (probably by using only pam_krb5 for
authentication and eliminating pam_ldap), but yes, this should work.

> account [success=1 default=ignore]      pam_ldap.so
> account required                        pam_unix.so
> account required                        pam_permit.so

Reduces to:

account sufficient                      pam_ldap.so
account sufficient                      pam_unix.so


> session [success=1 default=ignore]      pam_ldap.so
> session required                        pam_unix.so
> session required                        pam_permit.so

Reduces to:

session    sufficient pam_ldap.so
session    sufficient pam_permit.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv

or even to:

session    sufficient pam_permit.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so
session    optional   pam_mail.so standard noenv

in the event that pam_ldap.so's session support is a no-op.


> Notes:

> 3. I could assume that both pam_ldap and pam_unix for session are NOPs
> (and both work even with the SLAP server down), but I though this way
> would be more "future" safe.

Honestly, I can't imagine why it would ever be appropriate for pam_unix to do
anything other than 'return PAM_SUCCESS;' in the session stage.  About the
only reason for providing the session functions in pam_unix is compatibility
with Solaris config files.  With Linux-PAM this has been a no-op for years,
and it's not likely to change in the near future.

Steve Langasek
postmodern programmer



Reply to: