[Kroupware] LDAP Design: Help appreciated

[Tassilo Erlewein]

Andreas and others,

I'm very interested in the LDAP layout topic


1. About the LDAP bindroot of the Kolab Server (which is now k=3Dkolab)

Am Mittwoch, 30. Oktober 2002 02:12 schrieb Andreas Jellinghaus:
> > So, we need k=3Dkolab to have a well-defined place in the LDAP=20
> > tree for administrative use. As the administrative tools rely
> > fully on ldap we simply need this well-defined root.
> You need to have at least one setting (hostname of the ldap server)
> and possible binddn and pw if you don't allow anon access.

are you suggesting that the bindroot is calculatable from
the server's fqdn at runtime ?

> clean up your code to make it a central variable,=20

that is already the case

> then the next step (reading it from the config file where
> also the ldap server is configured) is easy.

problem: the ldap server does not need to run on the same machine

we should probably soften the whole only-ldap-config-thing a bit and stic=
k=20
with a little config file containing ldap uri,bindroot, bind_dn, and bind=
_pw.

But _not more_, this path leads to nowhere (spreading the server config o=
ver=20
the filesystem and let bofh's holding the shit together - been there done=
=20
that)

We would solve the problem of elegantly bringing in a different ldap uri=20
(remote ldap server) as well.=20

I look into this with Martin and Achim.

> also i think it is possible to figure out all ldap rootservers
> automaticaly and then search for k=3Dkolab. I can use ethereal
> on gq to find out the details, if necessary.

agreed, we could place the server config objects in another=20
part of the tree. Having it at a well defined location is IMHO
not a big advantage. It's just we get for free that they only exist
once and do not need to check this. A check however is easy to =20
implement.

If we do the config file trick as stated above we can have
a well-defined and protected config subtree (k=3Dkolab, dc=3D..,dc=3D..) =
that=20
should not disturb anybody at all, right ? Andreas ?



2. About LDAP design in general


> ldap root dictates a namespace. that should not be seen as tied to a
> domain.

Look, there are other opinions about that issue. I don't say that
the argument you recall isn't a good one.

> for example my ldap root could be dc=3Dcompany,dc=3Dco,dc=3Dnz
> and all data is stored somewhere within that root, and still
> i can have email addresses for several domains such as
> company.co.nz, product.co.nz, alias.co.nz, oldname.co.nz ...

Sorry, I feel like getting 10 different opinions about that from 5 people=
=20
commenting..

How about if we make a little survey between the LDAP guru's
on the list. Please send your organizations or even favoured ldap layout=20
(no internal information, only structure-wise) and comments. I volunteer =
to=20
collect input and post a summary. And then let's discuss again. Please be=
=20
sure to add a few pro's and con's to make my life easier.
Keep in mind that we have a multi-domain future (separate users, visible,=
=20
non-visible email users, separate contacts, maintainers to do the daily
account maintenance).=20

The administrator group I think should not be domain-dependend.
An administrator can do bad things to the server. It doesn't make sense
to have it domain-wise, IMHO.

Well, maybe the LDAP guru's can in advance agree that a good choice for=20
Kolab's bindroot would be to have the fqdn ? (dc=3D,dc=3D... wise)



3. Having visible and invisible E-Mail users and contacts


> > This is a requirement brought in by the customers. And the more
> > I think about it (after implementing it ;-)) the more I like it.
> > Basically there are three types of Mail Users:
> >
> > 1. Regular Users with E-Mail functionality visible by using LDAP
> > anonymously, under dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab
> >
> > 2. Users with Email Account but invisible for anonymous LDAP users un=
der
> > cn=3Dinternal,dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab
> > (note that the "internal ..." subtree does not grant read permissions=
 to
> > anyone)
> >
> > 3. Address Book Entries, that only reside in LDAP (no Email-Users, no
> > Webinterface Login). They reside under
> > cn=3Dexternal,dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab.
> > Think of it as global contacts.
>
> still you could have
> o=3DPeople,dc=3Dmax,dc=3Dkde,dc=3Dorg
> ou=3DHidden,o=3DPeople,dc=3Dmax,dc=3Dkde,dc=3Dorg
> o=3DContacts,dc=3Dmax,dc=3Dkde,dc=3Dorg
>
> whithout any problem.

Do we have a majority of LDAP guru's agreeing to use
o,ou subtree to differentiate between visible and unvisible users
instead of namedObject ?

My problem is that this customer already uses o,ou otherwise.
I claim that this could be the case more often.=20

I still don't get why exactly you want to use o,ou for that stuff ?

> My basic issue is: the mailserver for example searches o=3DPeople,...,
> and has no reason to see the Contacts at all. They could be moved to
> that different location without any proplems.

The visibility feature is not a matter of guessing the right search base.
We want a subtree and we want a access rule protecting it.

> And you could of course create even more subfolders like
> ou=3DMarketing,o=3DContacts,dc=3Dmax,dc=3Dkde,dc=3Dorg
> ou=3DSuppliers,o=3DContacts,dc=3Dmax,dc=3Dkde,dc=3Dorg
>
> or some group hidden for most people (maybe contacts available to the
> management only?)

this should be always true, with any solution.=20

> yep, maybe o and ou aren't the best choices to build these
> subnamespaces. any better idea? namedObject?

sorry I'm confused. Wasn't that the thing you didn't like ?

> keeping searches smaller e.g. for the internal functions performed
> by authentication, mailserver etc. smaller, cleaner, secure.

I agree that authentication must be speeded up as much as possible.
This is very much performance relevant. We maintain an index over all=20
attributes we're keen on (uid, mail, alias).
My view is that limiting the search to subtrees doesn't matter as ldap
uses the pre-compiled index anyway.=20

> if you have the external=3D subtree, you always need to make sure
> contacts stored there are not mailObjects, have not uid=3D etc.
> Or limit the authentication requests accordingly.

our authentication procedures still work with anonymous bind.
We consider it a security advandage to not give Apache and
Saslauthd better permissions.

the webinterface enforces that no uid's are in the contact entries.
We could - to top this - arrange for a slightly modified inetOrgPerson
object not containing the uid at all. Will think about that.