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

Reply via email to