I've installed 5.1 beta2 but I'm still in trouble
with pam_ldap / nss_ldap
the scenario is the following
if in any file of the pam.d directory I replace
the original line :
auth required pam_unix.so no_warn try_first_pass nullok
by the following
auth sufficient /usr/local/lib/pam_ldap.so
for example in the /etc/pam.d/su file I can perform the "su -"
command WITHOUT TYPING ANY PASSWORD from a normal user login.
Do I missunderstand pam concepts or is it a real bug ?
LDAP related packages installed are
openldap-2.0.25_3
nss_ldap-1.204_1
pam_ldap-1.6.1
Thanks for any infos
--
Frank Bonnet
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Don't replace the line, add it before pam_unix.so. Having the last auth
line be sufficient causes weird behavior. If you feel like you need to
*replace* pam_unix (which is a *really* bad idea), make it required, not
sufficient. I would recommend something like this:
...
auth sufficient /usr/local/lib/pam_ldap.so
auth required pam_unix.so no_warn try_first_pass nullok
> Do I missunderstand pam concepts or is it a real bug ?
I think you might be missing a concept or two. In any event this is not
really a bug.
-gordon
If pam_ldap is the last line, it should be "required", not
"sufficient"; alternatively it should be followed by pam_deny. This
is (imperfectly) documented in /etc/pam.d/README:
Note that having a "sufficient" module as the last entry for a
particular service and module type may result in surprising behaviour.
To get the intended semantics, add a "required" entry listing the
pam_deny module at the end of the chain.
Solaris introduced the "binding" flag to try to alleviate this
problem. OpenPAM supports "binding", but does not document it
anywhere.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
Do you think it might be a good idea to turn all the pam configuration
files to list actual providers at sufficient followed by a pam_deny:
auth sufficient pam_krb5.so
auth sufficient pam_ldap.so
auth sufficient pam_unix.so
auth required pam_deny.so
This makes it very explicit as to what's going on and makes it so the
last entry isn't different merely because it's last.
> Solaris introduced the "binding" flag to try to alleviate this
> problem. OpenPAM supports "binding", but does not document it
> anywhere.
I'm unfamiliar with this option. What's it do?
-gordon
No. I'd rather replace "sufficient" with "binding" where appropriate.
> > Solaris introduced the "binding" flag to try to alleviate this
> > problem. OpenPAM supports "binding", but does not document it
> > anywhere.
> I'm unfamiliar with this option. What's it do?
It behaves like "sufficient" should, i.e. failure is not ignored. I'm
working on updating the documentation.
--
Ruslan Ermilov Sysadmin and DBA,
r...@sunbay.com Sunbay Software AG,
r...@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
I don't understand the question.
Cheers,
Failure of a "binding" module causes the entire chain to fail once it
has completed. The error returned is that returned by the first
non-"optional", non-"sufficient" module that failed.
Failure of a "sufficient" module, on the other hand, is always ignored
(so if no other non-"optional", non-"sufficient" module failed, the
chain will succeed). This is what constantly surprises users, and
what "binding" was introduced to alleviate.
See the PAM article for details - particularly the following two
sections:
http://www.freebsd.org/doc/en/articles/pam/pam-essentials.html#PAM-CHAINS-POLICIES
http://www.freebsd.org/doc/en/articles/pam/pam-config.html#PAM-POLICIES
And I have the following question for you:
Why pam_nologin in the "auth" chain of the "login" service is marked
"required" and not "requisite", and why do we have the "required" at
all? What's the point in continuing with the chain if we are going
to return the failure anyway? What's the real application of
"required" as compared to "requisite"?
Information leak. The applicant screwed up, but we don't want to let
him know that until he's jumped through all the *other* hoops as well;
otherwise he might learn something about our authentication setup from
the premature error message.
hmm
I think you're right - in the nologin case, information leak isn't an
issue. We should change it to requisite. I need to go through the
policies and change "sufficient" to "binding" anyway, so I'll take
care of it once the freeze lifts.