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 <[email protected]> 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 [email protected] >> 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 [email protected] 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
