[Kolab-devel] Active Directory synchronization in Kolab 2

[Bernhard Reiter]

Am Montag, 19. September 2005 14:25 schrieb Henning Holtschneider:
> On Monday 19 September 2005 09:55, Bernhard Reiter wrote:

> > It would be a small project to develop this,
> > so if  a customer of the Kolab-Konsortium wants this,
> > we might have it pretty fast.
>
> Ok. I've got two customers who are interested in Active Directory
> integration but their installations are too small to have them fund the
> entire development. We have already written a COM plugin for the Active
> Directory MMC so that's it's possible to configure the Kolab-specific LDAP
> attributes from there. There were two outstanding issues with Kolab 1 that
> lead us to halt the project at that point:
>
> 1. changing the username and/or email address in the AD resulted in the
> mailbox on the Kolab server to be deleted and re-created. This could be
> prevented when using the AD UUID as the UID on the Kolab server. It didn't
> work well with Kolab 1 (ZFOS) because the custom UIDs had been removed, but
> with Kolab 2 it shouldn't be a problem anymore.

It might be easier with the Kolab2 Server, but the primary email address is 
still pretty important as it lives inside the appointments for this and other 
users. Thus you would need to act like moving a user mailbox (see raw-howto)
and then have and set and alias for the old primary email address.

> 2. As far as I know, the plaintext password is needed to log into the
> POP3/IMAP server (the connection is being encrypted, but the password is
> still sent "as is"). But the AD user password in only available encrypted
> on a Windows machine. So, for true AD integration on the client side, we
> either need some kind of Kerberos authentication on the IMAP server or the
> integration stops at the Toltec Connector password dialog. 

Are you talking single sign on here or just that authentification has to work
with the AD saved password from the Kolab side?
Let's say AD uses its own hash, then we would need to enter that hash into 
SASL (or so) and then all services could authenticate direct to AD.
There is no need for Kolab to have the plaintext password from the AD,
unless I am missing something.

> This doesn't 
> sound to grave at first, but most companies have password policies in place
> that force the users to change their passwords every couple of weeks. 

... though that is not a good policy in many cases as it faces the quality of 
password to go down.

> With 
> the current way of authentication, the users would have to change their
> Toltec password manually each time they change their AD password. That's
> impractical.

Same for the KDE Kolab client where it might even be saved in several places.
So a ticket system would be very cool to have, but I fear it will be bigger 
development step.

> Anyway, I will keep an eye on this as time permits. But If anyone out there
> can provide funding to take this half-finished project to the checkered
> flag, please contact me!

We from the Kolab-Konsortium try to find funding for a couple of nice features 
and implementation improvements.  Of course it also helps if more companies
subscribe to our 3rd level service to help funding the basic maintenance 
costs.

Bernhard