I have an existing Nextcloud installation which has only been used by myself as the only single user in the past. My personal user was also the administrator for that Nextcloud installation.
How do I migrate to LDAP authentication for an existing user account without risking to loose access, data or creating DB inconsistencies which may cause problems later?
Background Story
In the past, Nextcloud was only used by myself. Now, Nextcloud is going to be used by a couple of users (family members) and the server will provide additional services such as Posfix and Dovecot. I want to migrate Nextcloud to LDAP user authentication not because there will be so many users (only five to be precise), but only to have a single account/password for each user and each service. OpenLDAP is already up and running, the LDAP DIT is already populated and the additional services (i.e. Postfix, Dovecot) already work properly with LDAP.
For my own, I have created a user account in the LDAP DIT with the same name as the already existing and original user account for Nextcloud, which I have been using for years. Currently, these two user accounts are still independent despite sharing the identical name as I have not yet enabled LDAP authentication in Nextcloud. In the future, I want to use LDAP authentication for that account, too, not only for the additional user accounts. Is it safe to simply enable LDAP authentication in Nextcloud and will it simply work as expected? Or will I face any issues, because that user account was not an LDAP account right from the beginning?
I found a more manual solution to my problem. It seems to have worked as expected, but I do not give any guarantees that this is a safe way.
In summary, I populated my LDAP DIT such that my account name according to LDAP was identical to my existint account name according to Nextcloud. Then I enabled LDAP in Nextcloud and fixed the Nextcloud tables which map Nextcloud accounts to LDAP accounts manually using raw SQL statements.
Detailed steps:
Create the LDAP user, in my case it is : uid=<my-account>,ou=users,o=<my-domain.tld>,dc=<host name>,dc=<my-domain>,dc=<tld>. Important: account name is identical to my existing account name in NC.
Enable and configure the “LDAP User and Group Backend” in NC.
I used the following special settings:
Eplaination: Normally, NC creates a UUID-based internal account name for each LDAP account and maps the NC account to the LDAP account. This also implies that the data directory becomes data/<UUID>. However, I wanted the (new) LDAP-based NC account to become the 1:1 direct successor of my existing NC account. Hence, I configured the “LDAP User and Group Backend” to use the uid-attribute as the UUID (for user accounts) and the cn-attribute as the UUID (for group accounts) such that LDAP-based accounts look the same as native NC accounts.
After I enabled that LDAP configuration, NC automatically synced the LDAP accounts and created corresponding NC accounts. Of course, in case of my existing account there was an (intended) name conflict as the LDAP DIT defined an user account with the exact same name the already existing account. NC resolved this conflict by creating a new NC account with a random number as suffix. Hence, I ended up with
<my-account> the previously existing (old) local NC account
<my-account_1234> as the new local NC account mapping to <my-account> in LDAP
Put NC into maintenance mode and fix the NC manually:
Fix the table of all accounts:
Remove the existing (old) NC account and rename the (freshly created) NC account to the old one
DELETE FROM oc_accounts WHERE uid = '<my-account>';
UPDATE oc_accounts SET uid = '<my-account>' WHERE uid = '<my-account_1234>';
DELETE FROM oc_accounts_data WHERE uid = '<my-account>';
UPDATE oc_accounts_data SET uid = '<my-account>' WHERE uid = '<my-account_1234>';
Fix the mapping table between NC and LDAP accounts
Rename the (freshly created) NC account to the old one
UPDATE oc_ldap_user_mapping SET owncloud_name = '<my-account>' WHERE owncloud_name = '<my-account_1234>';
Fix the table of local NC accounts:
Delete the old account which is not needed anymore
Cool that you found a way to make that work. For such unofficial ways where you change the inner workings, don’t forget to backup first, so you don’t loose any data. After such an intervention make sure, that everything works. Your clients are still syncing, the apps have the data, the shares are still working, …
@kamiar_apt Looking to do this (only really need 2 users changed) so curious if it does work that way. Did you structure LDAP like @nagmat84 did? It seems you did, I just want to confirm.
