Update on CentOS 7, Kerberos, and Active Directory.
After my initial configurations had time to bake in for a while, I discovered a lingering little problem. If the system was left to allow all a user’s Kerberos tickets to expire, using PuTTY to SSH into the machine would permit login but not pass any tokens over for the home directory mounting. This was somewhat unfortunate and at first the cause of the problem was not evident. In fact, this problem was staring me in the face as I was reviewing logs from my last post, though I didn’t see nor understand what it was trying to tell me. Oh well.
Troubleshooting the issue
I went ahead and re-added the troubleshooting debug flags to sssd so that I could get some data back on what was going on. Sadly, looking through /var/log/debug did not provide much help, except that the error below bothered me.
sshd[81535]: Accepted gssapi-with-mic for twan from 192.168.101.109 port 56853 ssh2 sshd[81535]: krb5_cc_initialize(): Permission denied
Why in the world was sshd being denied the ability to initialize the credential cache? Without that cache, everything else was going to fail with the expected inability to store tokens for the user and thus, fail to mount the home directory. A little research on this issue brought good fortune, however, as this issue relating to a Fedora OS implicated SELinux as the cause of the problem. This particular CentOS server was a fairly plain build from media to current state, so it seemed likely that SELinux, installed in an enforcing state, was causing me grief. Additional insight was provided by looking through the SELinux audit log at /var/log/audit/audit.log and this line was recorded.
type=AVC msg=audit(1540562861.227:78010): avc: denied { write } for pid=81535 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=key
Sure enough, there was the smoking gun. SSHD was being denied the ability to write (or create in this case) Kerberos tickets to the credential cache.
Writing the fix
Thankfully for me, since SELinux is the bane of my existence most days, the solution to this issue was almost painfully easy. Thanks to this RedHat article on building a selinux policy module, I was able to use the data recorded in the audit log to create a policy package file and import it into the SELinux active policy.
# ausearch -m AVC --comm sshd | audit2allow -M krb5sshd # semodule -i krb5sshd.pp
As the article states, the semodule command will persist the policy across reboots. I was able to perform a quick test after the command completed (and it did take a while to do so) and without further fuss, I was authenticated easily by my existing Kerberos ticket and my home directory was mounted. Klist also now successfully showed the necessary Kerberos tickets for me to talk to my file server.
Additional thoughts
I think the one final configuration I was hoping to achieve was a fully passwordless setup using SSH keys where I was off and remote. I really wasn’t sure that would be actually achievable. As one reply on this discussion on serverfault.com stated, you don’t use Kerberos with SSH Keys, you use it instead of. I can see why this would be the case, as you would need to supply your password in order to properly authenticate to the Kerberos realm for a ticket. A SSH key bypasses the need for a password, but it can also only be used between that SSH client and that SSH host. While the key can be reused, storing any password in such a way as to retrieve it for requesting Kerberos tickets invalidates the security of not passing your password in the first place, soo… I guess that if this method is my choice going forward, passwords will be required on connecting clients that do not support Kerberos and Kerberos single sign-on can be used for those clients that I can.
Still, I have to say this is a pretty cool and secure method by which to bind CentOS servers to AD, and one way to abandon the use of Window’s NIS solution (deprecated going forward anyway) and the need to present my file server shares using NFS.