I've been at this as well for a while now, and managed to make it work for my NFS needs (automounting user homes with password-less logons).
Whether and how this would apply to cron or other services, I don't know yet, but presumably would/should work in a similar manner. My env: $ lsb_release -d Description: Red Hat Enterprise Linux Server release 7.3 (Maipo) $ rpm -q ipa-server ipa-server-4.4.0-14.el7_3.4.x86_64 $ ipa --version VERSION: 4.4.0, API_VERSION: 2.213 This is what worked for me in the end: 1. Create "nfs/nfsserver.dom....@dom.com" service, and add to NFS server's /etc/krb5.keytab. 2. Create IPA "servicedelegation" rule/targets, so that they look like so: $ ipa servicedelegationrule-show ipa-nfs-delegation Delegation name: ipa-nfs-delegation Allowed Target: ipa-nfs-delegation-targets Member principals: *host*/*nfsclient*.dom....@dom.com $ ipa servicedelegationtarget-show ipa-nfs-delegation-targets Delegation name: ipa-nfs-delegation-targets Member principals: *nfs*/*nfsserver*.dom....@dom.com Only niggle here is IPA CLI didn't let me add "host/..." principal to the rule, or perhaps there's a default LDAP ACI of some sort and it requires a privilege/permission to be granted. The "ipa servicedelegationrule-add-member ..." command simply says "no such entry" for "host/..." type principals. Maybe IPA folks can comment. I force added it to the delegation rule via LDAP instead using this ldif: dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com changetype: modify add: memberPrincipal memberPrincipal: host/nfsclient.dom....@dom.com The "nfs/..." principal can be added using CLI "ipa servicedelegationtarget-add-member ..." just fine. 3. Allow the "nfsclient" host to impersonate users: $ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true 4. On the "nfsclient" machine, add "impersonate = true" line in the "[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf. 5. Restart nfs/gssproxy/rpc services on client and server (it's probably just gssproxy on the client that needs a kick, but just to be sure). I was also religiously doing "sss_cache -E" for good measure, unmounting anything that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to start as cleanly before each attempt at user logon. Obv make sure the user does not have an existing/valid ticket in their own cache ("kdestroy -A" as the user), otherwise it'll just mount successfully without delegation. I think that's it, I've messed about with the config for a long time and in many places, so there's a small chance there's something else that I did and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my sssd.confs and krb5.confs on both machines, can't think of much else that I might've changed for now. So my IPA automount config now mounts users' home dirs on the "nfsclient", without any tickets or keytabs from users. There's also a "krb5_principal" option available in gssproxy.conf - I tried to set that to "nfs/nfscli...@dom.com" in "[service/nfs-client]" section on the "nfsclient" machine, to try and force gssproxy to use that principal instead of "host/...", but it didn't seem to work, gssproxy defaults to "host/...". Possibly mis-understanding what this option is for, and possibly "host/..." is the safer/standard option? I'm assuming it's default for a reason, or maybe just operational convenience (not having to pollute /etc/krb5.keytabs with more principals than necessary). Hope this helps. -- Thanks, Greg Kubok. On 1 March 2017 at 22:47, Orion Poplawski <or...@cora.nwra.com> wrote: > If you ever get this into a repository, I'd love to see it. Thanks. > > On 01/17/2017 07:44 PM, Charles Hedrick wrote: > > Instructions like that are several places. But NFS is different, and I > believe the configuration would be different from other services. > > > > I’ve given up on this approach, and have written my own utilities. I’ve > actually got three. The first two assume that users who want to do cron > jobs on a machine register a keytab for that machine on a secure system. I > don’t want to put the actual keytab on the machine where the user is > running, because if someone can become root, they can take the keytab and > use it anywhere. (I’m in a computer science dept with systems run by > faculty and grad students; also systems in public labs.) > > > > So instead, I allow users to register that they want to do cron on a > specific machine by putting a keytab on a secure server, associated with > their username and the hostname. I expect to write a web app to set that up. > > > > Credserv runs on the machine with the keytabs. It accepts a request from > a server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), > with a username in the request. If the user has registered a keytab for > that host, credserv returns a credential, locked to that IP address, with > forwarding off. > > > > Kgetcred is the client side. It runs setuid root (so it can read > /etc/krb5.keytab), though it drops privs as quickly as possible. It creates > a credentials cache for the user from the credentials returned from > credserv. > > > > This gives the best granularity of control I can come up with. > > > > There’s a third utility in the family: renewd. It gets the uids of all > current processes, and renews credentials for all of the users. It’s more > complex than you’d expect because a normal renewal (as in kinit -R or > kstart) leaves a brief period of time when the credentials cache is > unusable. This can result in NFS failing. I use a special approach that > depends upon the details of the KEYRING implementation. It should be free > of race conditions for NFS. If desired, a different approach to avoid race > conditions could be used for caches located in /tmp. I haven’t written that > code but there’s a comment in the source outlining it. > > > > I’ll be creating a git repository for the code. > > > > > >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski <or...@cora.nwra.com> > wrote: > >> > >> On 01/09/2017 09:52 AM, Charles Hedrick wrote: > >>> Various documentation suggests that it is possible for Gssproxy to get > tickets for users who need to use NFS. This is a possible way to handle > things like cron jobs. > >>> > >>> However while a gssproxy.conf example is given, there’s no sign of > what needs to be done in freeipa to authorize it. I tried following > instructions for LDAP access, but it doesn’t work. NFS seems to use a > different, two-stage method for getting credentials, so that’s not a > surprise. There are, not surprisingly, no useful error messages even with > logging turned all the way up. > >>> > >>> > >> > >> I'm interested in this as well. All I've been able to find so far is: > >> > >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ > >> > >> haven't tried anything. > >> > >> -- > >> Orion Poplawski > >> Technical Manager 720-772-5637 > >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 > >> 3380 Mitchell Lane or...@nwra.com > >> Boulder, CO 80301 http://www.nwra.com > > > > > -- > Orion Poplawski > Technical Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 http://www.nwra.com > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project