On Fri, 2017-12-01 at 14:34 +0100, Anton Semjonov 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
> > 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
> > 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
> > 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.
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.
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.
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: nfsdcb: authbuf=gss/krb5 authtype=user
rpc.idmapd: Server : (user) id "48" -> name
in the server's journal. So I am not sure where things do break apart ..
Sr. Principal Software Engineer
Red Hat, Inc