The repo is There’s a, and 
man pages for the individual programs. While I’m currently using these 
programs, we haven’t fully rolled out Kerberos yet. As we do, I expect we’ll 
want to add more features. (E.g. kgetcred / credserv need to support redundant 

When free ipa implements all planned features, kgetcred / credserv may not 
longer be needed. Rnewd and skinit still will be (though skinit should be 
modified to use “kinit -n” rather than “kgetcred -a"

On Mar 1, 2017, at 5:47 PM, Orion Poplawski 
<<>> wrote:

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 

I’ll be creating a git repository for the code.

On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski 
<<>> 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:

haven't tried anything.

Orion Poplawski
Technical Manager                          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane             
Boulder, CO 80301         

Orion Poplawski
Technical Manager                          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane             <>
Boulder, CO 80301         

Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to