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

Re: problem with PAM and LDAP



On Wed, 22 Aug 2001, Russell Coker wrote:

> We have pam_min_uid and pam_max_uid settings in /etc/pam_ldap.conf for the
> obvious reasons.

> Anyone who uses libpam-ldap needs to use libnss-ldap so that "ls -l" can show
> the owners of files that were created from LDAP logins.

> Now the problem is that the presense of libpam-ldap circumvents the
> pam_min_uid setting.  This is because the pam_min_uid value is checked in the
> "account" section of PAM not the "auth" section.  It's mandatory to have PAM
> setup to use pam_unix.so (for root logins when LDAP is broken).  This means
> that if you have pam_min_uid then the system will just use the "account"
> section from pam_unix.so disregarding the failure of "account" in pam_ldap.so.

A suggestion would be to map return value PAM_USER_UNKNOWN to an 'ignore' in
the account block, like so:

account		[user_unknown=ignore success=ok default=bad]	pam_ldap.so
account		required					pam_unix.so

This should (if I've gotten the syntax right) let you ignore pam_ldap for
users that don't have LDAP information.  pam_ldap may return a different error
code in the event of an LDAP timeout, in which case you would also want to
include it here as an 'ignore'; I haven't looked at the source.

> So my question is, is this a bug in libpam-ldap that should be fixed by
> moving it to the "auth" section?  Or is there something in PAM setup that I
> should change to solve this?  Or should it be checked in both "auth" and
> "account"?

Although there's some division on this question among PAM developers, it's my
feeling that the 'auth' block should be used /only/ for authentication
checks, and that authorization checks (such as uid comparisons) belong in the
'account' block.  However,

> Also as a further complication, I want to have pam_unix.so listed before
> pam_ldap.so so that if there is a network problem causing LDAP timeouts I can
> still login as root.

I'm not sure how to reconcile these requirements.  The only possible way to
enforce LDAP uid limits in the account block when libnss-ldap is in use is to
actually call pam_ldap.  That means that if the network is down you /have/
to wait for the timeout before granting access, because pam_unix by design
can't know if the user is coming from the local password file or the LDAP
database.

One interesting possibility would be to have libnss-ldap's getspnam()
implementation always return a locked-out shadow entry.  Then
pam_unix:pam_acct_mgmt() would never succeed for LDAP users, so LDAP users
would be allowed or denied access only according to the results of the
pam_ldap authorization checks.  But there may be other reasons why people
need libnss-ldap to return valid shadow entries. <shrug>

Alternatively, you could argue that the uid check has relevance to
authentication, since the user has not truly been authenticated to the local
machine if it's bouncing against an LDAP entry that's disallowed by local
system policy.  In that case, it makes sense to do the uid checks in the auth
block.

Steve Langasek
postmodern programmer



Reply to: