We don’t want to use keytabs for regular users due to security concerns. For interactive servers, we integrated kinit as part of X unlock process. So every time user unlocks his screen (at least once a day), he gets a new ticket on that interactive server. From there, when a user tries to connect to another server via SSH – it will transfer the ticket We use internally developed grid management system, we added support in this system for ticket transfer and distribution between all compute servers where user’s job is landing
For faceless accounts, cron jobs, etc we’ve developed a special distributed system to store keytabs, and it is accessed to get a ticket when needed.
From: Michael Garrison [mailto:mcgarr@umich.edu] Sent: Monday, November 10, 2014 18:48 To: Touretsky, Gregory Cc: toasters@teaparty.net Subject: Re: "Sensitive data" storage needs
Thanks Greg! Have you implemented any type of automated keytab generation/management system?
The hard part in our environment is that, for the most part, I have no control over client machines and what they are doing. Our ticket lifetime renewable maxes out at 7 days; we could discuss changing that or generating keytabs for people to use, but we have to train researchers/their support staff on properly executing long running jobs, etc.
We have an OpenAFS cell here and it's always been a struggle for clients to install that. In my experience, Kerberized NFSv4 (or v3) Linux support is far behind where the AFS client is, not to mention the lack of Windows or OS X support (unless things have changed since last time I looked). Even if everything is in place, I believe that a lot of folks will see what it takes to implement it properly and decide to do something else.
I appreciate all the feedback from everyone so far, Mike Garrison
On Sun, Nov 9, 2014 at 2:30 AM, Touretsky, Gregory <gregory.touretsky@intel.commailto:gregory.touretsky@intel.com> wrote: We’re piloting NFSv3 with Kerberos in our environment. See http://snia.org/sites/default/files2/SPDEcon2013/presentations/Security/Greg... for some details. The main goal is to overcome 16 GIDs limitation.
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Michael Garrison Sent: Friday, November 07, 2014 23:53 To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: "Sensitive data" storage needs
We currently offer a NFS v3 service that people can purchase. It's relatively inexpensive and basic, but thats what folks like. They can access it from their desktop and then access the data on a cluster to do compute jobs. However, it doesn't meet the requirements of being able to store sensitive data - like ePHI.
I've been exploring the route of NFS v4 with Kerberos, but the Linux client leaves a lot to be desired. Additionally, folks are so used to how NFS v3 works that introducing Kerberos into the mix is challenging.
How are other groups (business, academic, whatever), addressing security, yet doing it in an inexpensive manner and allowing cross-platform access? Is anyone doing NFS v4 (or v3) with Kerberos today?
Thanks, Mike Garrison
--------------------------------------------------------------------- Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
--------------------------------------------------------------------- Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.