[Kroupware] LDAP Design: Help appreciated

[Kervin L. Pierre]

for info on domain



Tassilo Erlewein wrote:
> Andreas and others,
> 
> I'm very interested in the LDAP layout topic
> 

Yes, me too :)

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

I do not understand what the 'bindroot' is.  Is it the bind DN?

> Am Mittwoch, 30. Oktober 2002 02:12 schrieb Andreas Jellinghaus:
> 
>>>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.
>>

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

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

Probably will.  There's going to have to be some sought of config file 
one way or the other ( to at least specify what LDAP server to point too 
).  I think the DN of the rest of the config information may as well be 
stored there.


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

I believe it does in some cases. 
ftp://ftp.rfc-editor.org/in-notes/rfc2247.txt

AFAIK, o=...,c=... was the X.500 way of doing things.  Problems arouse 
because there was not an effective way of managing registration.  eg. 
what if I claim I'm 'o=kervin,c=us'?

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.

> [...]
>>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 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"
...

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.

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.

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

That's why I think the best solution should be to be accomodating.

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

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.

I am seeing some overlap between what kolab is doing and what Cyrus 2.2 
already does.  Domain specific admins are already in Cyrus 2.2

>[...]
> 
> 3. Having visible and invisible E-Mail users and contacts
> 
> 

This could ( and my opinion should be ) done using ACLs.

>>>
>>>1. Regular Users with E-Mail functionality visible by using LDAP
>>>anonymously, under dc=max,dc=kde,dc=org,k=kolab
>>>

This is an LDAP rollout issue.  For instance, you can have a public LDAP 
address book server that only replicates addresses you want to be 
published.  Your clients intranet has the master LDAP address book 
server with all employees. ACLs can accomplish this as well.

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

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.

The 'o' attribute was used more often with the 'o=...,c=...' way of 
doing things.  With domain components, the 'o' attribute is hardly used 
in DNs, as far as I've seen.

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

Actually, in some cases it's more secure to give them permissions.  For 
instance, the LDAP server may not give anonymous user the rights to 
authenticate.

Most programs that authentication against LDAP give the user both 
options, bind-as-user-to-authenticate and 
bind-as-a-proxy-user-and-get-user-info.  The second way can be more 
secure, the first is simpler.  I'd vote for making both available.

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

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.

--Kervin