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*[email protected]
<mailto:3CXPBX/3cx*[email protected]>” 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:
Systemd process runs with a local system account (phonesystem/<uid below 1000>)
Gssproxy maps the local uid to an SPN and requests the ticket using a keytab
file (created using ipa-getkeytab)
NFS-server
Auth_to_local maps the SPN to a local (or IPA) user and checks file and folder
permissions using the uid and gid of the ‘local’ account.
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]
>>> 2 1 HTTP/[email protected]
>>> 3 1 HTTP/[email protected]
>>> 4 1 HTTP/[email protected]
>>>
>>>
>>
>
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
