Re: [Freeipa-users] Kerberized NFS with Synology NAS
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 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 >> 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 '' >> 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.C
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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 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 '' 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]: usi
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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?
On 13 August 2015 at 16:34, Alexander Bokovoy 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 ''
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]: creatin
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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
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 ''
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 ''
gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
Minor code may provide more information, No cred
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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 :(
On 12 August 2015 at 13:33, Roberto Cornacchia 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 ''
>> 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 ''
>> 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 co
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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 ''
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 ''
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 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/lis
Re: [Freeipa-users] Kerberized NFS with Synology NAS
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 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 ''
> 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 ''
> 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.
>
[Freeipa-users] Kerberized NFS with Synology NAS
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
