problems with sec=krb5

[Kevin Coffman]

On 3/28/07, Rohit Kumar Mehta <rohitm at engr.uconn.edu> wrote:
> I noticed there were quite a few rpc.gssd processes running so I
> rebooted, and now it appears to have made the correct
> krb5cc_machine_AD.ENGR.UCONN.EDU file.

klist -e -c /tmp/krb5cc_machine_AD.ENGR.UCONN.EDU

>
> I have the user rohitm's kerberos credentials, and he owns all the files
> in /StaffDirectories/nfs/rohitm.  rohitm is also UID 6557 in NIS, but it
> seems to be trying use the ID of root who is making the mount.  I'm not
> sure if there is some configuration problem I am missing here.

The current Linux behavior is that *ALL* accesses by root will use the
machine credentials (/tmp/krb5cc_machine_REALM) when accessing
Kerberos-mounted NFS.

> I believe I created the nfs/cselin service principal des-cbc-crc:
> root at cselin12:/etc# klist -e -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> ------------------------------------------------------------------------
>     7 host/cselin12.engr.uconn.edu at AD.ENGR.UCONN.EDU (DES cbc mode with
> RSA-MD5)
>     9 nfs/cselin12.engr.uconn.edu at AD.ENGR.UCONN.EDU (DES cbc mode with
> CRC-32)

This looks fine.

> Now one thing I might have done wrong is mapping both the
> host/cselin12.engr.uconn.edu and the nfs/cselin12.engr.uconn.edu service
> principals to the same username in the Active Directory.  I am not sure
> if that is a problem or not.

I'm not an AD expert, but I'm assuming for now that this isn't a problem.

> Right now the nfs-utils is the standard one that comes with Ubuntu
> Dapper.  It appears to be 1.0.7-3ubuntu2.
>
> Attached are the tcpdumps gssd.nfs.pcap (communications to nfs server 88
> packets) and gssd.kdc.pcap (communications to kdc 0 packets).

I couldn't find any packets in the KDC trace.  The nfs trace shows
that the service ticket in the NULL request is for
"nfs/filesm at AD.ENGR.UCONN.EDU" and the gss major status in the reply
is 458752 (0x00070000), which is GSS_S_NO_CRED.

The service ticket you should have gotten on the client should have
the fully qualified host name:
"nfs/filesm.ad.engr.uconn.edu at AD.ENGR.UCONN.EDU"

I think you showed that the server's principal was created with the
full name.  So it must be some issue with AD returning a service
ticket with this short name?  Seeing those kerberos packets might
help.  (as would the klist output from above)

Does "host filesm" on the client return the full name?  Perhaps
/etc/hosts is configured incorrectly with only the short name on the
client?

K.C.