[Freeipa-users] Kerberized NFS with Synology NAS

Roberto Cornacchia roberto.cornacchia at gmail.com
Thu Aug 20 09:45:22 UTC 2015 

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 <abokovoy at 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150820/4a3eb385/attachment.htm>

More information about the Freeipa-users mailing list