[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Freeipa-devel] Ubuntu interests in FreeIPA
- From: Mathias Gug <mathiaz ubuntu com>
- To: Simo Sorce <ssorce redhat com>
- Cc: freeipa-devel redhat com
- Subject: Re: [Freeipa-devel] Ubuntu interests in FreeIPA
- Date: Wed, 22 Jul 2009 14:11:53 -0400
Sorry for not following up earlier on this, but this topic has been
recently brought on the Ubuntu freeipa team mailing list 
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.
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.
However one solution could be to use the uniq overlay to make sure the
uids are unique:
The Attribute Uniqueness overlay can be used with a backend database
such as slapd-bdb(5) to enforce the uniqueness of some or all
attributes within a scope. This subtree defaults to all objects within
the subtree of the database for which the Uniqueness overlay is config‐
For example, if uniqueness were enforced
for the uid attribute, the subtree would be searched for any other
records which also have a uid attribute containing the same value. If
any are found, the request is rejected.
That would also require some modification in the administration tools
by pushing the logic to generate a new user id from the slapd server
to the administration tools. The code responsible for creating a new
user should take into account the possibility that the ldap add
operation might fail because of an existing uid and update the uid
accordingly before retrying.
* 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.
* 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.
* 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?
It should also be noted that openldap support slapi plugins, which
means that some FreeIPA plugins could be supported in openldap (to be
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 .
>> : 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.
> 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).
Ubuntu Developer http://www.ubuntu.com
[Date Prev][Date Next] [Thread Prev][Thread Next]