On 21/05/2024 12.15, Djerk Geurts via FreeIPA-users wrote:
Hi all,
Judging by my online searches, I’m far from the first to ask the
question, but I’m keft with holes in my understanding of Kerberos and
how services can authenticate via Kerberos (keytab).
I’m switching from sec=sys to sec=krb5p and either way struggle with
local services which must place files on an NFS share for backup
purposes. Using sec=sys things just work but the uid/gid numbers get
matched locally and this often worked fine (when local services used
the same aid/gid. But this doesn’t scale well, so I’m looking for ways
to deal with this.
One way is to create a user in FreeIPA with the name of the service
(for example bhsvc for Nakivo backup), and then adjust the uid on the
local server to the IPA issued one, which is quick. But requires
finding any file with the old id and changing it to the new one, which
can be time consuming.
As the nfs client is a 3CX server, which don’t do well when manually
configured as 3CX treat them as appliances. (God forbid someone might
want to centrally manage these beast…); I would prefer not to change
the uid of the local system account (phonesystem) to an IPA assigned one.
What are my options?
* Despite finding how to configure gssproxy, I don’t yet understand
how a daemon running as a certain user is mapped to an SPN with
related keytab. Creating an SPN in IPA is easy, but how does the
nfs-client know that a local system account should use/fetch a
keytab for a certain SPN?
* I could just manually set the uid of the local user on the nfs
server, but while this worked with sec=sys, I don’t think this
works with sec=krb5. So an option is to revert to sec=system, but
I’d prefer not to.
The gssproxy config I created for the 3cxpbx daemon(s):
user@3cx04:~$ cat /etc/gssproxy/00-3cxpbx.conf
[service/3CXPBX]
mechs = krb5
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_3cxpbx
cred_store = client_keytab:/var/lib/gssproxy/clients/3cxpbx.keytab
cred_usage = initiate
euid = 998
gss-proxy maps an execution context to a configuration and keytab. In
your case, it maps the context by effective uid. gss-proxy then uses the
SPN of the first entry of the keytab to acquire a TGT with that keytab.
By the way, did you set the environment variable "GSS_USE_PROXY=yes" for
your daemons, too? The easiest way is to use a systemd override with
e.g. "systemctl edit yourdaemon.service", then add:
[Service]
Environment=GSS_USE_PROXY=yes
You can test the gssproxy configuration by switching to the user (sudo,
su), then running "GSS_USE_PROXY=yes ipa ping". If everything is working
correctly, then ipa CLI will automatically acquire a TGT for you. Don't
try this with kinit, it doesn't use GSS-API.
Christian
--
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security
Red Hat
GmbH,https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill