[Freeipa-users] Problem with Kerberised NFS mount

Fri Jul 12 19:01:55 UTC 2013

I have only tried with latest centos 6 - i.e. pretty old :-(. But I doubt there is any change in recent kernels.

Hope Simo or Steve Dickson could perhaps shed some light...

But agree, this is not the best list to discuss this.
O.

Odesláno ze Samsung Mobile

-------- Původní zpráva --------
Od: "Adamson, Andy" <William.Adamson at netapp.com>
Datum:
Komu: Ondrej Valousek <ovalousek at vendavo.com>
Kopie: andrew at wasielewski.co.uk,freeipa-users at redhat.com
Předmět: Re: [Freeipa-users] Problem with Kerberised NFS mount

On Jul 12, 2013, at 2:43 PM, Ondrej Valousek <ovalousek at vendavo.com<mailto:ovalousek at vendavo.com>>
 wrote:

Just back to the Kerberized NFS. Any solution to RH bugzilla #786463 on the horizon yet?
Expiring tickets will render the whole concept unusable otherwise.

Hi

I'm looking into Kerberized NFS client issues and bugs. I'll be sure to add this to my todo list.  Do you know if anyone has tried with the latest upstream kernel?

-->Andy

Anyone?
O.

Odesláno ze Samsung Mobile

-------- Původní zpráva --------
Od: Ondrej Valousek <ovalousek at vendavo.com<mailto:ovalousek at vendavo.com>>
Datum:
Komu: andrew at wasielewski.co.uk<mailto:andrew at wasielewski.co.uk>,freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Předmět: RE: [Freeipa-users] Problem with Kerberised NFS mount

Hard to say.
In general, when dealing w/ nfs & kerberos, I would advise to:
● Upgrade to the latest fedora
● Make sure idmapper is configured and working fine
● Limit krb enctypes to 3des-cbc-crc (not sure if your kernel can handle aes keys).
Ondrej

Odesláno ze Samsung Mobile

-------- Původní zpráva --------
Od: Andrew Wasielewski <andrew at wasielewski.co.uk<mailto:andrew at wasielewski.co.uk>>
Datum:
Komu: freeipa-users at redhat.com<mailto:freeipa-users at redhat.com>
Předmět: [Freeipa-users] Problem with Kerberised NFS mount

Hello everyone,

I am setting up FreeIPA for a small home network. However I have a problem mounting NFS shares with Kerberos enables - see syslog output below.

My NFS, KDC and FreeIPA servers are all on the same host. I am running the NFS mount directly on the server, which has local firewall disabled - I get the same outcome on a remote client, but this surely eliminates any network issues.

These are my NFS exports, which are visible both locally and remotely with "showmount -e":-

[root at server ~]# exportfs -av
exporting gss/krb5:/home
exporting gss/krb5i:/home
exporting gss/krb5p:/home

The command "mount -t nfs4 -o sec=krb5 server.wasielewski.co.uk<http://server.wasielewski.co.uk>:/home /mnt/test_mnt" hangs indefinitely. However without the Kerberos export options the NFS share can be mounted both locally and remotely without problem.

I read in a post that the "serializing key with enctype 18 and size 32" entry in syslog means I am trying to use an unsupported key with AES256 encryption (I can find very little about enctype numbers though); however I appear to have an AES256 service principal:

[root at server etc]# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: list -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 2 host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> (aes256-cts-hmac-sha1-96)
2 2 host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> (aes128-cts-hmac-sha1-96)
3 2 host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> (des3-cbc-sha1)
4 2 host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:host/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> (arcfour-hmac)
5 5 nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> (aes256-cts-hmac-sha1-96)

My versions are:
Fedora 17 (kernel 3.8.13-100.fc17.x86_64)
FreeIPA 2.2.2
krb5 1.10.2
nfs-utils 1.2.6
I have read of this issue being fixed by downgrading nfs-utils to 1.2.5; however that is not possible due to conflict with systemd. Everything else appears to work OK e.g. domain login, automap etc. When I try to mount the Kerberised NFS share, *nothing* appears in /var/log/krb5kdc.log

Here is my syslog output when attempt the mount:

Jul 12 01:13:10 server rpc.gssd[31628]: dir_notify_handler: sig 37 si 0x7fffe59b94f0 data 0x7fffe59b93c0
Jul 12 01:13:10 server rpc.gssd[31628]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt48)
Jul 12 01:13:10 server rpc.gssd[31628]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
Jul 12 01:13:10 server rpc.gssd[31628]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt48)
Jul 12 01:13:10 server rpc.gssd[31628]: process_krb5_upcall: service is '<null>'
Jul 12 01:13:10 server rpc.gssd[31628]: Full hostname for 'server.wasielewski.co.uk<http://server.wasielewski.co.uk>' is 'server.wasielewski.co.uk<http://server.wasielewski.co.uk>'
Jul 12 01:13:10 server rpc.gssd[31628]: Full hostname for 'server.wasielewski.co.uk<http://server.wasielewski.co.uk>' is 'server.wasielewski.co.uk<http://server.wasielewski.co.uk>'
Jul 12 01:13:10 server rpc.gssd[31628]: No key table entry found for SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK<mailto:SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK> while getting keytab entry for 'SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK<mailto:SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK>'
Jul 12 01:13:10 server rpc.gssd[31628]: No key table entry found for root/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:root/server.wasielewski.co.uk at WASIELEWSKI.CO.UK> while getting keytab entry for 'root/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:root/server.wasielewski.co.uk at WASIELEWSKI.CO.UK>'
Jul 12 01:13:10 server rpc.gssd[31628]: Success getting keytab entry for 'nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK>'
Jul 12 01:13:10 server rpc.gssd[31628]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK' are good until 1373659035
Jul 12 01:13:10 server rpc.gssd[31628]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK' are good until 1373659035
Jul 12 01:13:10 server rpc.gssd[31628]: using FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK as credentials cache for machine creds
Jul 12 01:13:10 server rpc.gssd[31628]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK
Jul 12 01:13:10 server rpc.gssd[31628]: creating context using fsuid 0 (save_uid 0)
Jul 12 01:13:10 server rpc.gssd[31628]: creating tcp client for server server.wasielewski.co.uk<http://server.wasielewski.co.uk>
Jul 12 01:13:10 server rpc.gssd[31628]: DEBUG: port already set to 2049
Jul 12 01:13:10 server rpc.gssd[31628]: creating context with server nfs at server.wasielewski.co.uk<mailto:nfs at server.wasielewski.co.uk>
Jul 12 01:13:10 server rpc.svcgssd[32135]: leaving poll
Jul 12 01:13:10 server rpc.svcgssd[32135]: handling null request
Jul 12 01:13:10 server rpc.svcgssd[32135]: svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from the kernel
Jul 12 01:13:10 server rpc.svcgssd[32135]: sname = nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK<mailto:nfs/server.wasielewski.co.uk at WASIELEWSKI.CO.UK>
Jul 12 01:13:10 server rpc.svcgssd[32135]: DEBUG: serialize_krb5_ctx: lucid version!
Jul 12 01:13:10 server rpc.svcgssd[32135]: prepare_krb5_rfc4121_buffer: protocol 1
Jul 12 01:13:10 server rpc.svcgssd[32135]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
Jul 12 01:13:10 server rpc.svcgssd[32135]: doing downcall
Jul 12 01:13:10 server rpc.svcgssd[32135]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1373659035 (71045 from now), clnt: nfs at server.wasielewski.co.uk<mailto:nfs at server.wasielewski.co.uk>, uid: -1, gid: -1, num aux grps: 0:
Jul 12 01:13:10 server rpc.svcgssd[32135]: sending null reply
Jul 12 01:13:10 server rpc.svcgssd[32135]: writing message: \x \x6082029f06092a864886f71201020201006e82028e3082028aa003020105a10302010ea20703050020000000a3820184618201803082017ca003020105a1131b1157415349454c4557534b492e434f2e554ba22a3028a003020103a121301f1b036e66731b187365727665722e77617369656c6577736b692e636f2e756ba38201323082012ea003020112a103020105a28201200482011ccd1627a49a2911b9662144c0c43f9e64d78f4e817846f95884f3f43ea053b3954f22fb2d287d9ad0e24f88e32301d6a6f3f70d0e415b9c957e60e773b45b3a065258f1614451a258e3ce05f5c1fb889882b336223a32db10bea70dd334f22b9e1efaddd8b417994f6168d42a065e160353243de8aa53b4449a477567673212d68c241975300d12be7a756b7d4c7c75f8e5e82d84223ad592f6fec6897baa79b92e7097ecf1237f6c2c8ac2555c7c60782f51c386782eb56147e1ffcc8c4de94fba31d1e7a20f88b2ce88a9eb8059a9fe5731c22075280ec9eaf01fc81fccac841002f65d86e0b7000074b84661cb9ceed5e77ca4bdadfbe345ea41467392441ca5f202db006e019826d81d60e383427b5cd766f23b15b4e4eb8ebc1ba481ec3081e9a003020112a281e10481de69f0cdd8b94ef7123715131198824fa3c953d25f7dfea3b253df9623e44c660e7a96629eb323e5616bd7162e0ba4ec2d6037e3b3409be10410b2d3ffc0e2b1631b5dac718c3dfde170ec050bfc1dde657fcb7f35a7ef38e20477fea9d5f7e1320a77eef539455383080522686d1fbfb7bef8cb200dc8810c56e68bc25ad011aff3397781713aa8b696ec9f94843822449d1930b96530f69203840eab8d8398faf1286fde6edf7ef315489aa6621e1be8ea8375c52084895498f57183ccd0a104e7ac244a3fab12449144499a2308103e432c47d945f80e644f4df17271c0 1373588050 0 0 \x73000000 \x60819906092a864886f71201020202006f8189308186a003020105a10302010fa27a3078a003020112a271046f87a21e99d0907eadcd179fef73a8a4b38cb8180566d1f2cea453e28b7334b0648a543c3f2588a79f516f7d2238e1cca4ca5ec290b2a5d8b9d570ba47fdc20a2d36bc54928c3addba9b68867028c9adb157e487cc0951bc1270f9f1b96e643bb614589411cc923a9fbe5654beb20d85
Jul 12 01:13:10 server rpc.svcgssd[32135]: finished handling null request
Jul 12 01:13:10 server rpc.svcgssd[32135]: entering poll
Jul 12 01:13:10 server rpc.gssd[31628]: DEBUG: serialize_krb5_ctx: lucid version!
Jul 12 01:13:10 server rpc.gssd[31628]: prepare_krb5_rfc4121_buffer: protocol 1
Jul 12 01:13:10 server rpc.gssd[31628]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
Jul 12 01:13:10 server rpc.gssd[31628]: doing downcall

Any advice is much appreciated.

Andrew

_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com<mailto:Freeipa-users at redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130712/c17e1469/attachment.htm>