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*
>> <>
>> $ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
>>   Delegation name: ipa-nfs-delegation-targets
>>   Member principals: *nfs*/*nfsserver*
>> <>
>> 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

Probably worth of filing a bug/ticket for further investigation.


>> 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/
>> <>
> 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/
> --ok-to-auth-as-delegate=True
> $ ipa servicedelegationrule-add-member nfs-delegation
> --principals=nfs-client/
> $ ipa servicedelegationrule-show nfs-delegation
>   Delegation name: nfs-delegation
>   Allowed Target: nfs-delegation-targets
>   Member principals: nfs-client/
>> 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 <>
>> --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/ -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/
>> <>" 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
> `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 --
> To unsubscribe send an email to
FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to