Pam Authorization Problem

[Doug White]

On Wed, 10 Nov 2004, jesk wrote:

> > huh? as in a user that more or less does *not* exist on your system can
> log
> > in? do you have any other authentication modules that the system falls to?
>
> Sure, authentication is enabled too, but i want to limit access through
> authorization.

Be careful, I think you are confusing authentication and authorization
here. In PAM they are distinct ideas.

> here my whole pam.d/sshd configuration:
> ---
> # auth
> auth            required        pam_nologin.so              no_warn
> auth            sufficient      pam_opie.so                    no_warn
> no_fake_prompts
> auth            requisite       pam_opieaccess.so         no_warn
> allow_local
> auth            sufficient      /usr/local/lib/pam_ldap.so no_warn
> try_first_pass
> auth            required        pam_unix.so                   no_warn
> try_first_pass
> # account
> account         required        pam_login_access.so
> account         sufficient        /usr/local/lib/pam_ldap.so
> account         required        pam_unix.so
> # session
> session         required        pam_permit.so
> # password
> password        required        pam_unix.so             no_warn
> try_first_pass
> ---
>
> when i login to the system i become the message:
> ---
> You must be a uniqueMember of cn=klever,ou=hosts,dc=xxx,dc=xxx,dc=xxx to
> login.

First of all -- be clear on where the user record exists.  Identify if
'klever' exists both in LDAP and locally, or in only one.  You will drive
yourself nuts if you don't keep this straight. I suggest creating local-
and directory-only test users when hacking on PAM.

Secondly, understand what checks happen where.  With PADL pam_ldap the
only way you can tell most of this is to read the code, sadly.  In this
case, the various access checks happen in pam_sm_acct_mgmt(), which
corresponds to 'account' in pam.conf.

Finally, the control field is really complex and its easy to make a
mistake and not react to a condition you are trying to catch.

> but exactly this is not true, then why i can login?

Because you have specified that the failure of pam_ldap is not fatal to
the account stack. The "sufficient" control means:

If this module returns success, then stop stack processing and return
success to the application. Otherwise continue processing.

Since the access check constitutes a "failure" and "sufficient"
effectively ignores failures, you've made the access checks useless. :)

You probably want to set it to "required", but there are a couple of
options to mask certain failure modes you may need to set so that you get
the proper fallback to local logins.  Those options are

ignore_unknown_user
ignore_authinfo_unavail

Add thesse to the end of the 'account ..pam_ldap' line.

If you don't want to set the options you can move it below pam_unix, but
the control must still be "required" for the appropriate action to be
taken.  Remember, you need to treat ldap failing as fatal to the stack if
you want the access controls to have any effect.

PAM is horrifically compilicated. I just spent 2 months implementing it at
my employer and getting the cases right is a bitch. In fact, its still
wrong there. :(

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite at gumbysoft.com          |  www.FreeBSD.org