+++ This bug was initially created as a clone of Bug #539423 +++ Description of problem: Customer is using Kerberos + ldap (AD) for authentication and authorization. They use the .k5login feature of kerberos for users to share privileges. It is by design that kerberos requires the principal sharing privileges to include his own principal name in the .k5login file if he wants to access his own resources. The customer feels that this behaviour is not correct. The only use case where a user should be denied after presenting correct credentials is when a krb5 principal is to be specifically disallowed from logging in to a machine. Today, this is possible in a number of ways especially since PAM is used by all other unices like AIX, Solaris, HP-UX etc in addition to Linux. So the design use-case has been clearly surpassed by other developments. There is no reason why the ~/.k5login should be checked at all if the correct credentials are presented. To disallow specific users, other more general methods like pam are available. Version-Release number of selected component (if applicable): pam_krb5-2.2.14-10 How reproducible: Always Steps to Reproduce: 1. Set up a krb5 server 2. Set up a RHEL5 system that authenticates users using pam_krb5. 3. For a test user, create the .k5login file. Make sure root can read this file - sshd reads this file as root. 4. Try sshing in as the test user - login will fail. 5. Add user's principal to .k5login, login will succeed. Actual results: Login does not succeed unless users principal is added to .k5login file. Expected results: Login should succeed even when users principal is absent from .k5login file. Additional info: The customers use case also involves users home directories on NFS. If the home directory is shared root_squashed, ssh cannot read the .k5login file, in which case login succeeds. If ssh (root) can read .k5login, the user is not allowed to login. --- Additional comment from nalin on 2010-04-01 12:16:29 EDT --- The root-squashing case is fixed in a later release (pam_krb5 drops the user's UID and creates a temporary ccache to hold the credentials for the sake of rpc.gssd, obtaining tokens if AFS is in play). We can backport that and the recently-introduced configuration option to disable the checking of .k5login, but the behavior of the check itself is part of a libkrb5 API which I don't expect to change. --- Additional comment from amessina on 2010-11-05 15:48:13 EDT --- This is also a problem in Fedora 14, upgrading from Fedora 13. My issue is using saslauthd for Postfix and Cyrus-IMAPd (with PLAIN and GSSAPI login enabled in both). The saslauthd/pam/pam_krb5 setup that has worked in F8-F13 no longer allows those users who use the PLAIN method to login. However, those using the GSSAPI (Kerberos) method can login without issue. For example, my BlackBerry suing LogicMail can no longer login. This used to work in F13. My saslauthd is setup to use PAM. From an attempt on the BlackBerry: Nov 5 16:44:54 chicago unix_chkpwd[1893]: password check failed for user (amessina) Nov 5 16:44:54 chicago saslauthd[1238]: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=amessina Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: debug Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flags: Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no ignore_afs Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no null_afs Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: user_check Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no krb4_convert Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: krb4_convert_524 Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: krb4_use_as_req Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: will try previously set password first Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: will let libkrb5 ask questions Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no use_shmem Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no external Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: no multiple_ccaches Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: flag: warn Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: ticket lifetime: default Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: renewable lifetime: default Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: banner: Kerberos 5 Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: ccache dir: /tmp Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: ccname template: FILE:%d/krb5cc_%U_XXXXXX Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: keytab: FILE:/etc/krb5.keytab Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: token strategy: v4,524,2b,rxk5 Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: called to authenticate 'amessina', realm 'MESSINET.COM' Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: authenticating 'amessina' Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: trying previously-entered password for 'amessina', allowing libkrb5 to prompt for more Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: authenticating 'amessina' to 'krbtgt/MESSINET.COM' Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: krb5_get_init_creds_password(krbtgt/MESSINET.COM) returned 0 (Success) Nov 5 16:44:54 chicago saslauthd[1238]: pam_krb5[1238]: got result 0 (Success) Nov 5 16:44:54 chicago saslauthd[1894]: pam_krb5[1894]: saving v5 credentials to 'MEMORY:_pam_krb5_tmp_s_amessina' for internal use Nov 5 16:44:55 chicago saslauthd[1894]: pam_krb5[1894]: copied credentials from "MEMORY:_pam_krb5_tmp_s_amessina" to "FILE:/tmp/krb5cc_500_D2738h" for the user, destroying "MEMORY:_pam_krb5_tmp_s_amessina" Nov 5 16:44:55 chicago saslauthd[1894]: pam_krb5[1894]: created v5 ccache 'FILE:/tmp/krb5cc_500_oY8KCl' for 'amessina' Nov 5 16:44:55 chicago saslauthd[1894]: pam_krb5[1894]: krb5_kuserok() says 0 Nov 5 16:44:55 chicago saslauthd[1894]: pam_krb5[1894]: removing ccache 'FILE:/tmp/krb5cc_500_oY8KCl' Nov 5 16:44:55 chicago saslauthd[1894]: pam_krb5[1894]: destroyed ccache 'FILE:/tmp/krb5cc_500_oY8KCl' Nov 5 16:44:55 chicago saslauthd[1238]: pam_krb5[1238]: account checks fail for 'amessina': user disallowed by .k5login file for 'amessina' Nov 5 16:44:55 chicago saslauthd[1238]: pam_krb5[1238]: authentication fails for 'amessina' (amessina): Permission denied (Success) Nov 5 16:44:55 chicago saslauthd[1238]: pam_krb5[1238]: pam_authenticate returning 6 (Permission denied) My krb5.conf on the imap/saslauthd server: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MESSINET.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] MESSINET.COM = { admin_server = ds.messinet.com kdc = ds.messinet.com } [domain_realm] .messinet.com = MESSINET.COM messinet.com = MESSINET.COM [appdefaults] debug = true My PAM password-auth (referred to from imap in /etc/pam.d) #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so
The issue will be addressed in Kerberos 1.9. We plan to put it into rawhide and Fedora 15. There is no plan to port it back to Fedora 14.
I think we pulled this in when we backported it to f15 at the time and (later?) rebased the f14 branch to match it. So this should actually be fixed in the current f14 update. Marking closed->currentrelease.