I'm troubleshooting a problem: A local system account (daemon) needs to access a file on an NFS4 filesystem with sec=krb5.  My understanding is that only processes which have a Kerberos ticket are able to access files on such a filesystem, and that seems to be the case on the system I'm troubleshooting. Suppose I need a keytab to identify the "daemon" user.  I don't think I want to create a new user in FreeIPA, since it would have a uid/gid that conflict with the locally defined account. However, I think I do need a keytab for "daemon(a)DOMAIN". The ipa command doesn't seem to provide a means of creating such a principal. Should I work directly in kadmin to create the principal and export the keytab?  Am I even on the right track?

On Dec 1, 2017, at 8:34 AM, Anton Semjonov via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt; wrote: On 01/12/17 00:11, Simo Sorce via FreeIPA-users wrote: > On Thu, 2017-11-30 at 14:50 -0800, Gordon Messmer via FreeIPA-users > wrote: >> I'm troubleshooting a problem: A local system account (daemon) needs to >> access a file on an NFS4 filesystem with sec=krb5. My understanding is >> that only processes which have a Kerberos ticket are able to access >> files on such a filesystem, and that seems to be the case on the system >> I'm troubleshooting. >> >> Suppose I need a keytab to identify the "daemon" user. I don't think I >> want to create a new user in FreeIPA, since it would have a uid/gid that >> conflict with the locally defined account. However, I think I do need a >> keytab for "daemon@DOMAIN". The ipa command doesn't seem to provide a >> means of creating such a principal. >> >> Should I work directly in kadmin to create the principal and export the >> keytab? Am I even on the right track? > > The reason why NFS wants to authenticate you, is to know what uig/gid > it should assign to your user (on the server) to access files. So > creating a user is not necessarily a bad idea... > > However in some NFS servers you may be able to create mappings from > principals to local users. In that case you can use a SPN (Service > Principal Name) and associated keytab to gain access. > > In freeipa only users can have a 1 component principal such as "daemon@ > DOMAIN" normally. If you really just want to use a service I would > first explore the possibility of mapping "daemon/hosts.f.q.d.n@REALM" > to a user on the NFS server and then just create a normal service and > get a keytab for in in IPA. > > Simo. > Could you elaborate on the mapping aspect? Specifically, what format do the static mappings in /etc/idmapd.conf need to be in in case of such service principals as you describe them? As far as I can tell gssproxy works great for me and system users get their credential caches and so on .. but I'm stuck on id mapping. If I leave idmapd.conf at its defaults with no static mappings, the correct username is displayed on the client (e.g. apache) but the user is then denied access to files only readable by apache on the server. If I define a static mapping like HTTP/client.$fqdn @ $REALM = apache on the server and restart rpcidmapd.service, the owner of said files is mapped to nobody on the client, while the user has a credential cache for the service principal HTTP/client.$fqdn@$REALM. I am testing all of this by doing `su apache -s /bin/bash` on the client, btw. However I do see lines like rpc.idmapd[26077]: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd[26077]: Server : (user) id "48" -> name "HTTP/client.$fqdn" in the server's journal. So I am not sure where things do break apart .. - Anton _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org

gssproxy dos not use libidmapd because it is not threads safe (among other issues), it is also not needed, because you can control mapping in auth_to_local in krb5.conf and that place is the correct place to deal with identity mapping when kerberos is involved.

The reason why NFS wants to authenticate you, is to know what uig/gid it should assign to your user (on the server) to access files. So creating a user is not necessarily a bad idea...

However in some NFS servers you may be able to create mappings from principals to local users. In that case you can use a SPN (Service Principal Name) and associated keytab to gain access. In freeipa only users can have a 1 component principal such as "daemon@ DOMAIN" normally. If you really just want to use a service I would first explore the possibility of mapping "daemon/hosts.f.q.d.n@REALM" to a user on the NFS server and then just create a normal service and get a keytab for in in IPA.