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

[Aleksander Adamowski]

Simo Sorce wrote:
> DNs are written the other way around:
> Cn=users,cn=accounts,BASE_DN
>   

Correct, I was typing that in a hurry

>> On the market, there are at least 2 widespread established LDAP DIT 
>> structuring styles:
>>
>> 1)
>> dc=domain,dc=tld
>>  \- cn=accounts (or something similar)
>>     
>
> Honestly I never saw this in the wild.
>   

Older (but still quite recent) versions of eGroupWare required 
ou=accounts (yes, not cn, but I was typing this out of the top of my 
head too...):
http://www.egroupware.org/index.php?page_name=wiki&wikipage=AddresbookAccountsConcept

They also required special objectclasses. Luckily from eGW 1.4 on there 
are no such silly requirements.

The cn=accounts,dc=domaincomponent,... scheme was also hinted at in RFC 
4524, section 3.3:

dn: uid=kdz,cn=Accounts,dc=Example,dc=COM

They also use(d?) this scheme in Stanford AFAIK.

Also, and old version of Netscape Messaging Server I worked with had 
accounts in l=Cityname subtrees placed directly under base DN, which was 
formed from comain components.

>> FreeIPA follows the first one with some modifications (more levels - 
>> cn=accounts for example).
>>
>> Some proprietary, commercial software packages often make their own 
>> assumptions about some aspect of DIT structure.
>>     
>
> If they are just LDAP clients and they make assumptions on the DIT, they
> are buggy.
>   

Well, a large part of FreeIPA _is_ an LDAP client.
And it makes assumptions on the DIT.
So logically, it's kind of buggy from some point of view. I'll elaborate 
on that in the next point:

>> If there are too many such assumptions, the packages may become 
>> completely impossible to integrate with each other.
>> And FreeIPA makes extremely numerous assumptions, thus making it very 
>> hard to integrate with other products.
>>     
> FreeIPA is the master of the DIT, it provides a management interface,
> therefore needs to make assumptions.
>   

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.
Deep somewhere in the design process lies a silent, subconscious 
assumption that it is the central, most important system in the IT 
infrastructure.

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.

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

And why the management interface needs to make those assumptions? Apart 
from simplifying its imlementation, I see no real benefits of that. 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.
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.


>> IMHO there are too many products that assume too much with respect to DIT structure.
>>     
>
> True, clients should never do it, they should rely on configuration as
> much as possible. They may require a specific subtree structure if they
> have some custom schema, but at the very least their base DN should be
> configurable.
>   

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.

>   
>> Such products become mutually exclusive because of such assumptions - 
>> you can't use two products together on the same LDAP directory if they 
>> expect different base DN's, different acount containers etc.
>>     
>
> Base DNs should always be configurable, they must, as every LDAP
> instance have a different one. If they assume specific account
> containers they are simply buggy, unless they are very specific User
> Management interfaces built with a specific DIT in mind, but it is
> unlikely you need to use 2 different user management interfaces for the
> same tree, it is usually unhealthy anyway.
>   

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.

>   
>> The spirit of LDAP data model is to make its operations quite 
>> independent of directory structure - this is why you have the "subtree" 
>> scope for the search operation, and most of the time you launch the 
>> search without even thinking about how many levels are there below the 
>> search base and how they are structured.
>>
>> The point of the LDAP directory is also to centralize authentication, 
>> authorization and other data, organization-wide.
>>     
>
> In abstract, yes, then you have to deploy stuff, and you have to make
> choices.
>   

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.

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

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.

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


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

>   
>> Did you consider making some aspects of DIT structure configurable in 
>> FreeIPA?
>>     
>
> Some of it is configurable, in some cases the mgmt UI cannot cope, but
> everything else can.
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.

>  We had to simplify the management UI to be able to
> deliver anything. We plan to make it more flexible going forward.
> But we cannot just have a completely free form DIT.
>   
Oh, that answers most of my question... Notice, however, that if you 
implement configurability similar to what I've suggested above, you'll 
get practically free form DIT. It's doable, it's not so hard, LDAP 
itself is designed to make it easy!

>> The more configurable, the better. Not only WRT naming of relevant 
>> subtrees, but also WRT their toplevel elements' objectclasses - so e.g. 
>> one can have ou=People instead of cn=users. The most important thing 
>> being the configurability of the base DN...
>>     
>
> You should be able to create a ou=People in the tree, but current webui
> and tools would not cope with it at this moment.
> The core components (KDC, plugins, etc...) would have no problem with
> that, and the XML-RPC interface use DNs so you can build your custom
> tools if you want.
>   
Yes, because those components are indeed marvelous pieces of 
engineering. It would be nice if the ui and tools followed that design too.

>
> But if you want free hand with DIT, and even objectclasses and tools,
> then you do not want an integrated product like freeipa,
Why? 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?

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

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.

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl