Do you also need auth_to_local in krb5.conf? I believe idmapd just controls 
what you see in ls -l.

> On Dec 1, 2017, at 8:34 AM, Anton Semjonov via FreeIPA-users 
> <> 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 --
> To unsubscribe send an email to
FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to