for a preview of the changes, have a look at:

• https://github.com/TBits/KolabScripts/blob/Kolab16/kolab/patches/canonification_via_uid_pykolab.patch
• https://github.com/TBits/KolabScripts/blob/Kolab16/kolab/patches/canonification_via_uid_wap.patch

I am still working on changes to Roundcube and WAP changes for the login to work with just a UID.

I would like for these patches to be turned in to differentials, so we have the opportunity to not only comment on the semantics of the ticket (like we do here), but refer to items on a line-by-line basis as well.

The principle of a multi-domain is clear, or so I hope;

Distinguish between separate organizations such that no member of one organization accidentally nor incidentally discovers any information about any one other organization.

The way that Kolab can do this out-of-the-box, however, is something different from what one would want to run in a more sustainable, scalable environment.

By default, and with defaults, Kolab can manage to create a separate database / suffix / root dn. The discovery for an @domain.tld login can then be established procedurally.

OTOH, this has created multiple separate databases -- for which, each separately, replication agreements would need to be created on the master(s) and slave(s). This works up to increasing the number of semaphores available, and tweaking the not-so-proverbial shit out of each system involved.

Ultimately, one reverts back to using a single database / suffix / root dn for all hosted account entries.

This means no policy may exist on the actual information storage layer, about something like a uid attribute value being globally unique -- albeit it also means all uids could be realmed to begin with.

I need this to be viewed in this broadened context, and discuss this with the options that already exist, including those that may be obscured from the general public's view (by not having a separate blog post associated with them), so that we can help the original problem space with an appropriate solution (should it still need any).

I am about to upload the differentials with arc.

To describe the problem space we have at TBits.net: We have customers with their own domains hosted on a single Kolab2 instance. We have given them user ids that encode their customer number and therefore are unique across domains anyway, and they use those in their email clients. Now when we want to upgrade them to Kolab3, and have as little amount of support issues as possible, we want to be able to keep the user logins with just the user id.

We don't need this for Roundcube, and I don't have a solution for Roundcube at the moment anyway. I saw the new plugin wap_client the other day, that might be an option in the future. But not in this task I suppose.

Regarding your point of not discovering any information about any one other organization: The only information possibly being leaked is that the UID xyz is already used by another customer, when you try to create a new user with that specific UID xyz.

Basically we have already realmed the uids in our use case at TBits.net, by using the customer number in the uid. This makes the uid unique by convention, but not on the technical level.
You are right, my current approach is just on the level of the Webadmin to enforce unique ids across all domains, which does not cover the actual information storage layer. But I guess it is still better than just relying on "unique by convention".

One thing that my patch would fix for everyone: WAP currently does not check for unique IDs within a domain. Only when storing to LDAP, you get an unspecified error. Usually the UID is generated anyway and readonly, which means this has not been discovered yet. With my patch, the user would get a speaking error message about the UID not being unique.