<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Thanks. That’s what I was originally looking for. However since asking it I realized that doing it without further limitations defeats the purpose of using Kerberos in the first place, since it means that anyone who becomes the user in Linux can
access their files.</div>
<div class=""><br class="">
</div>
<div class="">I’m trying to make sure that users can decide which machines they’re willing to expose to access without a credential. In our department we have shared systems, which we run, student labs, which we run but that are not physically secure, and user-maintained
machines. We’d like to say that normally no one can access your files without having your credentials. So if someone manages to become root on one system they don’t suddenly have access to everyone’s files. </div>
<div class=""><br class="">
</div>
<div class="">We have to relax that where users need to run cron jobs. But I’d like that relaxation to be in a controlled way. That is, I want the user to have to say that on a specific machine it’s possible to access their files based just on being their uid.
But that only applies to the specific user on the specific machine. That at least restricts exposure.</div>
<div class=""><br class="">
</div>
<div class="">If S42U is turned on for NFS as described below, then anyone who becomes root can become any user, and then access any user’s files. </div>
<div class=""><br class="">
</div>
<div class="">The design documentation says:</div>
<div class=""><br class="">
</div>
<div class="">"The ACL system also provides a means of limiting which user's a ticket may be obtained for using the ipaAllowToImpersonate attribute. This is not implemented."</div>
<br class="">
There’s no sign of this feature in the command line tools, so I assume it’s still not implemented. Until it is I don’t think that will do what I need.
<div class=""><br class="">
</div>
<div class="">Kgetcred, however, will do the job.<br class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 1, 2017, at 9:29 PM, Greg <<a href="mailto:gkubok@gmail.com" class="">gkubok@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">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).
<div class=""><br class="">
</div>
<div class="">Whether and how this would apply to cron or other services, I don't know yet, but presumably would/should work in a similar manner.</div>
<div class=""><br class="">
</div>
<div class="">My env:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><font face="monospace, monospace" class="">$ lsb_release -d</font></div>
<div class=""><font face="monospace, monospace" class="">Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)</font></div>
<div class=""><font face="monospace, monospace" class="">$ rpm -q ipa-server</font></div>
<div class=""><font face="monospace, monospace" class="">ipa-server-4.4.0-14.el7_3.4.x86_64</font></div>
<div class=""><font face="monospace, monospace" class="">$ ipa --version</font></div>
<div class=""><font face="monospace, monospace" class="">VERSION: 4.4.0, API_VERSION: 2.213</font></div>
</div>
<div class=""><br class="">
</div>
<div class="">This is what worked for me in the end:</div>
<div class=""><br class="">
</div>
<div class="">1. Create "nfs/<a href="mailto:nfsserver.dom.com@DOM.COM" class="">nfsserver.dom.com@DOM.COM</a>" service, and add to NFS server's /etc/krb5.keytab.</div>
<div class=""><br class="">
</div>
<div class="">2. Create IPA "servicedelegation" rule/targets, so that they look like so:<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><font face="monospace, monospace" class="">$ ipa servicedelegationrule-show ipa-nfs-delegation</font></div>
<div class=""><font face="monospace, monospace" class=""> Delegation name: ipa-nfs-delegation</font></div>
<div class=""><font face="monospace, monospace" class=""> Allowed Target: ipa-nfs-delegation-targets</font></div>
<div class=""><font face="monospace, monospace" class=""> Member principals: <b class="">
host</b>/<b class="">nfsclient</b>.<a href="mailto:dom.com@DOM.COM" class="">dom.com@DOM.COM</a></font></div>
<div class=""><font face="monospace, monospace" class=""><br class="">
</font></div>
<div class=""><font face="monospace, monospace" class="">$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets</font></div>
<div class=""><font face="monospace, monospace" class=""> Delegation name: ipa-nfs-delegation-targets</font></div>
<div class=""><font face="monospace, monospace" class=""> Member principals: <b class="">
nfs</b>/<b class="">nfsserver</b>.<a href="mailto:dom.com@DOM.COM" class="">dom.com@DOM.COM</a></font></div>
</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">I force added it to the delegation rule via LDAP instead using this ldif:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><font face="monospace, monospace" class="">dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com</font></div>
<div class=""><font face="monospace, monospace" class="">changetype: modify</font></div>
<div class=""><font face="monospace, monospace" class="">add: memberPrincipal</font></div>
<div class=""><font face="monospace, monospace" class="">memberPrincipal: host/<a href="mailto:nfsclient.dom.com@DOM.COM" class="">nfsclient.dom.com@DOM.COM</a></font></div>
</div>
<div class=""><br class="">
</div>
<div class="">The "nfs/..." principal can be added using CLI "ipa servicedelegationtarget-add-member ..." just fine.</div>
<div class=""><br class="">
</div>
<div class="">3. Allow the "nfsclient" host to impersonate users:</div>
<div class=""><br class="">
</div>
<div class=""><font face="monospace, monospace" class="">$ ipa host-mod <a href="http://nfsclient.dom.com/" class="">
nfsclient.dom.com</a> --ok-to-auth-as-delegate=true</font></div>
<div class=""><br class="">
</div>
<div class="">4. On the "nfsclient" machine, add "impersonate = true" line in the "[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">So my IPA automount config now mounts users' home dirs on the "nfsclient", without any tickets or keytabs from users.</div>
<div class=""><br class="">
</div>
<div class="">There's also a "krb5_principal" option available in gssproxy.conf - I tried to set that to "nfs/<a href="mailto:nfsclient@DOM.COM" class="">nfsclient@DOM.COM</a>" 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).</div>
<div class=""><br class="">
</div>
<div class="">Hope this helps.</div>
<div class=""><br class="">
</div>
<div class="">--</div>
<div class="">Thanks,</div>
<div class=""><br class="">
</div>
<div class="">Greg Kubok.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">On 1 March 2017 at 22:47, Orion Poplawski <span dir="ltr" class="">
<<a href="mailto:orion@cora.nwra.com" target="_blank" class="">orion@cora.nwra.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you ever get this into a repository, I'd love to see it. Thanks.<br class="">
<br class="">
On 01/17/2017 07:44 PM, Charles Hedrick wrote:<br class="">
> Instructions like that are several places. But NFS is different, and I believe the configuration would be different from other services.<br class="">
><br class="">
> I’ve given up on this approach, and have written my own utilities. I’ve actually got three. The first two assume that users who want to do cron jobs on a machine register a keytab for that machine on a secure system. I don’t want to put the actual keytab
on the machine where the user is running, because if someone can become root, they can take the keytab and use it anywhere. (I’m in a computer science dept with systems run by faculty and grad students; also systems in public labs.)<br class="">
><br class="">
> So instead, I allow users to register that they want to do cron on a specific machine by putting a keytab on a secure server, associated with their username and the hostname. I expect to write a web app to set that up.<br class="">
><br class="">
> Credserv runs on the machine with the keytabs. It accepts a request from a server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with a username in the request. If the user has registered a keytab for that host, credserv returns a credential,
locked to that IP address, with forwarding off.<br class="">
><br class="">
> Kgetcred is the client side. It runs setuid root (so it can read /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a credentials cache for the user from the credentials returned from credserv.<br class="">
><br class="">
> This gives the best granularity of control I can come up with.<br class="">
><br class="">
> There’s a third utility in the family: renewd. It gets the uids of all current processes, and renews credentials for all of the users. It’s more complex than you’d expect because a normal renewal (as in kinit -R or kstart) leaves a brief period of time when
the credentials cache is unusable. This can result in NFS failing. I use a special approach that depends upon the details of the KEYRING implementation. It should be free of race conditions for NFS. If desired, a different approach to avoid race conditions
could be used for caches located in /tmp. I haven’t written that code but there’s a comment in the source outlining it.<br class="">
><br class="">
> I’ll be creating a git repository for the code.<br class="">
><br class="">
><br class="">
>> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski <<a href="mailto:orion@cora.nwra.com" class="">orion@cora.nwra.com</a>> wrote:<br class="">
>><br class="">
>> On 01/09/2017 09:52 AM, Charles Hedrick wrote:<br class="">
>>> Various documentation suggests that it is possible for Gssproxy to get tickets for users who need to use NFS. This is a possible way to handle things like cron jobs.<br class="">
>>><br class="">
>>> However while a gssproxy.conf example is given, there’s no sign of what needs to be done in freeipa to authorize it. I tried following instructions for LDAP access, but it doesn’t work. NFS seems to use a different, two-stage method for getting credentials,
so that’s not a surprise. There are, not surprisingly, no useful error messages even with logging turned all the way up.<br class="">
>>><br class="">
>>><br class="">
>><br class="">
>> I'm interested in this as well. All I've been able to find so far is:<br class="">
>><br class="">
>> <a href="https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/" rel="noreferrer" target="_blank" class="">
https://vda.li/en/posts/2013/<wbr class="">07/29/Setting-up-S4U2Proxy-<wbr class="">with-FreeIPA/</a><br class="">
>><br class="">
>> haven't tried anything.<br class="">
>><br class="">
>> --<br class="">
>> Orion Poplawski<br class="">
>> Technical Manager 720-772-5637<br class="">
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702<br class="">
>> 3380 Mitchell Lane <a href="mailto:orion@nwra.com" class="">orion@nwra.com</a><br class="">
>> Boulder, CO 80301 <a href="http://www.nwra.com/" rel="noreferrer" target="_blank" class="">http://www.nwra.com</a><br class="">
><br class="">
<span class="gmail-HOEnZb"><font color="#888888" class=""><br class="">
<br class="">
--<br class="">
Orion Poplawski<br class="">
Technical Manager 720-772-5637<br class="">
NWRA, Boulder/CoRA Office FAX: 303-415-9702<br class="">
3380 Mitchell Lane <a href="mailto:orion@nwra.com" class="">orion@nwra.com</a><br class="">
Boulder, CO 80301 <a href="http://www.nwra.com/" rel="noreferrer" target="_blank" class="">http://www.nwra.com</a><br class="">
<br class="">
--<br class="">
Manage your subscription for the Freeipa-users mailing list:<br class="">
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" target="_blank" class="">https://www.redhat.com/<wbr class="">mailman/listinfo/freeipa-users</a><br class="">
Go to <a href="http://freeipa.org/" rel="noreferrer" target="_blank" class="">http://freeipa.org</a> for more info on the project</font></span></blockquote>
</div>
<br class="">
<div class=""><br class="">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>