Thanks Alexander, That's the confirmation I was looking for. Indeed the Synology guy admitted it was their limitation.
I have already made a feature request for SSSD. I guess for now I will just get it running with sec=sys. Best regards, Roberto On 20 August 2015 at 11:32, Alexander Bokovoy <aboko...@redhat.com> wrote: > 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 <aboko...@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.cornacc...@gmail.com >>>> >>>> wrote: >>>>> >>>>> >>>> Enabled verbose output for rpc.idmapd as well, and now I see: >>>> >>>>> >>>>> nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map >>>>> into domain 'hq.spinque.com' >>>>> >>>>> >>>>> On 12 August 2015 at 12:28, Roberto Cornacchia < >>>>> roberto.cornacc...@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....@hq.spinque.com while getting keytab entry for >>>>>> 'root/ >>>>>> meson.hq.spinque....@hq.spinque.com' >>>>>> rpc.gssd[3328]: No key table entry found for nfs/ >>>>>> meson.hq.spinque....@hq.spinque.com while getting keytab entry for >>>>>> 'nfs/ >>>>>> >>>>>> meson.hq.spinque....@hq.spinque.com' >>>>>> rpc.gssd[3328]: Success getting keytab entry for 'host/ >>>>>> meson.hq.spinque....@hq.spinque.com' >>>>>> rpc.gssd[3328]: Successfully obtained machine credentials for >>>>>> principal >>>>>> 'host/meson.hq.spinque....@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 >>>>>> n...@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= >>>>>> n...@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 >>>>>> n...@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= >>>>>> n...@spinque03.hq.spinque.com >>>>>> >>>>>> >>>>>> On 12 August 2015 at 02:46, Roberto Cornacchia < >>>>>> roberto.cornacc...@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 >
-- 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