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.
> 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

Reply via email to