Comment 4 for bug 236830

Sorry, I'm afraid this bug is going to become something of a dumping ground for my investigations; this is getting complicated enough that I need somewhere to keep track of all the bits and pieces needed to get this working (...almost).

Software needed:
 - 2.6.24 kernel with the CONFIG_CIFS_EXPERIMENTAL and CONFIG_CIFS_UPCALL options set
 - backported cifs.spnego upcall helper from samba 3.2
 - keyutils package (from universe)

Install the cifs.spnego helper as /usr/sbin/cifs.spnego, and add the following line to /etc/request-key.conf (a conffile provided by the keyutils package):

   create cifs.spnego * * /usr/sbin/cifs.spnego %k %d

Make sure that the default_realm value in /etc/krb5.conf points to your AD realm; without this, I found that the kerberos upcall would fail because it would try to retrieve the ticket via the default realm, even if you already have a TGT in the necessary realm. (This seems like a regression in MIT KRB5, I don't remember this being a problem in the past when I had correct domain_realm mappings... but chances are, anyone who was already using smbmount w/ Kerberos has already dealt with this problem, I guess?)

Run kinit without KRB5CCNAME set (because the kernel upcall can't set a different ccache using an environmental variable) to request credentials for your AD realm:

$ kinit ubuntu
Password for <email address hidden>:
$

Then run the mount.cifs command, specifying username=, sec=, and 'guest' options (the misnamed 'guest' option being the way to tell mount.cifs not to prompt for a password):

$ mount.cifs //win2003.canonical.local/ubuntu /tmp/testmount -ousername=ubuntu,sec=krb5i,guest
$

Following these steps, I'm able to successfully mount a share using kerberos authentication in the cifs driver.