Hi, I am having to migrate LDAP backends for my Nextcloud version 13.0.4 server. Currently, my (NGO, non-profit) users authenticate against an OpenLDAP server, but their accounts have since been moved to an Active Directory. Of course, users do not want to use their profiles or files.
Has anyone done this before and could outline the process?
Thanks!
This is a tough call… especially, if your RDNs are not the same in each directory, which they probably aren’t. And even if they were the same, there is a mapping from NC users to directory uuids, which won’t match between those two directories.
The issue is, you won’t know the new directory uuids upfront, so as soon as you connect your NC instance to an AD, you will get duplicate users, with different directory uuids. The same issue will occur for LDAP groups. I have been, too, thinking about a way to migrate from OpenLDAP to AD, but I haven’t come up with a viable solution to this problem.
I will give it some more thought over the next weeks, when our new server arrives and maybe there is a way to work that out. If I can find one, I will share it here.
So… this can be done, actually. Digging into the NC database, it turns out, that you will have to take care of a few things to make this work. To be able to do this, you will need to make sure that, the usernames match between the ones in OpenLDAP and AD. This is the most cruicial part, since on a ldap based setup everything relies on the values of the uid attribute in the table oc_accounts. In oc_ldap_user_mapping, the owncloud_name ties the owncloud_name, and thus the uid from oc_accounts to the UUID of the ldap entry in OpenLDAP or AD.
Naturally, these uuids don’t match and they need to be preserved for all the shares and things to still work afterwards. However, this can be sorted out rather easily. 
The other thing is the owncloud_name, which gets populated from the ldap search, when NC queries the directory for user entries. This depends on how you set up your ldap initially. E.g., we used OpenLDAP’s uid for that, which has always been ‘givenname.surname’ and which dates back almost 18 years ago, when this seemed to be a natural choice (when in fact it wasn’t, but that’s another story altogehter). The thing is… the contents of the OpenLDAP attribute ‘uid’ could have any length - and we do have people with lengthy names, while AD only supports a max. of 20 characters for usernames (silly AD!). The way I solved that, was to introduce another attribute to AD named extrensionAttribute10 (which of course implies, that we already had made use of 9 others, so this was not new to us… ) which got the proper uid values and which I used in my new NC instance as the login attribute. After having figured that out, the rest was merely a bit of juggling around with the database tables.
In brief this is how the process worked:
prepare you AD such as that you can match your AD accounts using the same login, that these accounts have on OpenLDAP
setup a new NC instance and configure it to use AD, but in such a way, that you can login using the OpenLDAP user account names, make sure that in oc_account each uid has the same owncloud_name as in the old instance (in the Expert settings!), if you used that before
check your new instance and try logging into NC
check the database tables oc_accounts and oc_ldap_user_mappings - make sure that the owncloud_name in oc_ldap_mappings match the uid values in oc_accounts
if you can successfully login to your new NC instance by providing your OpenLDAP usernames, shutdown the NC instance
dump the database of your new NC instance, in case you’re messing something up along the way, that follows…
mysqldump -u root nextcloud > new_instance_dump.sql
dump the oc_ldap_user_mapping table separately:
mysqldump -u root nextcloud oc_ldap_user_mapping > oc_ldap_user_mapping_new.sql
dump the oc_ldap_group_mapping table separately:
mysqldump -u root nextcloud oc_ldap_group_mapping > oc_ldap_group_mapping_new.sql
dump the user_ldap configuration from oc_appconfig separately:
mysqldump --opt -u root nextcloud oc_appconfig --where="appid='user_ldap'" > oc_appconfig.sql;
remove the drop table/create table commands from the exported oc_appconfig_new.sql(!)
dump the database from your current NC and transfer it over to the new instance:
mysqldump -u root nextcloud > production_dump.sql
drop the entire NC database on your new instance and create a blank one: mysql -u root -e "DROP DATABASE nextcloud; CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; GRANT ALL PRIVILEGES on nextcloud.* to nextcloud@localhost;"
import the complete dump of your production NC database on your new instance: mysql -u root nextcloud < production_dump.sql
drop the table oc_ldap_user_mappings and oc_ldap_group_mappings from the nextcloud db:
mysql -u root nextcloud -e "drop table oc_ldap_user_mapping; drop table oc_ldap_group_mapping;"
import the dump of oc_ldap_user_mappings from your local installation:
mysql -u root nextcloud < oc_ldap_user_mapping_new.sql
import the dump of oc_ldap_group_mappings from your local installation:
mysql -u root nextcloud < oc_ldap_group_mapping_new.sql
delete all rows from your oc_appconfig table where appid ist "user_ldap’:
mysql -u root nextcloud -e "delete from oc_appconfig where appid='user_ldap';"
import the ‘ldap config for AD’:
mysql -u root nextcloud < oc_appconfig.sql
This should do it for the “migration” of the user accounts from OpenLDAP to AD. I actually went further and moved the entire nextcloud directory over to the new host and also arranged for the data directory to be placed at the same location. Afterwards I startet the necessary services for my new NC instance and was able to login using my regular AD account, by providing my “OpenLDAP” username. Afaik, all the shares and shared links do work correctly, which had been my main concern…
Cheers,
budy
hey, fantastic work, hats off!
One minor thingie: I do happen to have a different AD directory connected to the NC server, alongside the OpenLDAP one. My migration task would be to move AD1/LDAP1 to AD1/AD2, leaving the AD1 connection as it is.
Following your steps, do you think it would work when I would set up the AD1 connection on the new NC instance?
Cheers!
As long as you get the config right for both of them, that should work. Just setup AD2’s config on your new NC instrance the same way it has been on your original one and only care about AD1. Getting this correct should get you all your accounts on your new NC instance, where the UUIDs of the AD1’s users accounts are different than before, but the UUIDs of your AD2’s users are not.
The rest of the procedure should be quite the same.