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
usability.
>> 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: