problems with sec=krb5

[Rohit Kumar Mehta]

root at cselin12:~# klist -e -c /tmp/krb5cc_machine_AD.ENGR.UCONN.EDU
Ticket cache: FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU
Default principal: nfs/cselin12.engr.uconn.edu at AD.ENGR.UCONN.EDU

Valid starting     Expires            Service principal
03/28/07 13:11:06  03/28/07 23:11:06 
krbtgt/AD.ENGR.UCONN.EDU at AD.ENGR.UCONN.EDU
         renew until 03/29/07 13:11:06, Etype (skey, tkt): ArcFour with 
HMAC/md5, ArcFour with HMAC/md5
03/28/07 13:14:03  03/28/07 23:11:06  nfs/filesm at AD.ENGR.UCONN.EDU
         renew until 03/29/07 13:11:06, Etype (skey, tkt): DES cbc mode 
with RSA-MD5, ArcFour with HMAC/md5

Yeah I see the short name in there.

"host filesm" command fails with error "Host filesm not found: 
(NXDOMAIN)", but it does resolve properly as does 
filesm.ad.engr.uconn.edu. I did have only the short name "filesm" in my 
/etc/hosts file.  I updated it to be "filesm.ad.engr.uconn.edu" and now 
we have the correct principal (after attempting a mount):
root at cselin12:~# klist -e -c /tmp/krb5cc_machine_AD.ENGR.UCONN.EDU
Ticket cache: FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU
Default principal: nfs/cselin12.engr.uconn.edu at AD.ENGR.UCONN.EDU

Valid starting     Expires            Service principal
03/28/07 13:11:06  03/28/07 23:11:06 
krbtgt/AD.ENGR.UCONN.EDU at AD.ENGR.UCONN.EDU
         renew until 03/29/07 13:11:06, Etype (skey, tkt): ArcFour with 
HMAC/md5, ArcFour with HMAC/md5
03/28/07 13:14:03  03/28/07 23:11:06  nfs/filesm at AD.ENGR.UCONN.EDU
         renew until 03/29/07 13:11:06, Etype (skey, tkt): DES cbc mode 
with RSA-MD5, ArcFour with HMAC/md5
03/28/07 14:57:36  03/28/07 23:11:06 
nfs/filesm.ad.engr.uconn.edu at AD.ENGR.UCONN.EDU
         renew until 03/29/07 13:11:06, Etype (skey, tkt): DES cbc mode 
with RSA-MD5, ArcFour with HMAC/md5

However the mount still appears to hang now with the following written 
to daemon.log:
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: processing client list
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: processing client list
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: handling krb5 upcall
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: Using keytab file 
'/etc/krb5.keytab'
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: INFO: Credentials in CC 
'FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU' are good until 1175137866
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: using 
FILE:/tmp/krb5cc_machine_AD.ENGR.UCONN.EDU as credentials cache for 
machine creds
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: creating context using euid 0 
(save_uid 0)
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: creating tcp client for server 
filesm.ad.engr.uconn.edu
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: creating context with server 
nfs at filesm.ad.engr.uconn.edu
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: DEBUG: serialize_krb5_ctx: 
lucid version!
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: doing downcall
Mar 28 14:57:35 cselin12 rpc.gssd[3841]: Failed to write downcall!

I was able to get a kerberos capture (without a matching nfs capture)
and then another capture with both.  They are both attached.

Rohit

Kevin Coffman wrote:
> 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gssd.kdc.pcap
Type: application/octet-stream
Size: 6698 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20070328/ef45282a/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capture2.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20070328/ef45282a/attachment.tar