Hi Bolke.. Sorry for the late reply.. I have been on vacation.
Thanks for taking an interest in adding support for more KDC implementations in Ambari. I know that a lot of people are looking for FreeIPA integration. Here are answers to your questions: * Why does Ambari store (user) principal passwords? It seems that this might only be required in case of a linux client with Active Directory where command line utils are unavailable to generate a key tab? It also creates an additional attack vector. Ambari does not store the principal passwords… for long. Ambari performs all of the work to create the keytab files. This is to avoid issues trying to integrate with KDCs to have them do it. For example, there is no way to remotely have Active Directory create keytab files. Therefore, in order to create keytab files, Ambari needs to know what the password is for a given principal. Since the workflow has the principal creation and the keytab file creation processes in different stages, the password generated in the principal creation stage is temporarily stored so that the keytab file stage can access it. This storage is in memory and is never persisted to disk. It goes away when (or shortly after) the request that started the workflow is completed. The reason this is done for all KDC integrations is to make the code more consistent and easier to manage and support. * Currently the test principal that Ambari generates is a user principal for which key tab is generated. I am not aware of any user principals that need key tabs and are managed by Ambari. Can this test principal also be a service principal and isn’t that even more appropriate? I don’t think it is appropriate to use a service principal where a user principal is needed. They typically serve different purposes. In the case of the test principal, Ambari uses that as a _user_ to perform automated tests to ensure the cluster is running as expected. I don’t see why this should be converted to a service principal. I hope this helps, Rob On 8/26/15, 5:36 AM, "Bolke de Bruin" <[email protected]> wrote: >Hello, > >I am implementing IPA as a Kerberos provider. If you are interested you can >see my progress here https://github.com/bolkedebruin/ambari . > >I’m running into a couple of issues where I need some guidance. > >Background: >IPA requires a password change for user principals on first authentication >(http://www.freeipa.org/page/New_Passwords_Expired). It is not advised to >change this manually and if you do it requires Directory Manager and ldap >access. This interferes with how Ambari handles key tab creation: password >policies still apply in case of key tab for user principals and thus the >Ambari generated key tab is unusable. > >Questions: >* Why does Ambari store (user) principal passwords? It seems that this might >only be required in case of a linux client with Active Directory where command >line utils are unavailable to generate a key tab? It also creates an >additional attack vector. >* Currently the test principal that Ambari generates is a user principal for >which key tab is generated. I am not aware of any user principals that need >key tabs and are managed by Ambari. Can this test principal also be a service >principal and isn’t that even more appropriate? > >Thanks! >Bolke
