Background: I am using a Debian 7 system which I have integrated with an LDAP+Kerberos system using libnss-ldap, libpam-krb5 and nscd. I have modified sudoers to permit an LDAP group the right to sudo and gain super-user privileges. Hence, I can log in as an LDAP group to manage the machine. This is all working fine, and ssh login works well with an LDAP user.
I was just experimenting with a .k5login file in the home directory of my user account, Cosmic Ossifrage. In the file, I listed:
[email protected]
which is a valid Kerberos identity. SSH logins as this user continued to work correctly with the .k5login file in place.
However, with this .k5login file in my home directory, I was no longer able to use sudo -i to gain super-user privileges. This does not seem to make any sense, since the .k5login is in my home directory, not root's, so to my mind, neither the root user, nor the sudo command, should be restricted any further than what is present in the sudoers file.
However, with the .k5login file as above in place, neither sudo -i nor sudo su were working whereas they were before. Once the .k5login file was removed, this functionality was restored and I was able to sudo again.
In the log file /var/log/auth.log, among the many error messages reported at this time was one from sudo, stating:
[pam:sudo] krb5_kuserok failed for user cosmic_ossifrage
Did I miss something fundamental in the definition of what a .k5login is supposed to do? Is this expected behaviour, and if so, why?
As per Mark's comment, the
.k5loginfile must satisfy the following requirements:as per the comments found in the Kerberos source code.
In this instance, the
.k5loginfile was not readable by anybody but theCosmic Ossifrageuser. The NFS mount on which the user's home directory was stored also enforced root squashing, prohibiting access by even the root user. By making the file world-readable,sudoto root functionality was returned.(Marking community wiki, as the answer originally came from a comment.)