[Kroupware] LDAP Design: Help appreciated

[Andreas Jellinghaus]

Hi Tassilo et al,

[ldap root (k=kolab)]
> 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 stick 
> with a little config file containing ldap uri,bindroot, bind_dn, and bind_pw.

So every component that needs to access ldap, has at least
a server (and maybe a port), and depending on the configuration
also bind_dn and bind_pw. why not add ldap_root?

All ldap operations could either use the ldap_root to create
a dn (such as for creating a new object), or use a search
withing the ldap_root (or some subtree of it) to find the dn.

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

hmm, yes all setting described could be put together in one single
uri statement, i guess, but that is not necessarily easier
to understand.

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

yes, thats the way to go.

> 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=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 ...
> 
> Sorry, I feel like getting 10 different opinions about that from 5 people 
> 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 
> (no internal information, only structure-wise) and comments. I volunteer to 
> collect input and post a summary. And then let's discuss again. Please be 
> 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, 
> non-visible email users, separate contacts, maintainers to do the daily
> account maintenance). 

my layout is:
 - every organization has to pick on central name. This should be a
   domain name (so uniqueness is guaranteed, and it is a familiar name).
   for example asterisk.co.nz.
 - that domain name is transformed into an ldap root by using dc= style.
   for example dc=asterisk,dc=co,dc=nz
 - all data is stored under that root, no data is stored outside.
 - account data is stored in a subtree. currently this is o=People,
   but i know this could be improved. Storing in a subtree is done to
   seperate it from other data such as customers address book.
 - all other data is stored in different subtrees.
   for example o=Customers. again "o=" might not be the best idea.

Now a company might have several domains such as product1.co.nz
or oldcompany.co.nz etc. People in the company can have any number
of email addresses, in the main domain or in other domains.

The important issue is: there is no assumption that people will
have one local_part in all domains a company holds.
for example charter@domain1 and charter@domain2 might end up
with completely different people.

continuing my ldap design:
 - there is exactly one ldap object for every person in the company.
 - the dn is build using the common name, for example
   cn=Andreas Jellinghaus,o=People,dc=asterisk,dc=co,dc=nz
 - all email addresses to be delivered to a person are stored in
   the mailacceptinggeneralid attribute (argh, what an awfull name).

so i might end up with mailacceptinggeneralid:
Andreas.Jellinghaus@asterisk.co.nz
andreaj@asterisk.co.nz
support@mailserverproduct.co.nz

but i will not get
support@firewallproduct.co.nz. even though the mailserver is managing
that domain as well.

so i have email addresses in several domains. but no matter how many
domains there are, i always only have one object, and thus all data
is stored in one ldap domain.


per domain data would cause ldap roots
	dc=mailserverproduct,dc=co,dc=nz
	dc=asterisk,dc=co,dc=nz
	dc=something,dc=co,dc=nz

so if you wanted to have domain specific configuration in the specific
ldap root, you would create several items. the questions is then:
where would be my main object? where would be my password stored?
we agree the password should be stored only in one location.

so this is why i don't want several object per user, only one.
and that means i need to pick a ldap root, and place all data
under that root. but i still think thats ok.

[naming a subfolder]
I made my subfolders with "o=". that might be not a good idea.
I know it and i'm open for suggestions. Please let me know.

a bit related to this is:
Also i think any software should be configurable where to place
objects and how to construct the dn for new users.
I saw several ldap webtools that insisted on formats
such as "dn: uid=234,dc=domain,dc=co,dc=nz"
which made the software useless for me (there is no numeric user id).

[place what where]
still i think it is ok to place local objects / people / ...
in one subtree, and external objects in a different subtree.
but can be dived into even more subtrees (for admins, internal,
locked users, ...).

putting local people into xyz and remote into o=remote,xyz
is IMO not a good idea. security wise i want a searchtree where
i will only find local people.

and for organization, if people start using several subtrees
under xyz, the differnce of subtree for local persons
and o=remote,xyz which has non-local persons could get overseen.
making the difference more explicit is IMO better.

Still searching all contacts (local and remote) is quite easy
by looking at dc=company,dc=co,dc=nz and searching for 
objectclass=person or an attribute such as firstname, lastname, mobile
phone...

for the point of view of administrating the security / acl, 
splitting into o=People and o=Contacts (or any two different names),
the maximum damage is two acl rules instead of one, but more likely
it is an easier and clearer structure. For example changes
to the o=Contact / external namespace could by done by several
normal people, whereas o=People (local people) is usualy under
control of admins only, except for a few attributes people
can edit them self (like phone numbers or home address).


[where to put the administrator]

i have put the admin as 
cn=Admin,o=People,dc=asterisk,dc=co,dc=nz
and made him all the objects as a normal person,
so it can have email addresses and imap folders
like everyone else. Or people can move the email
aliases to some shared folder or whatever they want.

Giving people in a subfolder such as
ou=admins,o=People,dc=asterisk,dc=co,dc=nz
would be also ok,

or keep the admin anywhere, but inside
dc=company,dc=co,dc=nz. But please, don't create
something like "cn=admin,dc=de" (maybe not even
if you are working at denic - the .de registry).


[authentication]

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

yes. but still testing username and password is done
by anon binding, finding the DN by using the username,
and then binding as that DN and the password supplied?

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

i wonder what openldap's internal rules are, whether a object
is good enough for authenticate bind or not. looking at the 
userPassword attribute? or some objectclass like simpleSecurityObject?
maybe it's also possible to limit bind requests to a certain
base dn?

i haven't seen anything in the documentation on this.

Regards, Andreas