[
https://issues.apache.org/jira/browse/AMBARI-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14721029#comment-14721029
]
Bolke de Bruin commented on AMBARI-6432:
----------------------------------------
I have implemented IPA support in my fork at
https://github.com/bolkedebruin/ambari. It implements it as a separate kerberos
service (ie like MIT, AD). On a couple of things I need some feedback or help:
* Where do I need to place (ie. which stack) the additional parameters
"admin_keytab" and "group"?
* It seems that not everything is picked up for the ui (like description or
location) for these additional parameters. What am I doing wrong?
Caveats:
* Some idiosyncracies of IPA and Ambari are difficult to match. For example
Ambari likes to create its key tabs programmatically, but this is incompatible
with IPA as additional encryption types are generated only after a key tab is
requested (and generated in IPA 4) on the server. This means that, in my
implementation, the Ambari generated password is ignored for user principals or
service principals that get a key tab generated.
* Also, due to the fact IPA requires a password change on first use for user
principals. Also if a key tab is generated for this user (which is a bit weird
and I will need to ask to the IPA guys). Therefore, the user administrator (the
principal in admin_keytab) requires additional permissions to be able to write
to krbPasswordExpiration (ipa permission-add “Set Password Expiry”
–permissions=write –type=user –attrs=krbPasswordExpiration, ipa
privilege-add-permission “User Administrators” –permission=”Set Password
Expiry”). Question: is this the right way to go or should an "expect" utility
be implemented so that the password can be set?
* Tests still need to be written.
> FreeIPA Support in Ambari
> -------------------------
>
> Key: AMBARI-6432
> URL: https://issues.apache.org/jira/browse/AMBARI-6432
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
> Reporter: jay vyas
>
> FreeIPA Is a powerful tool for unifying identity, kerberos credentials,
> across a cluster.
> A great value add for ambari would be to provide support for using FreeIPA to
> kerberize services. This would allow for
> 1) better HCFS interoperability, because first class GID/UID is critical for
> certain file systems (GlusterFS, Lustre, and any other file system which uses
> kernel / FUSE apis for determining identity)
> 2) better enterprise interoperability. Because of the fact that FreeIPA
> makes it easy to interop with different identity solutions (like active
> directory), it would make ambari easier to adopt for various enterprises.
> 3) broadens ambaris scope. Now ambari could also allow people to setup the
> users of their clusters, and at least some of the security features of their
> clusters, all from one interface (no more manual handling of TGTs and such -
> it could all be done quite easily via the ambari UI which could make calls to
> underlying FreeIPA clients).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
