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?
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.
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
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 freeipa-users@lists.fedorahosted.org 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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 11/30/2017 03:11 PM, Simo Sorce wrote:
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...
Naturally. I think I understand the "why" part of krb5 NFS authentication, but I'm trying to figure out how to allow access from system accounts, where creating a new user and changing the UID for an existing process would mean changing permissions on the local filesystems in addition to the NFS filesystems.
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.
That looks like it's probably what I'm after, though I can't get it to actually work. On the NFS server, I've set '[Translation] Method = nsswitch,static' and set '[Static] daemon/f.q.d.n@REALM = daemon'. With verbosity set to an arbitrary large value, I see what appears to be activity mapping numeric UID and GIDs to names, but never the reverse. There is no logged activity mapping a name to a UID, and the process which has the 'daemon/f.q.d.n@REALM' ticket gets access as the nfsnobody account. (It had no permission of any kind with no ticket.) It may be good enough to provide a ticket and no mapping, since I want it to access globally readable files, and the nfsnobody user can do that, but I would like to understand the mapping feature better than I do. I'm doing something wrong, but I'm not sure what. That seems like a question better suited for another list, though.
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 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.
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.
HTH, Simo.
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
On 12/01/2017 09:52 AM, Simo Sorce via FreeIPA-users wrote:
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.
Not sure if I'm doing this right, but that doesn't work for me, either:
[realms] EXAMPLE.NET = { pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem auth_to_local = RULE:[2:$1](daemon)s/^.*$/daemon/ auto_to_local = DEFAULT }
Client's default principal is daemon/application-2017111901.example.net@EXAMPLE.NET
On Fri, 2017-12-01 at 11:15 -0800, Gordon Messmer via FreeIPA-users wrote:
On 12/01/2017 09:52 AM, Simo Sorce via FreeIPA-users wrote:
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.
Not sure if I'm doing this right, but that doesn't work for me, either:
[realms] EXAMPLE.NET = { pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem auth_to_local = RULE:[2:$1](daemon)s/^.*$/daemon/ auto_to_local = DEFAULT }
Client's default principal is daemon/application-2017111901.example.net@EXAMPLE.NET
I think what you want is something like: RULE:[2:$1@$0](daemon@EXAMPLE.NET)s/.*//
note, this will map any daemon/<arbitrary>@REALM principals to the local 'daemon' user, be sure that's is ok.
This is a decent guide to better understand what can be done with auth_to_local: https://community.hortonworks.com/articles/14463/auth-to-local-rules-sy ntax.html
HTH, Simo.
freeipa-users@lists.fedorahosted.org
-
Anton Semjonov -
Charles Hedrick -
Gordon Messmer -
Simo Sorce