Kopano with USC *AND* MS Active Directory

[mculibk]

Hi there!

After some naive experiments I’m a little “stuck”…

Let me explain the environment in short.

I have an existing MS ActiveDirectory with installed Kopano schema extensions and MMC plugin. This MS AD is used as a “master” domain/ldap.

Next I have a UCS 4.3 system running “integrated” with the MS AD (ucs running AD Connector (on ucs master) and MS domain-member roles on other UCS servers (with ucs backup/slave roles)). UCS is serving other applications and services besides “samba member-server”.

Now, I would like to throw Kopano in the mix…

The idea was to install Kopano on some UCS servers and use the local open-ldap for better performance and “greater hackability”/flexibility.

After setting/changing some Kopano attributes in MS-AD with the Kopano MMC plugin I hoped the UCS system would propagate the attributes/changes “back” to open-ldap… but that’s not the case.

If I install Kopano on UCS through UCS Apps then it’ll extend the local (ucs) ldap schema and add the required attributes… but I think that’s not the right way. I think I would end up with a Kopano running off the UCS ldap “only” so would have to manage all the Kopano related attributes through UCS web portal/console - which is not what I want.

Users are mainly managed with MS AD tools (creating, deleting, changing passwords, groups…) and I would like to avoid having “split administration” (manage accounts in AD and then manage kopano related stuff in UCS web).
Also, the UCS management is somehow “limited/different” compared to the MMC plugin…

Ah, and multi-tenancy is a requirement - which is easily done/configurable through the MMC plugin (setting the “kopano company” attribute) which I could not find in the UCS admin counterpart. And handling different mail addresses (per account and different domain) in UCS web admin is quite limited/problematic.

Does “using” local ldap make any sense (perfromance/feature wise)? What is the “penalty” of hammering one DC with all Kopano requests?
I suppose it would be much simpler/easier to just install Kopano “standalone” (not through UCS Apps) and configure it to use the MS AD directly?

Any suggestions are more than welcome!

Regards,
M.C

[fbartels]

Hi @mculibk,

@mculibk said in Kopano with USC *AND* MS Active Directory:

If I install Kopano on UCS through UCS Apps then it’ll extend the local (ucs) ldap schema and add the required attributes… but I think that’s not the right way. I think I would end up with a Kopano running off the UCS ldap “only” so would have to manage all the Kopano related attributes through UCS web portal/console - which is not what I want.

this is though afaik exactly the scenario the appcenter in UCS was designed for. You have your AD and you want to easily run an app on UCS. Schema extensions of the UCS apps may not be available on Windows, or more generally you do not want to pollute your AD with these additional attributes. Therefore all app specific user configuration is performed only on the UCS side.

If the ad should be the leading system then this is possible in Kopano as well. Just make sure to perform all configuration changes through the UCR (univention configuration registry) so that these are preserved when doing updates.

@mculibk said in Kopano with USC *AND* MS Active Directory:

Ah, and multi-tenancy is a requirement […] which I could not find in the UCS admin counterpart

The UMC is quite flexible and could (and has been done so in the pst) be extended to handle the multi tenant configuration of Kopano.

@mculibk said in Kopano with USC *AND* MS Active Directory:

Does “using” local ldap make any sense (perfromance/feature wise)?

You would of course reduce latency a bit, because you do not need to go over the network for logins and lookups. From a feature perspective you would not loose/win anything by using by having a non local user source.

@mculibk said in Kopano with USC *AND* MS Active Directory:

What is the “penalty” of hammering one DC with all Kopano requests?

as said before “latency”, but this is negligible unless we ware talking about thousands of highly active users. But it also does not have to be a single DC. By putting a load balancer in between you can also distribute these requests to a number of ldap servers.

@mculibk said in Kopano with USC *AND* MS Active Directory:

I suppose it would be much simpler/easier to just install Kopano “standalone” (not through UCS Apps)

As long as we are talking about UCS I would always recommend to install apps through the appcenter as these also take care of some configuration. But its of course also possible to use a non-ucs system for this.

[mculibk]

this is though afaik exactly the scenario the appcenter in UCS was designed for. You have your AD and you want to easily run an app on UCS. Schema extensions of the UCS apps may not be available on Windows, or more generally you do not want to pollute your AD with these additional attributes. Therefore all app specific user configuration is performed only on the UCS side.

Yes… I get this part… but I hoped the directory-listener would “replicate” the entire “structure” from MS AD with all attributes and values… but it’s obviously not.

I suppose the listener should be modified/extended to replicate all the Kopano attributes from AD? (Any hints on this?) to do what I intended from beginning (all config in AD, local ldap for performance).

Is there any “gain” in installing Kopano from UCS Apps if MS AD is used as backend? (open-ldap schema extension, user attributes… would be redundant and not used nor synced from AD)
As far as I can understand the source of Kopano4UCS it’s all related to handling ucs admin pages and open-ldap attributes - and that should be managed by the MMC plugin, isn’t it?

If the ad should be the leading system then this is possible in Kopano as well. Just make sure to perform all configuration changes through the UCR (univention configuration registry) so that these are preserved when doing updates.

@mculibk said in Kopano with USC *AND* MS Active Directory:

Ah, and multi-tenancy is a requirement […] which I could not find in the UCS admin counterpart

The UMC is quite flexible and could (and has been done so in the pst) be extended to handle the multi tenant configuration of Kopano.

Reading the source - I should add some extended attributes (kopano-company etc) and hooks to handle changes done through UMC, right?
Do you have any link/reference of something similar that was already done, as you mention?

As long as we are talking about UCS I would always recommend to install apps through the appcenter as these also take care of some configuration. But its of course also possible to use a non-ucs system for this.

I totally agree… but in the case of wanting to use AD as Kopano ldap backend I’m not sure if it’s the right way?

UCS is nice, shiny and everything… but I find it rather “fragile” (and complex once you start looking under the hood)
For example, it happened to me a few times that samba-memberserver lost “connection” to the MS AD (unable to authenticate…) and once even the ucs-master DC lost “kerberos connectivity” to AD… without touching anything at all and then loosing quite some time to make it all work again (eventually restoring from backup)…

Regards,
M.Culibrk

[fbartels]

@mculibk said in Kopano with USC *AND* MS Active Directory:

Any hints on this?

I’d recommend to ask in the ucs forum about this. I think I’ve read at some point that the mapping can be configured.

@mculibk said in Kopano with USC *AND* MS Active Directory:

Is there any “gain” in installing Kopano from UCS Apps if MS AD is used as backend?

Yes, Kopano is also configured through the app (for the default ucs environment at least) .

@mculibk said in Kopano with USC *AND* MS Active Directory:

Reading the source - I should add some extended attributes (kopano-company etc) and hooks to handle changes done through UMC, right?
Do you have any link/reference of something similar that was already done, as you mention?

No, unfortunately no ready to run examples. But our support can surely create them for you.

@mculibk said in Kopano with USC *AND* MS Active Directory:

I totally agree… but in the case of wanting to use AD as Kopano ldap backend I’m not sure if it’s the right way?

See it the other way around: If you neither want to use the ucs appcenter, nor its ldap, then there is also not much use in ucs as an OS for you.