This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 508488 - 2.3.5-1 update causes auth failure for OS X clients
2.3.5-1 update causes auth failure for OS X clients
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pam_krb5 (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-27 15:19 EDT by Ray Gibson
Modified: 2009-07-04 14:56 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-04 14:56:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ray Gibson 2009-06-27 15:19:03 EDT
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):
pam_krb5-2.3.5-1.fc11.x86_64

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 2.6.29.4-167.fc11.x86_64 #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

/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

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 13:05:23 EDT
(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 09:40:14 EDT
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.

Thanks.
Comment 3 Ray Gibson 2009-07-04 14:56:42 EDT
Worked Great.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.