From owner-freebsd-stable@FreeBSD.ORG Thu Nov 18 09:05:42 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 EB18816A4CE for ; Thu, 18 Nov 2004 09:05:41 +0000 (GMT) Received: from thekla.de.clara.net (thekla.de.clara.net [212.82.225.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7300A43D2D for ; Thu, 18 Nov 2004 09:05:41 +0000 (GMT) (envelope-from jesk@killall.org) Received: from localhost.de.clara.net ([127.0.0.1] helo=localhost) by thekla.de.clara.net with esmtp (Exim 4.30; FreeBSD) id 1CUiET-0007FQ-Q3; Thu, 18 Nov 2004 10:05:37 +0100 Received: from kamikaze-studio.int.de.clara.net ([192.168.0.232]) by thekla.de.clara.net with esmtp (Exim 4.30; FreeBSD) id 1CUiET-0007FF-IW; Thu, 18 Nov 2004 10:05:37 +0100 Date: Thu, 18 Nov 2004 10:05:37 +0100 From: jesk To: Doug White , jesk Message-ID: In-Reply-To: <20041117184612.J29048@carver.gumbysoft.com> References: <2627048885E8BF7F8DCDCFD2@jesk.int.de.clara.net> <200411102021.18553.pokui@psg.com> <001001c4c755$2eb4b980$45fea8c0@turbofresse> <20041117184612.J29048@carver.gumbysoft.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Reply-To: jesk@killall.org 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 09:05:42 -0000 Hi, thanks for your reply! my goal is to authenticate through ldap and to do some specific authorization checks. for failover i have one account in /etc/passwd in case of a downtime of ldap so that its still possible to login throught local authentication. Further more i have inside of ldap.conf the following: --- # Group to enforce membership of pam_groupdn cn=klever,ou=hosts,dc=xxx,dc=xxx,dc=xxx # Group member attribute pam_member_attribute uniqueMember --- this should do authorization and should only allow to login if the account who is login in also exists in 'cn=klever,ou=hosts,dc=xxx,dc=xxx,dc=xxx' with its full DN inside the uniqueMember attribute. Authentication is already working with AUTH directive inside of /etc/pam.d/sshd. So i want to allow any user to login if in ACCOUNT the check with pam_ldap is true and the user exists also there or if the user exists inside of /etc/passwd. > 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. this is what i have done. > 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. i dont have much C knowledge so this will be very hard. > 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. :( I have all combinations tried in the ACCOUNT section but without the special attributes you have written about 'ignore_unknown_user/ignore_authinfo_unavail'. i will test them, maybe they are the only missing and required things to get this working.