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

Re: LDAP authentication with PAM

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

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

hmmm. I am not subscribed to either mailing list (and if I subscribed
to every mailing list for software that I use, my already saturated
28.8kbps modem connection and limited brain processing power would get
overwhelmed). So I will reply here instead.

    Steve> 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.

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

Sorry, I think you are mistaken. if pam_unix returned an error with
the above config, then the use couldn't log in even if pam_ldap
returned success. Or is that behaviour wrong?

It is hard to tell the problem from the above case (because pam_unix
session management never fails), it is easier to tell with auth:

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

    >> 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

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

Kerberos has the problem that it won't work on a disconnected laptop
without a slave Kerberos database. The same goes for pam_ldap, too.
The difference being, if the laptop is stolen and has a Kerberos
database, then all your computers have been compromised. With a LDAP
database, the attacker must attack the crypt or MD5 passwords first
(by which stage you have already changed every-bodies password anyway;
at least for a small user base like mine).

Also pam_ldap seems to support Kerberos authentication now anyway, via
LDAP's kpasswd feature.  So the only difference seems to be that
pam_krb5 keeps the ticket, but pam_ldap doesn't.

I only use pam_unix for root logins (otherwise I can't login to fix
LDAP problems). So the only three databases I use for normal use are:
1. kerberos, 2. LDAP, 3. smbpasswd.

I don't think I could get rid of any one of these without restricting

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

    Steve> Reduces to:

    Steve> account sufficient                      pam_ldap.so
    Steve> account sufficient                      pam_unix.so

Ok. I assume if neither of this work pam_deny is implied?

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

    Steve> Reduces to:

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

No it doesn't!

For starters you forgot pam_unix, and put pam_permit instead. Both are
NOPs, but why the change? Was that a typo?

My observations have shown that sufficient means "skip all future
operations if this one succeeds." So for the above case if pam_ldap
succeeds, it skips pam_lastlog, pam_motd, and pam_mail.

So if I log in (yes, I tested this) using ldap, then I don't get the
MOTD displayed.

    Steve> or even to:

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

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

Perhaps you meant required, not sufficient?

Brian May <bam@debian.org>

Reply to: