Team,
What will be correct procedure to establish kerberos trust to non Active Directory server running MIT Kerberos.
Regards, Andrey
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote:
Team,
What will be correct procedure to establish kerberos trust to non Active Directory server running MIT Kerberos.
This is something we do not officially support, but see https://bugzilla.redhat.com/show_bug.cgi?id=1035494#c16 and comment 14.
Alexander,
Thank you for the hint! We are testing component integration in the non-production environment in the lab. Can you advice if that is potentially working solution and we can get working, or someone tried without much success and Red Hat won’t be investing time into that development even in the future at all.
Regards, Andrey
On 5/30/17, 12:00 PM, "Alexander Bokovoy" abokovoy@redhat.com wrote:
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote:
Team,
What will be correct procedure to establish kerberos trust to non Active Directory server running MIT Kerberos.
This is something we do not officially support, but see https://bugzilla.redhat.com/show_bug.cgi?id=1035494#c16 and comment 14.
-- / Alexander Bokovoy
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote:
Alexander,
Thank you for the hint! We are testing component integration in the non-production environment in the lab. Can you advice if that is potentially working solution and we can get working, or someone tried without much success and Red Hat won’t be investing time into that development even in the future at all.
I have no idea on how Red Hat plans to productize FreeIPA features that aren't developed yet, so no comment on that side.
Upstream-wise, when we get IPA-IPA trust working, we'll get to the point where this would be required to handle and have it properly working. In IPA-AD trust this is handled automatically by the code in ipasam module but IPA-AD trust is more than just a Kerberos realm trust.
A problem with a generic Kerberos realm trust is that it doesn't really have an answer to an identity part of the question. You would have Kerberos principals from a trusted realm but you don't know to which identities they need to be mapped on POSIX systems enrolled into IPA, for POSIX applications.
This goes further -- if we have no identities, how we can apply RBAC, HBAC, SUDO, and other rules.
One possible answer to those questions is when you have identical user names on both sides and you are effectively ask to impersonate IPA users by a trusted realm Kerberos principals. This still needs manual setup on your side to allow mapping of the principals but at least solves identity problem. It is, however, a hardly most interesting case.
So what use case you have in mind for such a trust?
Alexander,
Thanks again for your point of view of the problem! There are some Linux centric products on the market that require centralized AAA services (Authentication, Authorization, Accounting). One of them is Hadoop and it’s Hortonworks implementation. It has it’s own Kerberos to be able to authenticate users from centrally managed domain and we were exploring options on how to point it into user base that we currently have within IPA domain.
Regards, Andrey
On 5/30/17, 12:43 PM, "Alexander Bokovoy" abokovoy@redhat.com wrote:
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote:
Alexander,
Thank you for the hint! We are testing component integration in the non-production environment in the lab. Can you advice if that is potentially working solution and we can get working, or someone tried without much success and Red Hat won’t be investing time into that development even in the future at all.
I have no idea on how Red Hat plans to productize FreeIPA features that aren't developed yet, so no comment on that side.
Upstream-wise, when we get IPA-IPA trust working, we'll get to the point where this would be required to handle and have it properly working. In IPA-AD trust this is handled automatically by the code in ipasam module but IPA-AD trust is more than just a Kerberos realm trust.
A problem with a generic Kerberos realm trust is that it doesn't really have an answer to an identity part of the question. You would have Kerberos principals from a trusted realm but you don't know to which identities they need to be mapped on POSIX systems enrolled into IPA, for POSIX applications.
This goes further -- if we have no identities, how we can apply RBAC, HBAC, SUDO, and other rules.
One possible answer to those questions is when you have identical user names on both sides and you are effectively ask to impersonate IPA users by a trusted realm Kerberos principals. This still needs manual setup on your side to allow mapping of the principals but at least solves identity problem. It is, however, a hardly most interesting case.
So what use case you have in mind for such a trust?
-- / Alexander Bokovoy
On ti, 30 touko 2017, Andrey Ptashnik wrote:
Alexander,
Thanks again for your point of view of the problem! There are some Linux centric products on the market that require centralized AAA services (Authentication, Authorization, Accounting). One of them is Hadoop and it’s Hortonworks implementation. It has it’s own Kerberos to be able to authenticate users from centrally managed domain and we were exploring options on how to point it into user base that we currently have within IPA domain.
Did you check https://mapredit.blogspot.fi/2016/10/freeipa-and-hadoop-distributions-hdp-cd... ?
Specifically, for Hortonworks' Ambari: https://community.hortonworks.com/articles/59645/ambari-24-kerberos-with-fre...
Alexander,
Thank you for those documents! Term “experimental” little scared me away, however I’ll give it a try, since we have a journey for the best, read future proof, option.
Regards, Andrey
On 5/30/17, 3:09 PM, "Alexander Bokovoy" abokovoy@redhat.com wrote:
On ti, 30 touko 2017, Andrey Ptashnik wrote:
Alexander,
Thanks again for your point of view of the problem! There are some Linux centric products on the market that require centralized AAA services (Authentication, Authorization, Accounting). One of them is Hadoop and it’s Hortonworks implementation. It has it’s own Kerberos to be able to authenticate users from centrally managed domain and we were exploring options on how to point it into user base that we currently have within IPA domain.
Did you check https://mapredit.blogspot.fi/2016/10/freeipa-and-hadoop-distributions-hdp-cd... ?
Specifically, for Hortonworks' Ambari: https://community.hortonworks.com/articles/59645/ambari-24-kerberos-with-fre...
-- / Alexander Bokovoy
On ti, 30 touko 2017, Andrey Ptashnik via FreeIPA-users wrote:
Alexander,
Thank you for those documents! Term “experimental” little scared me away, however I’ll give it a try, since we have a journey for the best, read future proof, option.
"Scared" sounds interesting given that you were otherwise willing to engage with unsupported feature anyway.
Another common use case is with acquisitions when you bringing on board team and their equipment that is also being managed by another IPA domain with respective products already integrated in it like OpenStack / OpenShift. You could survive with dual accounts, however not for long.
Regards, Andrey
On 5/30/17, 12:43 PM, "Alexander Bokovoy" abokovoy@redhat.com wrote:
So what use case you have in mind for such a trust?
-- / Alexander Bokovoy
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Andrey Ptashnik