Migrating Kopano from OpenLDAP to Active Directory

linnea-s

Hi,

I am looking into migrating from a OpenLDAP+Samba NT domain to a Samba4 Active Directory domain.

With our OpenLDAP catalog, uid/gidNumber is used to uniquely identify users/groups in Kopano. While these attributes are preserved while migrating from OpenLDAP to Samba4 AD, I would still like to change to using objectGUID to uniquely identify users and groups, because it’s a hassle to continue to maintain Unix attributes. (The Unix attribute support has been removed from the ADUC tool, and UID/GIDs thus have to be maintained manually)

I’ve been looking into the process for migrating from DB to LDAP, and found out that the user/groups’s LDAP ID is stored in the externid column in the users table. In theory it should be a simple matter of mapping UID/GID to objectGUID and updating the database.

The DB to LDAP migration process I’ve found also contains the script db-upgrade-addressbook-entryids.pl, but it seems to be outdated. What I’m wondering is, does that script do anything that is necessary for LDAP to AD migration, or is it sufficient to update the users table?

Thanks for any help,

Linnea

fbartels

Hi @linnea-s ,

@linnea-s said in Migrating Kopano from OpenLDAP to Active Directory:

What I’m wondering is, does that script do anything that is necessary for LDAP to AD migration, or is it sufficient to update the users table?

unfortunately just changing the ids in the user table will not be enough, as the external user id is still referenced for example in mail objects. This is what the mentioned script fixes in the database.

As the script was also required for a migration step in the old Zarafa Univention integration I had a slightly updated version of that script. This version can be found at https://stash.z-hub.io/projects/Z4U/repos/zarafa4ucs/browse/scripts/db-upgrade-addressbook-entryids-delegate.pl.

linnea-s

@fbartels Thank you :) With that script I could probably get it to work, but it feels a little scary to make changes to the database at such a low level, so for now I’ve decided that it’s safer to continue using UIDs/GIDs.

thctlo

Hai, before you migrate, please becarefull with the UID/GID’s when you move from samba NT to samba AD.
It’s all about the defined ranges, these may not overlap .
The systems uid/gids and the other ranges.

By example, this is the most important part.

    ## map id's outside to domain to tdb files.
    idmap config *:backend = tdb
    idmap config *:range = 2000-9999

    ## map ids from the domain and (*) the range may not overlap ! ( same for the system ranges - 1999 )
    idmap config NTDOM : backend = ad
    idmap config NTDOM : schema_mode = rfc2307
    idmap config NTDOM : range = 10000-3999999
    idmap config NTDOM : unix_nss_info = yes

Then import the kopano schema in the samba AD.
Setup a new server for the mail with kopano.
export all data to pst en import these again in kopano.

a bit more work but no problems after the migration.

fbartels

@linnea-s said in Migrating Kopano from OpenLDAP to Active Directory:

Samba4 AD

Urgh, I totally overread this part. In the past the Samba4 AD implementation did suffer from very poor performance. About how many users are we talking here? Please make sure to perform a stress test on your new directory (throw as many binds at it as possible) and compare performance your your current OpenLDAP.

thctlo

The performance is fine these days. samba AD is Multi threaded now, so no slow ldap anymore for me.
And added a bit of extra indexing helps also a lot. All info is in the samba list also.

My site has 50-60 users, so not to many but lots of mail and other object in ad and a 110GB database.
All with Debian 8/9 and samba AD-DC 4.8.5 . dont use samba 4.9.x yet wait for 4.9.2 due to some bugs.

linnea-s

Thanks for the advice. I will be sure to check the IDs and performance before migrating fully.

A note in case anybody’s considering the same, the plan is to set up the Kopano server as a RODC (read only domain controller). In my testing so far I’ve found that it’s necessary to add Kopano users to the “Allowed RODC Password Replication Group” and also to run “samba-tool rodc preload username” for each user. I have a script which automates that step, only preloading user objects that have been modified since the last time it was run (preloading is very slow). The preload step appears to be necessary both for LDAP binds to work and for the Kopano attributes to be synchronized.