One of the credential cache types offered by MIT Kerberos is MEMORY. According to the documentation it is used by kadmin.

MEMORY caches are for storage of credentials that don’t need to be made available outside of the current process. For example, a memory ccache is used by kadmin to store the administrative ticket used to contact the admin server.

I have tried setting default_ccache_name = MEMORY: in /etc/krb5.conf. After doing so I made a packet capture while issuing the kinit command. From this capture I can see that a TGT was successfully obtained from the KDC. This ticket was then (obviously) lost as soon as the kinit process finished. Furthermore, it seems if persistent memory based tickets are required one can use the KEYRING ccache type.

What are the other use cases of the MEMORY credential cache type?

I assume this is not useful from a bash script for example. When the script calls kinit it will fork and upon completion the obtained ticket will not be accessible to the parent.

Is there perhaps a kerberos header file that can be included so as to keep obtained tickets in the same address space as the rest of your logic?

  • this is an interesting question, i didn't know this MEMORY option either, i assume there are some kind of possiblities to use it in C or Perl applications and keep the memory address location to use it afterwards, and it's better than a file so it cannot be obfuscated? or something
    – olivierg
    Commented Jun 16, 2017 at 19:47
  • i suppose we can use the KRB5CCNAME variable and perform another kerberos query afterwards using this cache (automatically)
    – olivierg
    Commented Jun 16, 2017 at 19:49
  • Yes that was my thought exactly. It doesn't seem so useful from the command line. I assume it must be usable from C code so that the ticket can be used internally. It certainly beats keeping this sensitive information in the (world read/writeable) /tmp directory!
    – rlf
    Commented Jun 16, 2017 at 19:55

2 Answers 2


The answer to this question is exactly what was postulated in the comments. From your code you can include the krb5.h header. This will give you access to the functions that make up the Kerberos code base.

Below is a toy example that is adapted from the documentation.

#include <string.h>
#include <krb5.h>

int main(void)
    krb5_error_code ret;
    krb5_creds creds;
    krb5_principal client_princ = NULL;

    krb5_context context;
    const char* princname = "user@REALM";
    const char* password = "secret";


    memset(&creds, 0, sizeof(creds));
    ret = krb5_parse_name(context, princname, &client_princ);
    if (ret)
        goto cleanup;
    ret = krb5_get_init_creds_password(context, &creds, client_princ,
                                       password, NULL, NULL, 0, NULL, NULL);
    if (ret)
        goto cleanup;
    ret = krb5_verify_init_creds(context, &creds, NULL, NULL, NULL, NULL);

    /* do things with the ticket (&creds) here */

    krb5_free_principal(context, client_princ);
    krb5_free_cred_contents(context, &creds);

    return 0;

The function krb5_init_context() is what reads your configuration file and honours the MEMORY: ccache type. The obtained ticket will then be stored in this processes memory space.

This code does indeed obtain a TGT. We can verify this by taking a packet capture while it runs. We can also just dump the memory of this process and verify that the TGT is contained in it.


The manual talks about kadmin example. It can be invoked either as a CLI with normal tickets in KEYRING or in FILEs. The other possibility is to run the commands interactively in kerberos "shell". In that case, the ticket is stored in the memory of the process where it is "more secure" and it is automatically cleaned up as the process ends.

The same way kerberos tickets and operations can be accessed from other applications using already mentioned "header" files, generally using so called GSSAPI (gssapi.h). Not completely answer to your question, but this is the way how the keberos primitives are accessed in the OpenSSH to access local kerberos ticket and authenticate to the remote server (in this case the MEMORY type would not be useful).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .