<div dir="ltr"><div><div><div>Re !<br><br></div>Thank both of you again for your answers, guys.<br><br></div>Simo, I would be very interested in this feature list in fact. <br>Do you know if there is a way to find it ?<br></div><div>I would really need it, it would help a lot.<br></div><div><br></div><div><div></div><div>Best regards.<br><br></div><div>Bahan<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 4:11 PM, Martin Kosek <span dir="ltr"><<a href="mailto:mkosek@redhat.com" target="_blank">mkosek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/13/2016 03:57 PM, bahan w wrote:<br>
> Re.<br>
><br>
> Thanks both of you for your answers.<br>
><br>
> Simo, MIT Kerberos and OpenLDAP can work on their own and provide the same<br>
> kind of service that we want from IPA, even if it is not embedded in<br>
> integrated solution like IPA.<br>
><br>
> I totally agree that IPA provides a lot of things but I am quite sure the<br>
> isolated softwares like MIT Kerberos for Kerberos, OpenLDAP for LDAP and a<br>
> cache client like sssd or nscd/nslcd can work.<br>
<br>
</span>It "can" work. But home grown solutions like that require non-trivial effort to<br>
even get started.<br>
<br>
As soon as you have more requests on such home grown infrastructure, you will<br>
need to implement enhancements (like something cert or DNS related). At that<br>
moment, you may realize you are re-implementing what FreeIPA may support<br>
already. FreeIPA project was started for a reason :-)<br>
<div class="HOEnZb"><div class="h5"><br>
> Alexander, when I mention migration, I think of the following actions :<br>
> 1. Take the principals that we have for the KDC and recreate them in an MIT<br>
> Kerberos KDC architecture<br>
> 2. Take the users/groups/pwpolicies in the LDAP and recreate them in an<br>
> openLDAP architecture<br>
><br>
> Do you know if there is other things necessary to recreate in the LDAP or<br>
> in the KDC ?<br>
><br>
> Additionnaly, do you have a list of points which could help to convince to<br>
> keep the freeipa architecture ?<br>
><br>
> Best regards.<br>
><br>
> Bahan<br>
><br>
> On Wed, Jan 13, 2016 at 3:33 PM, Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com">abokovoy@redhat.com</a>><br>
> wrote:<br>
><br>
>> On Wed, 13 Jan 2016, bahan w wrote:<br>
>><br>
>>> Hello Simo !<br>
>>><br>
>>> For the reason :<br>
>>> The production team wants to use only the two components openLDAP and MIT<br>
>>> Kerberos, possibily on different servers.<br>
>>><br>
>>> For the explanation :<br>
>>> They want to install only MIT Kerberos and openLDAP.<br>
>>> We already have an existing FreeIPA installation, with users, groups,<br>
>>> principals, pwpolicies.<br>
>>> We would like to migrate this to an openLDAP for the users, groups and<br>
>>> pwpolicies, and to another MIT Kerberos for the principals (hope I'm not<br>
>>> forgetting anything).<br>
>>><br>
>> FreeIPA provides own LDAP driver for MIT Kerberos that relies on IPA<br>
>> LDAP schema. Standard MIT Kerberos LDAP driver does not support IPA<br>
>> schema.<br>
>><br>
>> Additionally, 389-ds LDAP server FreeIPA uses is coupled with about two<br>
>> dozen additional plugins. These plugins either don't exist for OpenLDAP<br>
>> at all or have different behavior and rely on different LDAP schema.<br>
>><br>
>> In short, if you move the data from 389-ds to OpenLDAP, it wouldn't be<br>
>> used by MIT Kerberos LDAP driver because it doesn't know about that<br>
>> data, and OpenLDAP server will not have the same behavior as expected by<br>
>> IPA clients (SSSD) for IPA-specific mode.<br>
>><br>
>> Whatever your production team is thinking about this move, it is most<br>
>> certainly not properly thought out.<br>
>><br>
>> --<br>
>> / Alexander Bokovoy<br>
>><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>