[Freeipa-users] Kerberized NFS with Synology NAS

Thu Aug 13 14:34:57 UTC 2015

On Thu, 13 Aug 2015, Roberto Cornacchia wrote:
>After some more investigation, I feel the problem I described can be
>considered off topic, sorry about that. Initially I had the impression it
>could have been more freeIPA-related.
>It is sometimes difficult to tell whether the issue would show up
>regardless of using freeIPA or not.
>
>Should anyone be curious, these are my findings about using a Synology disk
>station for NFSv4+krb5 exports in my freeIPA domain:
>
>- Still no idea why I see all those "Unspecified GSS failure" from gssproxy
>on the client side. Google tells me that many before me have wondered about
>it. Has anyone a clue?
>
>- The NFS4+krb5 mounting works, but what I ran into is the "nobody" issue.
>NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence
>the "nobody" issue
>
>- One first problem is that I had not set the domain. My bad. Fixed and got
>one step further.
>    in idmapd.conf: Domain = hq.spinque.com
>
>- The second problem is that idmapd.conf in my synology says:
>    Method=nsswitch
>    GSS-Methods=static,synomap
>
>  No idea what "synomap" would be, but I guess GSS-Methods should be more
>like "static,nsswitch,synomap"
>  Indeed, everything works fine if I make static mappings for each LDAP
>user to a local user in Synology. But that's not how I want it.
>
>- Problem with all this is: no matter how I change these files, the next
>time I would save something from the Synology UI, these files would be
>overwritten
>
>Frustrating :(
I would only suggest you to raise the problem with Synology support and
convince them adding SSSD build and use it. SSSD has nfsidmap module
'sss' that does the right job on mapping based on what SSSD knows about
Kerberos principals and user mapping for the domain.


>
>
>
>On 12 August 2015 at 13:33, Roberto Cornacchia <roberto.cornacchia at gmail.com
>> wrote:
>
>> Enabled verbose output for rpc.idmapd as well, and now I see:
>>
>> nfsidmap[5034]: nss_getpwnam: name 'test1_l at localdomain' does not map
>> into domain 'hq.spinque.com'
>>
>>
>> On 12 August 2015 at 12:28, Roberto Cornacchia <
>> roberto.cornacchia at gmail.com> wrote:
>>
>>> I have used
>>>
>>> RPCGSSDARGS="-vvv"
>>> RPCSVCGSSDARGS="-vvv"
>>>
>>> in /etc/sysconfig/nfs , as suggested in http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html
>>>
>>> In the excerpt below, taken during the mount, meson is the client, spinque03 is the nfs server (synology).
>>>
>>> It still doesn't tell me much, perhaps I'm missing something?
>>>
>>>
>>> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
>>> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
>>> enctypes=18,17,16,23,3,1,2 '
>>> rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
>>> rpc.gssd[3328]: process_krb5_upcall: service is '<null>'
>>> rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
>>> spinque03.hq.spinque.com'
>>> rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
>>> meson.hq.spinque.com'
>>> rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while
>>> getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
>>> rpc.gssd[3328]: No key table entry found for root/
>>> meson.hq.spinque.com at HQ.SPINQUE.COM while getting keytab entry for 'root/
>>> meson.hq.spinque.com at HQ.SPINQUE.COM'
>>> rpc.gssd[3328]: No key table entry found for nfs/
>>> meson.hq.spinque.com at HQ.SPINQUE.COM while getting keytab entry for 'nfs/
>>> meson.hq.spinque.com at HQ.SPINQUE.COM'
>>> rpc.gssd[3328]: Success getting keytab entry for 'host/
>>> meson.hq.spinque.com at HQ.SPINQUE.COM'
>>> rpc.gssd[3328]: Successfully obtained machine credentials for principal
>>> 'host/meson.hq.spinque.com at HQ.SPINQUE.COM' stored in ccache 'FILE:/tmp/
>>> krb5ccmachine_HQ.SPINQUE.COM'
>>> rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/
>>> krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246
>>> rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as
>>> credentials cache for machine creds
>>> rpc.gssd[3328]: using environment variable to select krb5 ccache
>>> FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM
>>> gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
>>> Minor code may provide more information, No credentials cache found
>>> gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
>>> GSS failure.  Minor code may provide more information, No credentials cache
>>> found
>>> rpc.gssd[3328]: creating tcp client for server spinque03.hq.spinque.com
>>> rpc.gssd[3328]: DEBUG: port already set to 2049
>>> rpc.gssd[3328]: creating context with server nfs at spinque03.hq.spinque.com
>>> rpc.gssd[3328]: DEBUG: serialize_krb5_ctx: lucid version!
>>> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: protocol 1
>>> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: serializing key with enctype
>>> 18 and size 32
>>> rpc.gssd[3328]: doing downcall: lifetime_rec=86399 acceptor=
>>> nfs at spinque03.hq.spinque.com
>>> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
>>> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=1005
>>> enctypes=18,17,16,23,3,1,2 '
>>> rpc.gssd[3337]: handling krb5 upcall (nfs/clnt19)
>>> rpc.gssd[3337]: process_krb5_upcall: service is '<null>'
>>> gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
>>> Minor code may provide more information, No credentials cache found
>>> gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
>>> GSS failure.  Minor code may provide more information, No credentials cache
>>> found
>>> rpc.gssd[3337]: creating tcp client for server spinque03.hq.spinque.com
>>> rpc.gssd[3337]: DEBUG: port already set to 2049
>>> rpc.gssd[3337]: creating context with server nfs at spinque03.hq.spinque.com
>>> rpc.gssd[3337]: DEBUG: serialize_krb5_ctx: lucid version!
>>> rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: protocol 1
>>> rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: serializing key with enctype
>>> 18 and size 32
>>> rpc.gssd[3337]: doing downcall: lifetime_rec=85675 acceptor=
>>> nfs at spinque03.hq.spinque.com
>>>
>>>
>>> On 12 August 2015 at 02:46, Roberto Cornacchia <
>>> roberto.cornacchia at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am trying to use a Synology NAS station in my FreeIPA domain to host
>>>> automounted home directories (not created automatically for now).
>>>>
>>>> I got almost everything working, but I seem to have a problem with
>>>> kerberized nfs.
>>>>
>>>> The NAS logs in the LDAP domain and seems happy with the kerberos
>>>> principal that I uploaded.
>>>>
>>>>
>>>>
>>>> * If I use plain nfs4 without krb5
>>>>
>>>> - /etc/exports -
>>>> /volume1/shared_homes
>>>> 192.168.0.0/24(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
>>>>
>>>> then I can mount it and use it (it even works with automount). But only
>>>> using all_squash. Not useful:
>>>>
>>>>
>>>> * If I use krb5
>>>>
>>>> - /etc/exports -
>>>> /volume1/shared_homes
>>>> 192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=krb5,anonuid=1025,anongid=100)
>>>>
>>>> then I can kinit with an LDAP user, mount it with sec=krb5, but I get
>>>> "nobody" as file owner.
>>>>
>>>> This is done from a FC22 client, perfectly enrolled in freeIPA.
>>>>
>>>> The client's log contains several of such errors:
>>>>
>>>> gssproxy[807]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
>>>> Minor code may provide more information, No credentials cache found
>>>>
>>>>
>>>> Any tip to help me understand what the problem is?
>>>> Roberto
>>>>
>>>
>>>
>>

>-- 
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go to http://freeipa.org for more info on the project


-- 
/ Alexander Bokovoy