Re: NFS+krb5: Failed to create krb5 context for user with uid 0
On Feb 5, 2008, at 9:12 PM, Kevin Coffman wrote: If the Mac server code can support other encryption types like Triple DES and ArcFour, you shouldn't need to limit it to only the des-cbc-crc key. The Linux nfs-utils code on the client should be limiting the negotiated encryption type to des. I would assume if normal users are able to get a context and talk to the server, that root using the keytab should be able to do so as well. I added a principal for root/[EMAIL PROTECTED] and added it to the client's keytab and everything appears to work now. I then put the other keys back on the server's keytab as you suggested. Thanks for the help! Luke Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying, distributing or disclosing the same. - To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
NFS+krb5: Failed to create krb5 context for user with uid 0
Hello NFS List, I've been trying to set up some linux clients to work with a Mac OS X 10.5 (Leopard) server. So far I've made some good progress, but run into a few problems with Kerberized NFS. I have the ssh server on the linux client fully kerberized with ticket forwarding. I also have the users' home directories mounting from the mac server with autofs with sec=krb5. Users can log in, see their files, and everything seems to work great. The problem is that in syslog I get these errors repeatedly... Feb 5 17:31:39 myclient.domain.com rpc.gssd[8137]: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server myserver.domain.com Feb 5 17:31:39 myclient.domain.com rpc.gssd[8137]: Failed to write error downcall! It seems that whenever root wants to look at the mounted filesystem (when running df, for example), it doesn't have permission. Now I know that it's supposed to use machine credentials, and that it currently only works with des-cbc-crc:normal. I wasn't sure if that applied to the server's nfs principal as well, but I did it just to be safe. Here's what I've got in the keytabs... Client keytab: 3 nfs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 8 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 8 host/[EMAIL PROTECTED] (ArcFour with HMAC/md5) 8 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) Server keytab: 3 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 3 host/[EMAIL PROTECTED] (ArcFour with HMAC/md5) 3 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 4 nfs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) I also recreated the principals on the KDC, and specified only the one key type (des-cbc-crc:normal). Again, not sure if that was necessary or not. I can run rpc.gssd with the -n flag, and the error output changes to this... # rpc.gssd -f -n ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure. Minor code may provide more information - Unknown code krb5 195 WARNING: Failed to create krb5 context for user with uid 0 for server myserver.domain.com Failed to write error downcall! If I crank up the verbosity of the output, I get this: # rpc.gssd -f -vvv handling krb5 upcall Full hostname for 'myserver.domain.com' is 'myserver.domain.com' Full hostname for 'myclient.domain.com' is 'myclient.domain.com' Key table entry not found while getting keytab entry for 'root/ [EMAIL PROTECTED]' Success getting keytab entry for 'nfs/[EMAIL PROTECTED]' Successfully obtained machine credentials for principal 'nfs/ [EMAIL PROTECTED]' stored in ccache 'FILE:/tmp/ krb5cc_machine_DOMAIN.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAIN.COM' are good until 1202297948 using FILE:/tmp/krb5cc_machine_DOMAIN.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/ krb5cc_machine_DOMAIN.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server myserver.domain.com creating context with server [EMAIL PROTECTED] WARNING: Failed to create krb5 context for user with uid 0 for server myserver.domain.com WARNING: Failed to create krb5 context for user with uid 0 with credentials cache FILE:/tmp/krb5cc_machine_DOMAIN.COM for server myserver.domain.com WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server myserver.domain.com doing error downcall Failed to write error downcall! Can anybody give me any hints or suggestions? Thanks, Luke Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying, distributing or disclosing the same. - To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NFS+krb5: Failed to create krb5 context for user with uid 0
On Feb 5, 2008 8:51 PM, Luke Cyca [EMAIL PROTECTED] wrote: Hello NFS List, I've been trying to set up some linux clients to work with a Mac OS X 10.5 (Leopard) server. So far I've made some good progress, but run into a few problems with Kerberized NFS. I have the ssh server on the linux client fully kerberized with ticket forwarding. I also have the users' home directories mounting from the mac server with autofs with sec=krb5. Users can log in, see their files, and everything seems to work great. The problem is that in syslog I get these errors repeatedly... Feb 5 17:31:39 myclient.domain.com rpc.gssd[8137]: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server myserver.domain.com Feb 5 17:31:39 myclient.domain.com rpc.gssd[8137]: Failed to write error downcall! It seems that whenever root wants to look at the mounted filesystem (when running df, for example), it doesn't have permission. Now I know that it's supposed to use machine credentials, and that it currently only works with des-cbc-crc:normal. I wasn't sure if that applied to the server's nfs principal as well, but I did it just to be safe. Here's what I've got in the keytabs... Client keytab: 3 nfs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 8 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 8 host/[EMAIL PROTECTED] (ArcFour with HMAC/md5) 8 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) Server keytab: 3 host/[EMAIL PROTECTED] (Triple DES cbc mode with HMAC/sha1) 3 host/[EMAIL PROTECTED] (ArcFour with HMAC/md5) 3 host/[EMAIL PROTECTED] (DES cbc mode with CRC-32) 4 nfs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) I also recreated the principals on the KDC, and specified only the one key type (des-cbc-crc:normal). Again, not sure if that was necessary or not. If the Mac server code can support other encryption types like Triple DES and ArcFour, you shouldn't need to limit it to only the des-cbc-crc key. The Linux nfs-utils code on the client should be limiting the negotiated encryption type to des. I would assume if normal users are able to get a context and talk to the server, that root using the keytab should be able to do so as well. I can run rpc.gssd with the -n flag, and the error output changes to this... # rpc.gssd -f -n ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure. Minor code may provide more information - Unknown code krb5 195 WARNING: Failed to create krb5 context for user with uid 0 for server myserver.domain.com Failed to write error downcall! This looks like a Redhat distro? krb5 195 is KRB5_FCC_NOFILE With the -n flag, you have to manually get credentials for root and put them in /tmp/krb5cc_0 (or similar). If I crank up the verbosity of the output, I get this: # rpc.gssd -f -vvv handling krb5 upcall Full hostname for 'myserver.domain.com' is 'myserver.domain.com' Full hostname for 'myclient.domain.com' is 'myclient.domain.com' Key table entry not found while getting keytab entry for 'root/ [EMAIL PROTECTED]' Success getting keytab entry for 'nfs/[EMAIL PROTECTED]' Successfully obtained machine credentials for principal 'nfs/ [EMAIL PROTECTED]' stored in ccache 'FILE:/tmp/ krb5cc_machine_DOMAIN.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAIN.COM' are good until 1202297948 using FILE:/tmp/krb5cc_machine_DOMAIN.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/ krb5cc_machine_DOMAIN.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server myserver.domain.com creating context with server [EMAIL PROTECTED] WARNING: Failed to create krb5 context for user with uid 0 for server myserver.domain.com WARNING: Failed to create krb5 context for user with uid 0 with credentials cache FILE:/tmp/krb5cc_machine_DOMAIN.COM for server myserver.domain.com WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server myserver.domain.com doing error downcall Failed to write error downcall! Can anybody give me any hints or suggestions? Why this is failing, I do not know. What version of Kerberos do you have? A packet trace would be helpful. K.C. - To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
