[OpenAFS] Openafs Client with pam krb5 and ldap

[Douglas E. Engert]

On 10/1/2010 10:00 PM, Andy Cobaugh wrote:
> On 2010-10-01 at 19:03, Russ Allbery ( rra@stanford.edu ) said:
>>> account [default=ignore ignore=ignore success=ok] pam_krb5.so debug


If it looks like the account, may be an issue, I noticed in your
/etc/nsswitch.conf that you did not have a compat for shadow:
  passwd: compat
  group:  files ldap
  shadow: files
  passwd_compat:  ldap

We run ldap with:

  passwd_compat:  ldap
  group_compat:   ldap
  shadow_compat:  ldap
  passwd:         compat
  group:          compat
  shadow:         compat

With the appropriate + and - entries for netgroups etc.

Just a thought, it might be that a pam account is trying to check
for expired or locked accounts and since you do not have shadow using
LDAP, it can't find the account.

For the LDAP password, you can use *LK* for locked, and NP for no
password, meaning there is not password that matches, but you can
authenticate some other way, like Kerberos.


>>
>> 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.
>
> Well, I didn't put it there, so something did. I've seen that line on
> systems that were originally lenny, and systems that were upgraded to
> lenny.
>
>> account required pam_unix.so
>> account required pam_krb5.so
>
> Yep, putting exactly those lines in common-account gives 'Connection
> close by foo'. I'm fairly certain I tried every combination of requires,
> sufficient, etc to the same effect. Only thing that made it work was
> putting in a module that returns success always, like pam_permit.
>
>> 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.
>
> Well, one system was installed with lenny to begin with, and for over a
> year we would have to do GSSAPIAuthentication=no to login to it, and the
> other 2 systems were upgraded to lenny, which subsequently broke gssapi
> logins in the same manner. Putting in pam_permit on all 3 systems fixed
> them.
>
> Doesn't matter to us so much now, though. At least 2 of these systems
> will be reinstalled with RHEL6 when it comes out, and the third isn't
> used by anyone ssh'ing to it that can make use of gssapi, so...
>
> If you have any other things you want me to try, I will for the sake of
> fixing whatever the real problem is, but no other system has this
> problem, only these lone debian lenny systems.
>
> I should note that the 2 systems that were upgraded were working fine
> before they were bumped up to lenny. All 3 are running the same version
> of libpam-krb5, 3.11-4.
>
> --andy
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444