Jens Timmerman via FreeIPA-users wrote: > Hi Greg, > > > On 02/03/2017 03:29, Greg wrote: >> 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). >> >> >> >> $ ipa servicedelegationrule-show ipa-nfs-delegation >> Delegation name: ipa-nfs-delegation >> Allowed Target: ipa-nfs-delegation-targets >> Member principals: *host*/*nfsclient*.dom....@dom.com >> <mailto:dom....@dom.com> >> >> $ ipa servicedelegationtarget-show ipa-nfs-delegation-targets >> Delegation name: ipa-nfs-delegation-targets >> Member principals: *nfs*/*nfsserver*.dom....@dom.com >> <mailto: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. >> > An official reply form IPA dev's might indeed be useful here.
Been a long time since I poked at this but host principals are stored in the host entry rather than having a separate service for it. Were I to guess this is why: servicedelegation is only searching services for principals. Probably worth of filing a bug/ticket for further investigation. rob >> 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 >> <mailto:nfsclient.dom....@dom.com> >> > I didn't want to resort to this trickery, turns out there's no reason at > all to use host/, you can create a nfs-client service, and use this. > (I guess this is the recommended way?) > > $ ipa service-add nfs-client/node2801.example....@example.com > --ok-to-auth-as-delegate=True > $ ipa servicedelegationrule-add-member nfs-delegation > --principals=nfs-client/node2801.example.com > $ ipa servicedelegationrule-show nfs-delegation > Delegation name: nfs-delegation > Allowed Target: nfs-delegation-targets > Member principals: nfs-client/node2801.example....@example.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 <http://nfsclient.dom.com> >> --ok-to-auth-as-delegate=true > not needed, we did this for the service >> >> 4. On the "nfsclient" machine, add "impersonate = true" line in the >> "[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf. > change > cred_store = keytab:/etc/krb5.keytab > to > cred_store = keytab:/etc/nfs-client.keytab > where you get nfs-client.keytab by running > ipa-getkeytab -p nfs-client/node2801.example.com -k /etc/nfs-client.keytab >> >> 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. > worked for me, thx! >> >> 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 >> <mailto: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). >> > according to > https://lists.fedorahosted.org/archives/list/gss-pr...@lists.fedorahosted.org/thread/76QKLXFOOM5YBGKPY23V5C2GDTAUTU35/ > `Well ... embarrassingly ... you might be right if we used > krb5_principal anywhere. I am looking at master code and this looks like > a forgotten option ... oops. ` >> Hope this helps. >> >> -- >> Thanks, >> >> Greg Kubok. >> > > Regards, > Jens Timmerman > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
