[Freeipa-devel] Ubuntu interests in FreeIPA

[Howard Chu]

 From Mathias Gug:
> Hi,
>
> Sorry for not following up earlier on this, but this topic has been
> recently brought on the Ubuntu freeipa team mailing list [1]
>
> [1]: https://lists.launchpad.net/freeipa/msg00009.html
>
> Here are my comments mainly related to supporting openldap instead of
> 389DS in FreeIPA:
>
> On Tue, Jun 30, 2009 at 9:30 AM, Simo Sorce<ssorce redhat com> wrote:
>> On Mon, 2009-06-29 at 19:20 -0400, Mathias Gug wrote:
>>>  * replace 389 Directory Server with openldap.
>>>
>>>  The main reason being that the 389 Directory server is not available in
>>>  the Ubuntu archive yet (there is a work in progress to get it included
>>>  in Debian/Ubuntu) while openldap is already in the archive and the
>>>  currently recommended directory solution in Ubuntu.
>>>
>>>  My question is how tight are FreeIPA and 389 Directory Server coupled?
>>
>> Very, we use many features of 389DS and a good amount of plugins not
>> available for openldap. It would require a quite substantial amount of
>> work and testing just to port the slapi plugins.

OpenLDAP has supported SLAPI since 2002; if the necessary plugins don't work 
out of the box we can easily fix whatever's needed.

> Looking at freeipa-1.2.1/ipa-server/ipa-slapi-plugins/, there are 4 plugins:
>
>  * dna: Distributed Numeric Assignment plug-in
>
> I don't know of an openldap plugin providing the same functionality.

This can also be written easily as a native slapd overlay.

> However one solution could be to use the uniq overlay to make sure the
> uids are unique:

>  * ipa-memberof: IPA memberof plugin
>
> There is a similar overlay in openldap:
>
>       The memberof overlay to slapd(8) allows automatic reverse group member‐
>       ship maintenance.  Any time a group entry is modified, its members  are
>       modified  as  appropriate  in  order to keep a DN-valued "is member of"
>       attribute updated with the DN of the group.

re: nested groups, that support can be added if necessary.

>  * ipa-pwd-extop: Password Modify - LDAP Extended Operation
>
> There is a similar overlay in openldap/contrib:
>
>      The smbk5pwd that extends the PasswordModify Extended Operation to
>      update Kerberos keys and Samba password hashes for an LDAP user.
>
> However the code is currently written for Heimdal kerberos and should
> be ported to MIT Kerberos.

I would still be quite leery of this; the history of MIT Kerberos wrt thread 
safety has always been poor. The performance of the later "threadsafe" 
releases has lagged significantly behind Heimdal's the rare times it wasn't 
simply hung or dead. I guess if someone contributes the patches we'll 
integrate them, but I'm not going to write this on my own initiative until I'm 
convinced there's actually any technical merit in supporting MIT. Thus far I 
haven't had time to rerun the benchmarks to see how things have changed in 
current MIT releases.

>  * ipa-winsync: Windows Synchronization Plug-in for IPA
>
> I don't know of an openldap overlay that provides all the
> functionality of ipa-winsync. However the translucent overlay may be
> leverage to provide part of the functionality. What are the exact
> functionality provided by this plugin?

I haven't looked at this code yet but there are a few different things one can 
consider in terms of Windows sync. Even as a replication peer, passwords are 
not exposed via LDAP so you still need a separate password synch agent (e.g. 
http://www.microsoft.com/downloads/details.aspx?familyid=2BA5C443-D972-4B13-81EF-8AD20F779F51&displaylang=en 
)

This synch protocol is pretty trivial, we have an overlay for it (not yet 
released).

> It should also be noted that openldap support slapi plugins, which
> means that some FreeIPA plugins could be supported in openldap (to be
> tested though).

> Are there any other plugins that I've missed?

>> Second, OpenLDAP has experimental object level multimaster replication.
>> 389DS has attribute level multimaster replication and coflict
>> resolution. All the tools to manage replication setup would have to be
>> rewritten.
>>
>
> Noted.
>
>> ACIs are slightly different between 389DS and openLDAP, that would
>> require to change part of the installation and management tools.

> Noted.
>
>> There are probably other issues, that will pop-up once someone attacks
>> the problem.
>>
>> I have no problems in principle on supporting multiple LDAP servers in
>> IPA, but that will require a substantial amount of work.

> Agreed. The other option is bring in 389 DS in the archive. My main
> concern here is about resource to maintain the package once it's in
> the archive. As there already is a good ldap server in Ubuntu I'm not
> sure what we would gain for having *another* ldap server to maintain.

>>>  * different Directory Information Tree (DIT): replace with openldap-dit [1].
>>>
>>> [1]: https://launchpad.net/openldap-dit
>>
>> First of all I think you may be confusing/conflating DIT and Schema.
>>
>> In 1. the schema is incompatible with the MIT kerberos ldap driver as it
>> uses the heimdal schema.

We're taking steps to unify the MIT and Heimdal schema.

https://lists.anl.gov/pipermail/ietf-krb-wg/2009-July/007790.html

Since the response from the IETF folks has been sparse but mostly positive, 
we'll likely move ahead without waiting for further IETF response and just 
present the completed work in the near future.

> Agreed.
>
>> On the pure DIT side I don't see any reason to change FreeIPA DIT. We
>> choose the DIT carefully based on many factors, that is unlikely it is
>> going to change, it would only make things incompatible with no benefit
>> whatsoever. (OpenLDAP can use the FreeIPA DIT w/o any problem).
>>
>
> Agreed.
>
> --
> Mathias Gug
> Ubuntu Developer  http://www.ubuntu.com

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/