[Kroupware] LDAP Design: Help appreciated

[Andreas Jellinghaus]

Hi Pierre,

sorry "bindroot" is the wrong name.
I should have used "basedn", the base for all
access of other objects, searches etc.

> For kolab's internal use, why not 'cn=kolab'? Why define a new attribute?

hmm. good question. i guess it has to do with the attributes?
ldap-servers: ldap://127.0.0.1:389
ldap-search-base: k=kolab
fqhostname: max.kde.org

but i don't see why these are in the ldap,
or why they are usefull. once you connect to the
ldap and read these attributes, you already know all of this.

[domains9

ah, i should reword: even if you have several domains,
it's still a good thing to keep all data under one
ldap base build from one domain. see my other mail
with examples on this.


> By connecting the organization's suffix to it's unique domain, 
> uniqueness can be guaranteed. eg. there is only one 'dc=kde,dc=org' in 
> the world.

yep. that's why i want everything stored under a domain root,
not k=kolab. but on the other side, have only one object per person.
so if i have several email addresses, these transform into a multi value
attribute, even if the email addresses are in different domains.
still one object, not several.

> > [...]
> >>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 ...
> > 
> 
> When you say 'email addresses', do you mean 'aliases' or 'mailboxes'?

i purely speak of the receiving side, not about what to do
with the mail. (mailacceptinggeneralid is sucha horrible term,
but it is more accurate that aliases i think.)

"mailboxes" implies the mail is stored in a mailbox (or several). for
distributions lists this is not true, the mails accepted would be
forwarded to a list of email addresses. From my perspective
the difference between distribution list and normal person is
the content of "maildrop". (and neither distribution lists nor shared
mailboxes need a uid: and userpassword: attribute).

> I have a similar setup with Cyrus 2.2 in an web hosting environment.
> 
> What I've done is to separate the suffixes, and have a suffix for every 
> virtual domain. eg. with OpenLDAP slapd.conf...
> 
> suffix "dc=company,dc=co,dc=nz"
> suffix "dc=product,dc=co,dc=nz"
> ...

will you create that way two objects, if i have email addresses in
both domains? i want only one object to make it easier to keep
all data visible, consistent etc.


> 
> You may still need a 'catchall' organization unit.  I have one for 
> sendmail, ie. "ou=sendmail,dc=mydomain,dc=com".  Every alias and mailbox 
> has an entry in there, eg. 
> "cn=user@somedomain.com,ou=sendmail,dc=mydomain,dc=com" will give 
> sendmail the routing information for delivering mail for that alias.
 
I have all data stored under one ldap base.
But the dn: is build by cn: Firstname Lastname.
email addresses are avoided, as they are not unique.

> Any program that needs to authenticate a user would need the logic of 
> either looking up the user in the 'catchall' ou, or figuring out the 
> user's suffix by their mail address, or a similar mapping.

i'm creating a unique value "uid" for every user, so
people use that username to authenticate. that username
is also used to create mailboxes user.uid by default.

> Having a domain dependent admin would be a great feature for ISPs.  Then 
> the administration of the domain can be potentially handed out to 
> customers who want it.

hmm. how would you configure postfix for that?
getting a mail for usera@domaina.com, it would need
to search in a different ldap tree or server than for
userb@domainb.com. 

i don't see how postfix can do that / you could allow
people to set ldap attributes themself without getting
security issues.

[acls]
it's easier to configure them if you have a clean structure,
right?

for example i consider it more difficult to configure
	dc=max allowed for authentication,
		but dc=external,dc=max not allowed,
			but dc=internal,dc=max allow.
than saying
	o=People	allowed for authentication
	o=Contatcs	not allowed for authentication.

Yeah, it is only a minor issue. i'm a nitpicker :-)


[subpart nameing]
> ftp://ftp.rfc-editor.org/in-notes/rfc2256.txt
> 
> I think the 'o' attribute is 'organization', ie the organization that 
> the DN belongs to will 'ou' is the 'organizational unit'.
> 
> In that respect 'ou' is the correct attribute.

hmm. i think neither o= nor ou= is a good choice for building
a dn. dc= implies a domain component, which is not true.
is there something neutral (i.e. "we divide the ldap into
subtrees, but no special meaning is implied by that, it's mostly
for management and access control configuration") ?

using o and ou= as attributes is ok (like using address or
fax or any other attribute we don't care about except when
looking at address books).

> Extend inetOrgPerson if needed, but I don't thinking modifying it would 
> be a good idea.  This would definately break some sites.
> 
> Just make the uid any unique info, eg. the contact mail address.

ah, two questions two discuss: 
 - why build dn's with uid? why not cn or somethening else?
 - why use the email address as uid? why not some old fasshioned
   username? i consider it quite normal to give users one username
   and any email address they want (within reason).

my university even used "u[a-z0-9]{3}" for usernames,
so i got "urcr", the person who got an account right before
me for "urcq", the next person got "urcs". Very unconventional,
but quite useful. Your email address would be urcr@rz..., but
you could get also lots of aliases like Firstname.Lastname 
(or something similiar as there are some persons with the same
Fistname and Lastname).

Andreas