# Migrating OpenLDAP to AD backend

**URL:** <https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404>\
**Category:** ℹ️ Support\
**Tags:** ldap\
**Created:** [August 22, 2018, 2:02pm UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404 "2018-08-22T14:02:28Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![4001982248998](https://help.nextcloud.com/user_avatar/help.nextcloud.com/4001982248998/32/64034_2.png) [@4001982248998](https://help.nextcloud.com/u/4001982248998)\
**Post date:** [August 22, 2018, 2:02pm UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/1 "2018-08-22T14:02:28Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![budy](https://help.nextcloud.com/user_avatar/help.nextcloud.com/budy/32/697_2.png) [@budy](https://help.nextcloud.com/u/budy)\
**Post date:** [August 23, 2018, 11:35am UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/2 "2018-08-23T11:35:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![budy](https://help.nextcloud.com/user_avatar/help.nextcloud.com/budy/32/697_2.png) [@budy](https://help.nextcloud.com/u/budy)\
**Post date:** [September 9, 2018, 10:10am UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/3 "2018-09-09T10:10:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![4001982248998](https://help.nextcloud.com/user_avatar/help.nextcloud.com/4001982248998/32/64034_2.png) [@4001982248998](https://help.nextcloud.com/u/4001982248998)\
**Post date:** [September 10, 2018, 9:36am UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/4 "2018-09-10T09:36:21Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![budy](https://help.nextcloud.com/user_avatar/help.nextcloud.com/budy/32/697_2.png) [@budy](https://help.nextcloud.com/u/budy)\
**Post date:** [September 10, 2018, 10:12am UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/5 "2018-09-10T10:12:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [December 4, 2024, 7:34am UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/6 "2024-12-04T07:34:32Z")

</div>



---

<div class="post-metadata">

**Author:** ![wwe](https://help.nextcloud.com/user_avatar/help.nextcloud.com/wwe/32/72963_2.png) [@wwe](https://help.nextcloud.com/u/wwe)\
**Post date:** [December 9, 2024, 3:10pm UTC](https://help.nextcloud.com/t/migrating-openldap-to-ad-backend/35404/7 "2024-12-09T15:10:36Z")

</div>