6:35 p.m.
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(a)DOMAIN.COM
<mailto: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:
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 <djerk(a)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(a)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(a)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(a)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(a)IPA-HCC.TEST
>> 2 1 HTTP/server.ipa-hcc.test(a)IPA-HCC.TEST
>> 3 1 HTTP/server.ipa-hcc.test(a)IPA-HCC.TEST
>> 4 1 HTTP/server.ipa-hcc.test(a)IPA-HCC.TEST
>>
>>
>