Official support for migrating local accounts to LDAP

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
As an NC admin, I set up an NC instance and create local accounts for all of my users. Subsequently I deploy LDAP for SSO for the organization and migrate all manner of apps to using LDAP instead of their local account management.

I would like to transparently migrate my NC users to using LDAP for their authentication also.

Nominally, I have been able to achieve this manually by changing the owncloud_name of the oc_ldap_user_mapping table for a given ldap_dn to the local account uid and then removing that account from the oc_users table. I.e.:

# echo 'update oc_ldap_user_mapping set owncloud_name = "brian" where owncloud_name = "4e554e88-3dfa11e5-b0d08e21-c4e9261b";' | mysql -D nextclouddb                          
# echo 'delete from oc_users where uid = "brian";' | mysql -D nextclouddb

for a row in oc_ldap_user_mapping that looked like:

+------------------------------------------------------------+-------------------------------------+-------------------------------------+------------------------------------------------------------------+
| ldap_dn                                                    | owncloud_name                       | directory_uuid                      | ldap_dn_hash                            |
+------------------------------------------------------------+-------------------------------------+-------------------------------------+------------------------------------------------------------------+
| uid=brian,cn=users,cn=accounts,dc=example,dc=com           | 4e554e88-3dfa11e5-b0d08e21-c4e9261b | 4e554e88-3dfa11e5-b0d08e21-c4e9261b | f7f112161feff3633e54ce54e1af9f83e54c3b4480a7157594747c086e328a57 |
+------------------------------------------------------------+-------------------------------------+-------------------------------------+------------------------------------------------------------------+

I suppose there is some various cleanup that [c|sh]ould be done to remove any data referring to that now-non-existent 4e554e88-3dfa11e5-b0d08e21-c4e9261b account now. For my case, I have identified the following tables that all have some occurrence of 4e554e88-3dfa11e5-b0d08e21-c4e9261b in them:

oc_accounts
oc_accounts_data
oc_activity
oc_activity
oc_addressbookchanges
oc_cards
oc_cards_properties
oc_circles_circle
oc_circles_event
oc_circles_member
oc_filecache
oc_filecache
oc_group_folders_manage
oc_group_user
oc_ldap_group_membership
oc_ldap_user_mapping
oc_mounts
oc_preferences
oc_storages
oc_twofactor_providers

Describe the solution you'd like
Some kind of UI-driven operation to match local accounts to LDAP accounts. Maybe the account uid between LDAP and the previously existing local accounts is entirely disparate and a one-by-one matching is needed by the admin.

But perhaps there is a 1:1 match between local account uids and an attribute in LDAP that the admin can identify so that NC can iterate the accounts and automatically match them up and process the above oc_ldap_user_mapping/oc_users for the user.

Describe alternatives you've considered
Nothing other than the manual process I described above.

Start by reviewing the LDAP mapping and local-account data described in oc_ldap_user_mapping and oc_users, then examine the other listed tables for references to the old account identifier. Define how an admin would match accounts and what safe cleanup must cover. Done means a supported UI-driven migration handles matching and preserves the user's existing data without manual SQL.