[Kroupware] test server: ldap design

[Andreas Jellinghaus]

Hi Tassilo et all,

> So, we need k=kolab to have a well-defined place in the LDAP 
> 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. 
Adding a bindroot as configuration variable is only one line of
code.

clean up your code to make it a central variable, then
the next step (reading it from the config file where
also the ldap server is configured) is easy.

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

> > # postfix, kolab
> > # php, kolab
> 
> kolab server configuration, once needed per server, not domain, as said above

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

for example my ldap root could be dc=company,dc=co,dc=nz
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 ...

it's even necessary as i want to have one object per person.
If that person has email addresses within several domains, then
they are listed as several mailacceptinggeneralid attributes.

> In principle, if two servers merge one has to
> think about the administrative users anyway IMHO.
> Also, there are certainly not thousands of them.
> Personally I would not say that merging a couple of 
> administrative accounts is a pain in the a**
> But yes, you will not be able to click your way through.

the different namespace allows you to keep two seperate databases
in one server. which is not a step for mergin, but rather a step
for reducing duplicate servers.

> 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=max,dc=kde,dc=org,k=kolab
> 
> 2. Users with Email Account but invisible for anonymous LDAP users under
> cn=internal,dc=max,dc=kde,dc=org,k=kolab 
> (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=external,dc=max,dc=kde,dc=org,k=kolab.
> Think of it as global contacts.

still you could have
o=People,dc=max,dc=kde,dc=org
ou=Hidden,o=People,dc=max,dc=kde,dc=org
o=Contacts,dc=max,dc=kde,dc=org

whithout any problem.

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

And you could of course create even more subfolders like
ou=Marketing,o=Contacts,dc=max,dc=kde,dc=org
ou=Suppliers,o=Contacts,dc=max,dc=kde,dc=org

or some group hidden for most people (maybe contacts available to the
management only?)

Still i think that local users and remote contacts are different enough
to be put into two different subtrees.

> -> only one search base is needed for the outside world: 
> dc=max,dc=kde,dc=org,k=kolab

not different in my proposal, you can still search (with sub) over
the whole tree.


> My view is that the o attribute is meant to hold different data.
yep, maybe o and ou aren't the best choices to build these
subnamespaces. any better idea? namedObject?

> Yes I know. But where is the point ?
keeping searches smaller e.g. for the internal functions performed
by authentication, mailserver etc. smaller, cleaner, secure.

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

Andreas