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? -- Djerk Geurts > On 21 May 2024, at 12:35, Christian Heimes <[email protected]> wrote: > > 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
-- _______________________________________________ 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
