[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] Ubuntu interests in FreeIPA

From Mathias Gug:

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


ACIs are slightly different between 389DS and openLDAP, that would
require to change part of the installation and management tools.


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.


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.


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).


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/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]