[OpenAFS] Openafs Client with pam krb5 and ldap
Russ Allbery
rra@stanford.edu
Fri, 01 Oct 2010 19:03:34 -0700
Andy Cobaugh <phalenor@gmail.com> writes:
> Oct 1 13:10:59 apollo sshd[25718]: (pam_krb5): none: pam_sm_acct_mgmt: entry (0x0)
> Oct 1 13:10:59 apollo sshd[25718]: (pam_krb5): none: skipping non-Kerberos login
> Oct 1 13:10:59 apollo sshd[25718]: (pam_krb5): none: pam_sm_acct_mgmt: exit (failure)
Yeah, that's normal; it's a logging bug that causes PAM_IGNORE to be
logged as failure even if it's actually returning ignore. It was fixed in
a later version, but it's just cosmetic.
> So we add in pam_krb5 in system-account like this, which appears to be the
> default entry added when pam-krb5 is installed:
> account [default=ignore ignore=ignore success=ok] pam_krb5.so debug
That doesn't look like anything that would ever be generated by default
and it isn't in the docs. I wonder if that's causing your problem. PAM
stacks can sometimes do really strange things if you set ignore as the
action and it's the last module in the stack.
For the pam_krb5 in Debian lenny, the correct entry is simply:
account required pam_krb5.so
(possibly with a minimum_uid setting if you want one, although it
shouldn't matter).
> Only way to make it work is to add in pam_permit.
Debian lenny systems, with ssh, using GSSAPI successfully:
# /etc/pam.d/common-account -- Authorization settings common to all services.
# $Id: common-account 7006 2008-04-10 22:22:47Z tskirvin $
#
# This file is included from other service-specific PAM config files on
# Debian, and should contain a list of the authorization modules that define
# the central access policy for use on the system.
#
# Deny service to users whose accounts are expired in /etc/shadow and check
# krb5_kuserok for logins via Kerberos.
account required pam_unix.so
account required pam_krb5.so
Works fine; we've never had any trouble. Version 3.11-4 of libpam-krb5.
> I've seen this on every single lenny system I've installed (so, maybe
> 3?). The defaults never worked for me. common-[auth|session|password]
> are all stock otherwise, and /etc/pam.d/sshd directly includes all for
> common-* files.
I have to assume there's something really screwy with how something on
your systems is set up or something about the too-complex PAM
configuration isn't working properly, since this just works out of the box
with me with supposedly the same versions of everything.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>