Red Hat Bugzilla – Bug 539423
pam_krb5 requires self principal to be listed in .k5login
Last modified: 2018-11-14 13:31:04 EST
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.
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.
This is also a problem in Fedora 14, upgrading from Fedora 13.
Fedora 14 also has the k5login_authoritative setting available in krb5.conf, which is what's being backported to address this bug here.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0098.html