If I understand the concern, I have the same one. For user cron jobs, the traditional approach is for the user to create a keytab. As others have noted, the keytab is equivalent to the password. The problem for me is that a keytab is good on all hosts. So if someone manages to become root on one system and steal a keytab, they can use it anywhere. (In my environment we have machines in public labs and even machines administered by students, so security of a keytab file is by no means guaranteed).
What I’ve done is create a utility that lets a user authorize their key to be used by root on a specific machine. Rather than transferring a copy of the ke tab, I have a client / server setup where the server stores the keytabs, securely one hopes, and generates a credential when requested by the client. It’s sent securely to the client, which uses it to create a credential cache. So neither password nor keytab is needed on the client. My code is for MIT Kerberos. A similar system has been done for Heimdal that doesn’t store keytabs on the server. It includes the code from the KDC in its server, and thus is able to generate credentials directly from the database, just as the KDC can. Another approach is to use S4U2. This allows you to tell the Kerberos server that a given user on a given host is allowed to act for a given client. This has much the same effect as my client / server, but it’s standards-based. The problem is that it’s a new feature. It may not be available for your system, or it may be available but without that level of granularity in access control. The implementation I’m aware of assumes that your application uses Kerberos through GSSAPI. > On May 11, 2017, at 2:47 AM, Abhishek Kaushik <akaushik...@gmail.com> wrote: > > Okay.The reason I asked for the format is this : for my work, I need the > keytab file to be loaded in my application and since it has to be > protected, I was planning to encode it in, say Base64 and store it in a > secure server, and retrieve it from there and decode it and use it. But > since the keytab file contains the service principal name and the keys, i > wasn't sure if it is possible to encode such a value. > > > > On Wed, May 10, 2017 at 12:46 AM, Benjamin Kaduk <ka...@mit.edu> wrote: > >> On Wed, May 10, 2017 at 12:20:44AM +0530, Abhishek Kaushik wrote: >>> Thank you for replying. >>> >>> I understood that it is a symmetric key which is shared with the KDC. >>> So, is it in binary format or is there some other format which is used, >>> generally? >> >> The keytab file format is documented at >> http://web.mit.edu/kerberos/krb5-latest/doc/formats/ >> keytab_file_format.html >> >>> And what if(hypothetically) you don't have a password for some user, how >> is >>> the key generated in such a case? >>> Like you have mentioned that the services only have the raw key.. >> >> During provisioning or rekeying, the KDC generates a random key and >> transmits it to the client (over an encrypted connection, of >> course). >> >> -Ben >> > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
