From owner-freebsd-stable@FreeBSD.ORG Thu Nov 18 02:59:40 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 688C816A4CE for ; Thu, 18 Nov 2004 02:59:40 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 303D743D54 for ; Thu, 18 Nov 2004 02:59:40 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 265B572DD4; Wed, 17 Nov 2004 18:59:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2104C72DCB; Wed, 17 Nov 2004 18:59:40 -0800 (PST) Date: Wed, 17 Nov 2004 18:59:40 -0800 (PST) From: Doug White To: jesk In-Reply-To: <001001c4c755$2eb4b980$45fea8c0@turbofresse> Message-ID: <20041117184612.J29048@carver.gumbysoft.com> References: <2627048885E8BF7F8DCDCFD2@jesk.int.de.clara.net> <001001c4c755$2eb4b980$45fea8c0@turbofresse> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Patrick Okui cc: freebsd-stable@freebsd.org Subject: Re: Pam Authorization Problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 02:59:40 -0000 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@gumbysoft.com | www.FreeBSD.org