If you ever get this into a repository, I'd love to see it.  Thanks.

On 01/17/2017 07:44 PM, Charles Hedrick wrote:
> Instructions like that are several places. But NFS is different, and I 
> believe the configuration would be different from other services. 
> 
> 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.)
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> This gives the best granularity of control I can come up with.
> 
> 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.
> 
> I’ll be creating a git repository for the code.
> 
> 
>> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski <or...@cora.nwra.com> wrote:
>>
>> On 01/09/2017 09:52 AM, Charles Hedrick wrote:
>>> 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.
>>>
>>> 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.
>>>
>>>
>>
>> I'm interested in this as well.  All I've been able to find so far is:
>>
>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
>>
>> haven't tried anything.
>>
>> -- 
>> Orion Poplawski
>> Technical Manager                          720-772-5637
>> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
>> 3380 Mitchell Lane                       or...@nwra.com
>> Boulder, CO 80301                   http://www.nwra.com
> 


-- 
Orion Poplawski
Technical Manager                          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nwra.com
Boulder, CO 80301                   http://www.nwra.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to