[Kolab-devel] Kolab and Novell eDirectory, Active Directory, Generic LDAP

[Stephan Buys]

Great. Answers below.

On Tuesday 07 October 2003 12:34, Klaus Steinberger wrote:
>  > We would be very interested in collaborating with you, as this work
>  > should have similar results.
>  >
>  > I suggest you join the kolab-devel mailing list and we can discuss the
>  > technicalities on there.
>
> Ok, I joined already kolab-devel.
>
> I'm very willing to collaborate.
>
> I will have a meeting with the edirectory developers of the university
> somewhere in next weeks. As we want to have an dedicated eDirectory
> Server for our faculty, the university staff will have to develop some
> DirXML driver for loading of our part of the directory. I will talk with
> them also about the kolab.schema integration into eDir.
>
> Sincerly,
> Klaus

As far as I see it the major technical hurdles are:

1) Getting the Kolab schema into the directory. Martin - are the kolab servers'
OIDs registered with the IANA? Luckily Active Directory 2003 support the 
inetOrgPerson objectclass, which is what is used in Kolab.

2) Detecting changes in the Directory. At the moment the Kolab daemon listens
on the LDAP replication port to detect changes in the directory. We are only
beginning our investigations into Active Directory, but this will be important for
eDirectory as well. You want to avoid a polling scheme as far as possible.

 - Major events include:
	- Addition of users
	- Deletion of users (at the moment the Kolab backend checkes for a
	DELETED attribute, after which it deletes the Imap mailbox and deletes 
	the directory object)
	- Modification of user object (specifically the userquota attribute)

3) Decoupling the DN's where user object are stored. It is not necesarry to worry
about user classes with AD or eDirectory as the directories themselves handle 
permissions. 
We were thinking about adding a "user_dn" attribute to the kolab object, which 
in turn will point to all the dn's where the kolab backend should search for user
objects. As you may be aware Kolab uses a static approach to the user dn's at
the moment. this is less than ideal for existing directories.

4) Extending the user interface of the directories. In  AD (and I am sure in eDirectory)
you are able to extend the context sensitive menus that relate to object. This will
allow us to create a Kolab menu when right' clicking on the server objects as well
as the user object. Giving one the ability to select wether a user object can have
a Kolab mailbox.

5) Bootstrapping. Getting the Kolab server up and running. We should be able to 
specify during the bootstrap script process that the server should use an alternate
directory for its work. 
Some things that need to happen: Interrogation of the LDAP directory to check that
the require schema is supported, etc.

Well, that was of the top of my head. Anyone have anything to add? 

Regards,
Stephan Buys

(I copied Dieter and Mike based on earlier LDAP discussions that we had on the list)