Bug 508488

Summary: 2.3.5-1 update causes auth failure for OS X clients
Product: [Fedora] Fedora Reporter: Ray Gibson <booray>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: booray, nalin
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-04 18:56:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ray Gibson 2009-06-27 19:19:03 UTC
Description of problem:
Security update 2.3.5-1 released makes OS X clients unable to authenticate via Kerberos to realm hosted on OS X Server 10.5.7.

Version-Release number of selected component (if applicable):

How reproducible:
Easy, for this setup (see additional info)

Steps to Reproduce:
1. update pam_krb5 from 2.3.4-1 to 2.3.5-1
Actual results:
afpd[16606]: pam_krb5[16606]: authentication fails for 'diradmin' (diradmin@SWIRE.APPLE): Authentication failure (Cannot read password)

Expected results:
afpd[16664]: pam_krb5[16664]: authentication succeeds for 'diradmin' (diradmin@SWIRE.APPLE)

Additional info:
fedora box: Linux storage.swire.apple #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

krb5 server: Darwin server.swire.apple 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

auth        required      pam_env.so
auth        sufficient    pam_ldap.so use_first_pass
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_unix.so

account     sufficient    pam_unix.so
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_ldap.so use_authtok

session     sufficient    pam_krb5.so
session     sufficient    pam_ldap.so
session     sufficient    pam_unix.so

** Apologies if this is a configuration problem due to security tightening.  I'm still learning this stuff, but I do know that downgrading the package fixes the issue immediately.  Thanks for your time.

Comment 1 Nalin Dahyabhai 2009-06-29 17:05:23 UTC
(In reply to comment #0)
> /etc/pam.d/netatalk:
> #%PAM-1.0
> auth        required      pam_env.so
> auth        sufficient    pam_ldap.so use_first_pass
> auth        sufficient    pam_krb5.so use_first_pass
> auth        sufficient    pam_unix.so

This looks like a configuration problem.  The 'use_first_pass' argument instructs a module to not prompt for a password, but to only try to authenticate the user using a password which was prompted for and given
to libpam by a previously-called module.  In this case, pam_unix is the
only module that's being allowed to ask the user for a password, and it's
being called after pam_ldap and pam_krb5 have already had their chance.

I suspect that what you need to do instead is this:
  auth        required      pam_env.so
  auth        sufficient    pam_ldap.so
  auth        sufficient    pam_krb5.so use_first_pass
  auth        sufficient    pam_unix.so use_first_pass

I think that'll fix the problem.  Personally, I'd just move the pam_unix call first, or have netatalk use the default configuration (which among other things, is set up to never ask the network about "system" users such as root), but this should do.

Unless there's another problem, I'm tempted to mark this as closed->worksforme.

Comment 2 Ray Gibson 2009-07-01 13:40:14 UTC
Hi Nalin,

I definitely appreciate your time and comments.  Please give me an additional 24 hours to follow your suggestion before you close; I will report back success as soon as possible.  The default netatalk file didn't have krb or ldap in it, so I originally copied those lines out of another file.


Comment 3 Ray Gibson 2009-07-04 18:56:42 UTC
Worked Great.  Thanks.