Re: pam_ldap + no_warn + pam_authz_search = issue?

[Lawrence Stewart <lstewart [at] room52.net>]

Hi Arthur,

On 10/27/12 00:09, Arthur de Jong wrote:
> On Fri, 2012-10-26 at 18:07 +1100, Lawrence Stewart wrote:
>> Is having the no_warn option with a pam_ldap.so account entry
>> expected to make that entry effectively a nop as far as the PAM
>> stack is concerned?
> 
> The no_warn option should only affect the error messages that get 
> reported back to the PAM application (and the user) with pam_error()
> and shouldn't affect the result of the PAM operation as such (the
> ingore_* options should only do this).

Ok good, thanks for confirming what I thought should be the case.

>> root@newtcphub:/root # grep account /etc/pam.d/sshd # account 
>> account         required        pam_nologin.so #account
>> required        pam_krb5.so account         required
>> pam_login_access.so account         sufficient
>> /usr/local/lib/pam_ldap.so account         required
>> pam_unix.so
> 
> The above would just mean that the result of pam_ldap is skipped if
> it fails and pam_unix is tried instead.

That's the behaviour I'm after.

> Whether pam_unix succeeds or fails for LDAP users in such a set-up is
> very dependant on the NSS side of things (at least on Linux, I can't
> say I know all the details of FreeBSD's pam_unix).

Ok.

> It is probably better to use something like the following:
> 
> account required pam_ldap.so ignore_unknown_user
> 
> Another option is to do something like:
> 
> account [success=ok new_authtok_reqd=done ignore=ignore
> user_unknown=ignore authinfo_unavail=ignore default=bad] pam_ldap.so
> 
> Also, you might consider adding ignore_authinfo_unavail to keep the 
> system accessible if the LDAP server is unavailable (also for the
> auth phase).

I normally run with ignore_unknown_user and ignore_authinfo_unavail, but
removed all options during debugging to derive the simplest
configuration which demonstrates the problem.

> Another nice one to speed things up in case of networking problems is
> minimum_uid.

I saw this recommendation during my research and the issue with it is
that I like to have a root account in ldap as well as local root on the
box and allow either password to effect a login. I believe setting
minimum_uid would stop this from working given that root's uid is 0.
Could be useful to add another option "exempt_uids" which takes a CSV
list of uids to also skip pam_ldap.so checks for? Could then have
"minimum_uid=1000 exempt_uids=0" and get the best of both worlds.

> If the authorisation step doesn't fail if the message is presented
> to the user it could be that FreeBSD's PAM implementation (or SSH) 
> interprets any error messages shown as a PAM stack failure.

Failing open because of a perceived stack failure seems like a bad idea
to me. I'll investigate the FreeBSD side of things and report back if I
find anything useful.

Thanks for the help.

Cheers,
Lawrence
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/