Bug 144064

Summary: Kerberos PAM login fails with Windows KDC
Product: [Fedora] Fedora Reporter: Evan Champion <evanchampion>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: mark, mattdm, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-03 22:14:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to acct.c to fix PAM account behaviour when pam_krb5 did not authenticate the user none

Description Evan Champion 2005-01-04 10:31:40 UTC
Description of problem:
I have a Windows Active Directory that I am trying to authenticate
against with either pam_krb5 or pam_winbind.  Both fail with similar
Kerberos errors, so I'll only discuss pam_krb5 for now for simplicity.
 I have followed all the instructions I can find on the subject and
the advice from various mailing lists and believe something is not
working as advertised.

I used samba with use kerberos keytab = yes to join the domain and
create /etc/krb5.keytab.  This worked fine, and kinit works fine.  I
can access fileshares via Kerberos and can use gssftp and ktelnet off
my local machine with Kerberos ticket authentication.

However, login via anything using PAM -- like ssh or gdm -- fails. 
The PAM auth section works fine, but the PAM account section fails on
the line:

account     [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_krb5.so

If I comment this line out, login proceeds fine with Kerberos ticket
authentication.

The user I am trying to login as exists in /etc/passwd and has
password set to "*" in /etc/shadow.  ~user contains a .k5login.


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

pam_krb5-2.1.2-1
krb5-devel-1.3.6-2
krb5-libs-1.3.6-2
krb5-workstation-1.3.6-2
samba-common-3.0.10-1.fc3
samba-client-3.0.10-1.fc3


How reproducible:
Always

Steps to Reproduce:
1. setup authconfig for Kerberos.
2. Use samba "net ads join" to join domain, create /etc/krb5.keytab --
works fine
3. kinit and "smbclient -k '\\server\share'" -- works fine
4. ssh localhost, login at gdm, etc. -- fails

I have removed /var/cache/samba/*, /etc/samba/*.tdb and
/etc/rb5.keytab and tried "net ads join" many times.  "net ads join";
does not report any errors (completely clean).


Actual Results:  Login via ssh with pam_krb5:

Jan  4 17:39:54 fedora sshd[8761]: Authorized to user, krb5 principal
user (krb5_kuserok)
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: configured realm
'COMPANY.COM'
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flags: forwardable
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: no ignore_afs
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: user_check
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: no krb4_convert
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: flag: warn
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: ticket lifetime: 36000
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: renewable lifetime:
36000
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: banner: Kerberos 5
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: ccache dir: /tmp
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: keytab:
/etc/krb5.keytab
Jan  4 17:39:54 fedora sshd[8761]: pam_krb5[8761]: authenticating
'user' to 'krbtgt/COMPANY.COM'
Jan  4 17:39:56 fedora sshd[8761]: pam_krb5[8761]:
krb5_get_init_creds_password(krbtgt/COMPANY.COM) returned
-1765328360 (Preauthentication failed)
Jan  4 17:39:56 fedora sshd[8761]: pam_krb5[8761]: pam_acct_mgmt
returning 7 (Authentication failure)


Expected Results:  Should succeed with system-auth as configured by
authconfig.

Additional info:

/etc/krb5.conf:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = COMPANY.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true
 default_tgs_enctypes = rc4-hmac
 default_tkt_enctypes = rc4-hmac
 permitted_enctypes = rc4-hmac

[realms]
 COMPANY.COM = {
 }

[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
   debug = true
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }


/etc/krb5.keytab:

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- -----------------
--------------------------------------------------------
  14 01/04/05 00:14:27 host/fedora.company.com
  14 01/04/05 00:14:30 cifs/fedora.company.com
  14 01/04/05 00:14:25 fedora$@COMPANY.COM
  14 01/04/05 00:14:25 FEDORA$@COMPANY.COM
  14 01/04/05 00:14:26 host/fedora
  14 01/04/05 00:14:26 host/FEDORA
  14 01/04/05 00:14:27 host/FEDORA.company.com
  14 01/04/05 00:14:28 HOST/fedora
  14 01/04/05 00:14:28 HOST/FEDORA
  14 01/04/05 00:14:29 HOST/fedora.company.com
  14 01/04/05 00:14:29 HOST/FEDORA.company.com
  14 01/04/05 00:14:29 cifs/fedora
  14 01/04/05 00:14:30 cifs/FEDORA
  14 01/04/05 00:14:31 cifs/FEDORA.company.com
  14 01/04/05 00:14:31 CIFS/fedora
  14 01/04/05 00:14:32 CIFS/FEDORA
  14 01/04/05 00:14:32 CIFS/fedora.company.com
  14 01/04/05 00:14:33 CIFS/FEDORA.company.com


/etc/samba/smb.conf:

[global]
   workgroup = COMPANYNT
   realm = COMPANY.COM
   security = ads
   use kerberos keytab = yes


/etc/pam.d/system-auth:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid
&lt; 100 quiet
account     [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_krb5.so
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok
use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_krb5.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so


~user/.k5login:

user

Comment 1 Evan Champion 2005-01-10 10:25:57 UTC
The problem is due to an IMHO invalid attempt by pam_krb5 to perform
account validation if the user was not authenticated by pam_krb5.

When using with sshd via GSSAPI, sshd performs the authentication and
.k5login account validation before passing the user off to PAM for any
additional authorization and session tasks.  pam_krb5 thus is not
called for PAM authentication.  As a result, when it gets to
performing PAM account validation, it doesn't know whether or not it
should do anything.

Not wanting to do nothing, pam_krb5 tries to determine if the user has
a Kerberos account -- the logic being that if the user has a Kerberos
account, probably that is what the user authenticated with, and
therefore pam_krb5 can go ahead and perform the account validation
tasks.  It does so by authenticating on the Kerberos server with the
user's principal but a garbage password.  This is supposed to fail
with KRB5KDC_ERR_PREAUTH_FAILED if a user has an account but has the
wrong password, but because Active Directory requires
preauthentication, when done against a Windows KDC it instead fails
with KRB5KDC_ERR_PREAUTH_FAILED.  This causes PAM account validation
to fail, and the whole user login fails.

If pam_krb5 didn't authenticate the user, then I am very confused as
to why it is attempting to authorize the user.  Not only does the
existing code make some strong assumptions about how the Kerberos
server will behave in this scenario, but it slows down login by the
time taken to do the garbage authenticate (possibly significant on the
WAN), and unnecessarily generates logon errors on both the local
system and the KDC.

I attached a proposed patch, which simply returns PAM_USER_UNKNOWN if
pam_krb5 didn't originally authenticate the user.  This allows
pam_krb5 to interoperate properly when a Kerberos-aware service
performs the authentication, it works with the existing system-auth
generated by authconfig, and is consistent with the old pam_krb5-1.3
behaviour.


Comment 2 Evan Champion 2005-01-10 10:27:45 UTC
Created attachment 109550 [details]
patch to acct.c to fix PAM account behaviour when pam_krb5 did not authenticate the user

Comment 3 Mark Bober 2005-03-15 23:11:30 UTC
Ah, this has been dogging my organization for some time now, with AD logins+NIS.

Interestingly enough, commenting out the line specified above (account    
[default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so)
also fixes the fact that the RedHat ES 4 build we have wasn't running user crontabs.

Logs looked like:

Mar 15 16:54:01 SERVERNAME crond[31156]: Authentication failure

After the change, worked like a charm. 

This also allows 'su [username]' to work again, whereas before I had to use 'ksu
[username]' to su out of root to a normal user.

This may also have been our problem with logging into dovecot's POP/IMAP, but
that test machine isn't alive anymore so I can't confirm.

Either way, it's looking to be like Evan Champion above is on the right track.




Comment 4 Matthew Miller 2006-07-10 21:57:17 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!


Comment 5 petrosyan 2008-02-03 22:14:33 UTC
Fedora Core 3 is not maintained anymore. If you can reproduce this bug in Fedora
7 or 8 please reopen this bug.