[Freeipa-users] Kerberized NFS with Synology NAS

Alexander Bokovoy abokovoy at redhat.com
Thu Aug 20 09:32:34 UTC 2015 

On Thu, 20 Aug 2015, Roberto Cornacchia wrote:
>I had Synology support inspect my configuration.
>
>They said that the authorization for the mapping looks for attribute
>"GSSAuthName" in LDAP, but doesn't find it. Therefore, they fall back to
>mapping it to nobody.
>
>Does this make sense to you? Is it true that GSSAuthName attribute isn't
>there?
FreeIPA does not use UMich LDAP schema developed for NFS. Instead, as we store
Kerberos principals in LDAP, for each Kerberos principal there is always
krbPrincipalName attribute available.

But on SSSD clients we instead recommend using SSSD-based identity
mapping in /etc/idmap.conf (using sss module) as it is relying on SSSD
caching capabilities and in general is more performance efficient. For
direct use of UMich LDAP module in NFSv4 idmap you would have idmapd
module to query LDAP server on each GSSAPI connection and since there is
no state umich_ldap.so module, it will re-connect to LDAP every time
which is highly inefficient.

That's why I recommended to suggest Synology to integrate SSSD in their
OS and have real benefits in improved Kerberos/AD/LDAP/FreeIPA support.

>
>
>
>On 13 August 2015 at 16:34, Alexander Bokovoy <abokovoy at redhat.com> wrote:
>
>> 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
>>

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

More information about the Freeipa-users mailing list