Answering my own final queries for posterity.

Auth_to_local was the missing piece. It maps the SPN to a ‘local’ user, and I found that an NFS server will regard an IPA user as a local user for these mappings. I added the following two auth_to_local lines to the realms section in /etc/krb5.conf (only on the NFS server):

[realms]
  DOMAIN.COM = {
    pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
    pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem

    auth_to_local = RULE:[2:$1;$2](^3CXPBX;3cx.*\.domain\.com$)s/^.*$/backup_3cxpbx/
    auth_to_local = DEFAULT
  }

This maps the SPN “3CXPBX/3cx*.domain.com@DOMAIN.COM” to (IPA) user backup_3cxpbx, which enables the file permissions to be checked successfully on the server, as without it there’s no way to map the service SPN to a uid or gid.

In summary, the client systemd service username is mapped to a uid and gid on the server as follows:

NFS-client:
NFS-server

Both client and server report the file and folder permissions as per the values set on the server. So no special idmapping is done or required.

In my testing I did use ‘kinit -kt <keytab> <principal>’ to be able to browse and test the NFS share access from the client.

I guess no auth_to_local mapping is needed when using the SPN of an IPA user for the systemd service, instead of a service SPN, incidentally this user does not need to have a password set when only keytab based auth is used. As always, YMMV, but this worked for me.

Huge thanks to Christian Heimes for his pointers and insight.

On 22 May 2024, at 10:41, Djerk Geurts <djerk@maizymoo.com> wrote:

Now that I have gssproxy configured with the keytab for the service and can do an ipa ping, the next thing I need to wrap my head around is how to grant a local service access to NFS shared files. A keytab for a user doesn’t equate to file permissions, so how does the NFS server match the SPN to file permissions?

What’s the right way forward from here?

  • auth_to_local (presumably on the NFS server, to map the SPN to a ‘local’ account.
    • However, my thinking then is that if I create a user in IPA to assign file and folder ownership to, then I may as well use the SPN of this user for the service on the client, avoiding the need to map things on the NFS server.
  • idmapd

Mapping a local daemon (systemd service) to an IPA user SPN just seems to make more sense to me.

— 
Djerk Geurts

On 21 May 2024, at 17:22, Djerk Geurts <djerk@maizymoo.com> wrote:

Thank you, after creating the keytab with `ipa-getkeytab -p 3CXPBX/3cx04.domain.com -k 3cxpbx.keytab` and moving the keytab to the machine (the Debian host didn’t have ipa-getkeytab) to the right location.

The ipa ping now works:

phonesystem@3cx04:/home/user$ GSS_USE_PROXY=yes ipa ping
--------------------------------------------
IPA server version 4.11.1. API version 2.253
--------------------------------------------

Thank you for your advice!

-- 
Djerk Geurts

On 21 May 2024, at 15:17, Djerk Geurts <djerk@maizymoo.com> wrote:

Great in depth detail, I'm learning loads from you.

So, an I right in deducting that would mean the keytab is manually populated, not generated by gssproxy? Sorry, feeling like a real noob here ...

Thanks,
Djerk Geurts
On 21 May 2024, at 13:25, Christian Heimes <cheimes@redhat.com> wrote: On 21/05/2024 13.11, Djerk Geurts wrote:
Thank you, that’s really helpful, especially how to test.

For the 3CX service I do indeed need to add the GSS_USE_PROXY=yes, but
as a side note, I’ll need to work out which service needs it as there
are many daemons that make up 3CX. Anyway, this is on my todo list.

What I need to do first is create a Service Principal for this service
to use. The GSS proxy config references the local uid, but how does it
match the SPN? I guess I’m not clear on the service name as the host
and REALM parts are straight forward. Is the username used for this?
If so the SPN should be phonesystem/FQDN@REALM, as the uid is a
number, so can I assume that the local machine uses the local account
name belonging to the uid for this?
GSS-Proxy uses the power of Unix sockets. "GSS_USE_PROXY=yes" enables
the interposer library in the client. When the interposer intercepts
some GSS-API calls and forwards them to GSS-Proxy's Unix domain socket.
The proxy daemon uses getsockopt() with SO_PEERCRED to get the euid and
egid of the client from the Linux Kernel. In your case, it maps euid 998
to "service/3CXPBX" and "3cxpbx.keytab". In client keytab mode,
GSS-Proxy then uses the SPN of the first keytab slot. The keytab
contains the SPN:

# ktutil
ktutil:  rkt /var/lib/ipa/gssproxy/http.keytab
ktutil:  l
slot KVNO Principal
---- ----

   1    1 HTTP/server.ipa-hcc.test@IPA-HCC.TEST
   2    1 HTTP/server.ipa-hcc.test@IPA-HCC.TEST
   3    1 HTTP/server.ipa-hcc.test@IPA-HCC.TEST
   4    1 HTTP/server.ipa-hcc.test@IPA-HCC.TEST