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
--
Thanks,
Djerk Geurts
--
_______________________________________________
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
