[Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA?

[Simo Sorce]

On Sat, 2008-07-05 at 01:43 +0200, Aleksander Adamowski wrote:

> It seems to me that FreeIPA makes the same mistake that eGW made - 
> assumes that if it is _the_ server (not _a_ server), then it doesn't 
> have to behave like the other LDAP clients.

Yes, we make that assumption.

> Deep somewhere in the design process lies a silent, subconscious 
> assumption that it is the central, most important system in the IT 
> infrastructure.

Indeed.

> In today's environment hardly any system can assume such privileged 
> position.
> Especially a project like FreeIPA, which is currently starting up and 
> needs first to gain ground in _existing_ infrastructures, with 
> established directories which are already structured and filled with data.

We know right now it is very difficult to do a migration, it was a
conscious decision.

> Also, if you look into the literature, and I think the most 
> comprehensive material is IBM Redbooks' "Understanding LDAP", it's 
> advised that the directory be structured according to organizational, or 
> geographical criteria - most importantly, according to criteria which 
> are unlikely to change significantly with time:
> http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/common/html/wwhelp.htm?context=SG244986&file=10-25.htm

We do not think using organizational OUs to be a good idea, it is a very
inflexible method. Directory Server can present views to other
applications (search about views in RHDS documentation) so if you really
want to see a virtual view of an organizational structure you can do
that.
We think that keeping the tree flat is the best course going forward and
we are planning on providing powerful grouping mechanism to help admins
organize their entries.

> We all know that IT systems come and go and most organizations will be 
> reluctant to base their identity management infrastructure which insists 
> on bending the directory structure to its technological quirks.

Experience shows that is not really true :)

> And why the management interface needs to make those assumptions? Apart 
> from simplifying its imlementation, I see no real benefits of that.

We needed to start with a manageable task, simplifying the
implementation, but most importantly the user interfaces was a primary
goal.

> I understand that it might be complex in implementation, but I think this 
> configurability will pay in much faster adoption of FreeIPA in the wild.

So far users are *gald* they do not have to learn LDAP and Kerberos and
don't have to make choices they have no way to understand, at the same
time I know some LDAP experts can be abit frusrated because we made
different choices from their preferences, but LDAP experts are a
handful, while people that need a centralized solution that just works
are the majority. We decided to help fisrt the people that *needed* the
most help. LDAP experts can easily build their own thing, we decided to
make them happy a bit later where and when possible.

> Currently FreeIPA is only usable for infrastructures built from scratch. 
> That's a very serious limitation, one which can kill the project in the 
> long term. FreeIPA is a newcomer, it has to be existing infrastructure 
> friendly.

It may slow a bit adoption in places where they already have a good
infrastructure (which are few). I am fully a ware of the limitations for
migration, but we had to make choices to deliver anything.

I welcome your criticism tho, you make good points, and I agree with
most of them.


> I don't think the distinction you make here between clients and FreeIPA 
> is justified. The LDAP directory in an organization inevitably evolves 
> into a shared database, and many distinct applications use _and_ manage 
> information contained there.
> FreeIPA needs to play well with others and should assume as little 
> control over the directory, as possible - only the necessary minimum to 
> do its job properly.

The minimum is what we did for now, we can relax yet some bits, but
anything you make configurable becomes something you have to deal with
at install AND replica time. It makes also future upgrades more
difficult.

> Well, in our company we are currently using a few interchangeable 
> management interfaces, the most widely used is our own custom one 
> (another one is phpLDAPadmin) and it doesn't assume a structure - it 
> lets the admin pick the container in the DIT where he wants a new object 
> (e.g. account) to be placed, with some configurable restrictions (the 
> top DN for accounts, and so on). It's a Perl-Gtk2 GUI.

yup phpLdapAdmin does not assume structure, but it assume that to set it
up you know LDAP very well, and you know how to customize phpLdapAdmin
itself in case you need to create users in a way that is not templated
already. That is not the kind of interface we wanted to provide to
people that do not know anything about Kerberos or LDAP, or the way we
mated Kerberos and LDAP together. We are trying to help *non*-experts
with first releases, and slowly provide flexibility to experts when we
can.

> That's true but I got the impression that FreeIPA is a project in an 
> early stage of development, and it's still possible to undo design 
> decisions which may prove to be catastrophic later on.

Nothing is fixed in stone, good people, with good ideas, and some
patches can always help steer the project in better directions, provided
our fundamental goals are not betrayed.

> I don't see why most aspects of its DIT structure couldn't be turned 
> into configurable options.
> 
> The base DN of the directory could be a config item.
> How the "accounts" subtree is named too.
> Or if it's present at all - one can make the location of users, groups, 
> trees, computers and other subtrees configurable, and the default 
> configuration would place them all in the cn=accounts container so that 
> it's identical to the current state.
> 
> E.g.:
> objectclass: ipaGuiConfig
> ipaUserAccountSubtreeRDN: cn=users,cn=accounts
> ipaGroupAccountSubtreeRDN: cn=groups,cn=accounts
> ipaComputerAccountSubtreeRDN: cn=computers,cn=accounts
> ....
> ipaKerberosSubtreeRDN: cn=Kerberos
> ...

This is a very good suggestion actually, and to be honest I have been
thinking of adding something similar in v2 so that clients can
auto-configure themselves too.

The problem is that to change this stuff you would need to make it
manually or substantially change the ipa-server-install script.

If you volunteer to send patches to ipa-server-install so that the
default installation will not require any more prompts then what we
require now in v1, then we could certainly extend IPA to handle these
configuration options.

> Note that above configuration is 100% compatible with FreeIPA 1.0.
> The ipaGuiConfig object could be placed by default in cn=etc subtree, 
> but it should work if it's anywhere in the tree - after all, the system 
> can search for objectclass=ipaGuiConfig, right? No need to make 
> assumptions here.

yup, not making assumption, but you have to store the kerberos subtree
DN in the server's /etc/krb5.conf file, so this is not something you can
change at will. You must install IPA from scratch with a specific
subtree and stick with it (altrhough it could be configurable so not
saying we cannot let users that know what they are doing change the
defaults before installing the first IPA server instance).

> Now one can use it to marry FreeIPA with a preexisting directory, e.g.:
> 
> objectclass: ipaGuiConfig
> ipaUserAccountSubtreeRDN: ou=People
> ipaGroupAccountSubtreeRDN: ou=Groups
> ipaComputerAccountSubtreeRDN: cn=computers
> ....
> ipaKerberosSubtreeRDN: o=mit
> # Note that o=mit  is the example from official MIT Kerberos 5 
> documentation! Lots of systems in the wild use this.
> ...

Yes and no, a pre-existing directory will need to have the right
objectclasses on users and groups, and then we have things like the
memberof and DNA plugins, the fact we decided to use rfc2307bis with
groupOfNames and the member attribute instead of the old memberUid
attribute of the classic rfc2307 posixGroup objectclass, and so on.

>  you just want a
> > bare LDAP tree to manage they way you want. In this case you can use
> > Directory Server or OpenLDAP, and spend the weeks or months it will
take
> > to make your own custom integrated product.
> >   
> This is the other extreme - on one end you have FreeIPA installer
that 
> sets up something from scratch and it is guaranteed to work. On the 
> opposite, you have perspective of taking all the bits and setting
them 
> up together, FreeIPA-style, by hand.
> 
The DIT is not everything.

> >> On the other hand, its design makes it hard to unify and centralize 
> >> because it's hard to integrate with other LDAP-based systems because of 
> >> its strict requirements pertaining to directory structure.
> >>     
> >
> > In IPA We control and define the DIT.
> What for? Why do we do this?

To simplify the problem mostly.

> Apply Occam's Razor here. What does that buy us? Some simplification of 
> management tools implementation. But they could be made to use 
> configuration variables where now they have hardcoded values. Yes, it 
> costs development time.

That's it, we could try to make the perfect super-configurable tool, and
release in 10-15 years, or we can try to make a good tool, with some
'restrictions' and release it in a year, and then work on improving it
where people demands and usage patterns show there is a problem of some
sorts. We choose to follow the latter, in classic Open source style:
release early, release often.

> Are there any other reasons for controlling the DIT?
> 
> >  Most software I know of, can cope
> > with it,
> true.
> >  some is buggy,
> Yes, but note that you are creating yet another piece of this kind of 
> software right now. It doesn't have to be this way.

We are not building a management interface for generic directories, we
are building an integrated IdM project. Flexibility is only one of the
things we want to achieve but there are other priorities too, often more
important, at this stage, than flexibility.

> > and some we are incompatible with (we use of
> > rfc2307bis and groupOfNames for example, which not all software still
> > understand).
> >   
> 
> Well written software should ignore the stuff it doesn't understand and 
> make the best effort to still work with the data it understands. That's 
> why the x.509 standard defines a concept of critical and non-critical 
> certificate fields.

Sure, but if your OS can't see group members it simply does not work.
The groupOfNames/member thing is one of those critical things and
luckily, with the noticeable exception of Solaris (and we are working to
address this problem), all other free or proprietary OSs seem to support
it.

> Well, I understand that the current version of FreeIPA cannot cope. I'm 
> concerned with its future development direction. Are there plans to make 
> it configurable? I think it's very important for future adoption of the 
> project to do it.

Yes we are sensible to your kind of requests, especially if someone
provides patches :)

> I view FreeIPA as a preconfigurator for 
> LDAP+Kerberos+Radius+NTP+some other future subsystems (DNS?), bundled 
> with easy to use management tools. It would be marvelous if it could 
> preconfigure all this given a preexisting directory, provided that you 
> point where in that directory are places you want it to put its stuff, 
> and that it tries to reuse existing data (e.g. converting ordinary 
> posixAccounts or inetOrgPersons to full-featured accounts). It's doable, 
> IMHO, and would tremendously benefit FreeIPA's appeal.
> 
> Am I missing something?

No, only patches :-)
The task you propose would be fantastic, but it would require a lot of
code, we would be happy to add it to IPA, but we cannot do everything,
the code is available, and contribution is very welcome, so if someone
really badly wants that and can start contributing patches to go in that
direction we will be happy to accept them and help.

> But the components of FreeIPA could be used for intermediate solutions - 
> you'd use them on existing infrastructure, they'd make their best effort 
> to set everything up given some initial configuration options (the DIT 
> structure I were talking about) and convert the contents of DIT, then if 
> all goes well - you got lucky and got a working system, otherwise you'd 
> simply have to tweak it to make it work. Which would still be much less 
> work than setting it up manually from scratch.

Yup, we nothing against this, except time :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York