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.
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.
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.