LDAP Migration with different DN

ℹ️ Support
1

Hi everyone,

I want to change our LDAP Service from OpenLDAP to freeIPA and with it the structure of the LDAP-tree, so we have another DN as before.

Goal:
Every user should keep his account with his files, rights (etc.) after the migration of the LDAP-server.

Starting Point:

  • Nextcloud version 18
  • LDAP with old DN works fine
  • The owncloud-name is the uid-LDAP-Attribute
  • the DN changes, but the LDAP attributes uid, uidNumber, gid, gidNumber, cn, mail and much more stays the same
  • Connecting the new LDAP-Server will create new NC-accounts (uid + suffix-number)

What I have successfully tried on a test-instance:

  • Connect old LDAP-Server to generate NC-accounts and LDAP-NC-Accounts mapping
  • Load up some test files
  • Connect new LDAP-Server to NC
  • Disconnect old LDAP-Server
  • Manually edit the database table oc_ldap_user_mapping:
    • Delete mapping generated by old LDAP-Connection
    • Update entry of the new LDAP-Mapping with the values of the entry of the old connection
    • Now the Mapping points from the new LDAP-entry to the old NC-account

Example of DB-table oc_ldap_user_mapping:

  1. Line: old LDAP-Mapping
  2. Line: new LDAP-Mapping
#before
+-----------------------------------------------------------+------------------+--------------------------------------+
| ldap_dn                                                   | owncloud_name    | directory_uuid                       |
+-----------------------------------------------------------+------------------+--------------------------------------+
| cn=john smith,cn=emplyees,ou=internal,dc=mycompany,dc=de  | jsmith           | bfc5d132-aa24-1039-963d-35b47debe530 |
| uid=jsmith,cn=users,cn=accounts,dc=mycompany,dc=de        | jsmith_8890      | edadbf0e-c120-11ea-b61f-960000423aa7 |
+-----------------------------------------------------------+------------------+--------------------------------------+

# after
+-----------------------------------------------------------+------------------+--------------------------------------+
| ldap_dn                                                   | owncloud_name    | directory_uuid                       |
+-----------------------------------------------------------+------------------+--------------------------------------+
| uid=jsmith,cn=users,cn=accounts,dc=mycompany,dc=de        | jsmith           | bfc5d132-aa24-1039-963d-35b47debe530 |
+-----------------------------------------------------------+------------------+--------------------------------------+

Questions:

  • Is there a better way or tool to reach the goal?
  • Is this “update-save”? (Updating NC)
  • I have read somewhere a while ago, that it will work well and without manipulation, if it would be the same DN. Means: This would generate the “same” mapping again and again (idempotent). Is that true?

Thanks & stay healthy!
wieland

P.S: My attempt ist heavily inspired by the post Migration to LDAP keeping users and data

2

Hi!

I did practicaly the same way when migrates from an old LDAP to a new LDAP with some differencies. I am using NC19 with LDAP with homeFolderNamingRule set to cn. Which means all homefolders are not created with UID, but common name (Jon Snow for example). I thought it will be a better way, but it’s not. I have some differencies between old and new LDAP cn. In old LDAP cn=Jan Novák, but in the new LDAP there is cn=Jan Novak. Because of that, I ended up with double count of users (old and new) and double count of home dirs (old and new). I thought I can use files:transfer-ownership, but it not working at all. Finaly I made changes in oc_ldap_user_mapping table in DB. Now I have only users from a new LDAP there. The same I can see in web browser on nextcloud, BUT when someone try to share something, there are a double count of users, (J) Jon Snow and (JS) Jon Snow, but only one of them works, when I choose the wrong one I got an error during create a share. How can I get rid of wrong (deleted) users from share option ?

Thanks
tlamik

3

Thank you very much! That was exactly what I was looking for.

I updated from 20.0.0 to 20.0.6 and it worked.
Only my windows client didn’t like it.

I can only recommend to use a script to edit the database.
One wrong click and now a user has the wired number after his username.
I also recommend that users have the same password in the new system.