0

Scenario:

  • We want to connect to multiple AD domains to fetch AD object information.
  • For authentication, we want to use Kerberos.
  • This is done simultaneously, meaning, fetching data from multiple AD domains is expected to be done in a single request - either interchangeably or in multi-threaded environment.

The Problem:

  • Kerberos authentication takes time and is proving to be performance hit

  • So, caching the TGT credentials on the application machine would solve the issue for us

  • A single cache file stores only one principal TGT. So to support multiple domains, we have to persist multiple cache files and dynamically choose which cache file to be used for current context creation.

  • This is indeed a valid solution, but the problem is about the security concerns: How?

We are caching the TGT using kinit in different cache files, but the drawback of this solution is that, if the security of the application machine is compromised, then those TGTs could be utilized by any different applications for authentication (we want the lifetime of the TGTs to be more)

So, is there a way where we can utilize an in-memory cache? I am aware of the MEMORY: ccache configuration in the krb.conf file, but again, how can that solve the issue of caching multiple principal TGTs? I haven't tried this solution, but as far as I understand, the successive kinit calls would overwrite the previous principal TGT.

Would having different krb.conf files for each AD domain help us? I am yet to explore the concept of keytab, would that of any help in addressing our issue?

Please Note: I am new to this space and yet in the phase of learning the concepts along with the implementation. A few of the above points might feel like a guess work and indeed they are.

theimpatientcoder
  • 1,184
  • 3
  • 19
  • 32
  • The Java implementation of Kerberos can read the shared cache, but cannot write in it -- think of that as a compatibility layer with **legacy, unsecure** habits. You can create your own private, in-memory ticket via JAAS configuration -- via passwords (interactive mode) or keytab files (headless mode). And you can manage multiple tickets for different "subjects". At least in theory -- it's complicated and the documentation is sparse – Samson Scharfrichter Jan 13 '21 at 19:56
  • Note: the `krb5.conf` file is pretty much off-topic, it just handles how your app contacts the KDC services (at network and Kerberos protocol levels). – Samson Scharfrichter Jan 13 '21 at 19:58
  • @SamsonScharfrichter Thanks for the comment. Can you please point me to some content that will help me understand how in-memory ticket using JAAS configuration works which will provide a starting point for me to implement if that seems possible. – theimpatientcoder Jan 14 '21 at 11:35
  • https://stackoverflow.com/a/42506620/5162372 – Samson Scharfrichter Jan 14 '21 at 19:33
  • To manage multiple, explicit credentials: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html (pretty cryptic though, you will want to find some actual implementations in e.g. GitHub to get a more comprehensive overview) – Samson Scharfrichter Jan 14 '21 at 19:36
  • To manage multiple entries in a single JAAS conf: https://stackoverflow.com/questions/45770743/kerberos-error-connecting-to-impala-and-hbase – Samson Scharfrichter Jan 14 '21 at 19:38

0 Answers0