Follow Up on ESX Server Integration
Published on 16 May 2006 · Filed in Explanation · 560 words (estimated 3 minutes to read)A short while ago, I published an entry discussing the integration of VMware ESX Server with Active Directory for the authentication of virtual machine management. In that entry, I noted that I had not created a keytab as part of the configuration of Kerberos authentication. I was curious as to why it worked, so I did some research. Here’s what I found.
Seeking expertise, I started a thread on the comp.protocols.kerberos Usenet group about the presence or absence of the keytab, and its impact on the operation of pam_krb5 for authentication. Based on the feedback received there, the keytab should be used to protect against a KDC spoofing attack, i.e., to verify the identity of the KDC against which pam_krb5 is attempting to authenticate and retrieve tickets. Richard E. Silverman (of “Secure Shell: The Definitive Guide” fame) stated:
pam_krb5 verifies your password against Kerberos, right? In that case, there should be a keytab, due to the issue alluded to earlier in this thread: the module should obtain a host ticket to defend against a KDC spoofing attack. If it let you in without that, perhaps there’s a “verify KDC” option that’s turned off (and ideally, should be turned on).
With that in mind, I set out to see if pam_krb5 supported just such an option. According to this pam_krb5 man page, there is a “validate” option that is supposed to force pam_krb5.so to “verify that the TGT obtained from the realm’s servers has not been spoofed. Note that the process which is performing authentication must be able to read the keytab in order for validation to be possible.”
However, even with this option set (and the permissions set on the keytab so that it is readable by any user), this validation still did not take place (as evidenced by the fact that pam_krb5 still authenticated users against Active Directory even when the keytab wasn’t present). The presence or absence of the keytab did not appear to affect the operation of pam_krb5 in any way.
Russ Alberry added this comment in the Usenet thread:
The pam_krb5 modules that I’ve used either don’t do this or only do this when the keytab is available, presumably doing a security vs. ease of deployment tradeoff.
So, apparently, even though the option is there, pam_krb5 still doesn’t perform validation of the TGT to ensure that the KDC wasn’t spoofed.
To test all of this, I used a freshly-built server running CentOS 4.3 and pam_krb5. The server was authenticating against Active Directory running on Windows Server 2003 R2, where a computer account had been created and a principal mapped to that account using ktpass.exe. The keytab generated by ktpass.exe was securely copied over to the Linux server and placed in the /etc directory as krb5.keytab. Initially, only root had any permissions on the file, but read permissions were added later to see if that affected the behavior of the Kerberos module.
The final answer still remains unknown. The man page for pam_krb5.so module indicates that the validate option should force the behavior we are seeking; but the tests that I’ve conducted so far don’t support that statement. I plan to conduct additional tests and more research to see what other information I can uncover.
In the meantime, any Kerberos experts out there are invited to add their comments to this article and share any additional information.