Migration to LDAP keeping users and data

[Uli_He]

Currently, I’m trying to migrate to LDAP. I’d like to keep the existing users and this seems to be a kind of an issue. By default, nextcloud creates new nextcloud users for all these LDAP users. I’m on nextcloud 12.

Starting point

I’m running nextcloud 12. I’m using the default setup (more or less). I have a couple of users within nextcloud and they share a couple of files and calendars. The password is stored within nextcloud.

Goal

I’d like to keep most of the setup, I only want to authenticate against a LDAP server.

Default Behavior

When activating LDAP, the LDAP users tend to create new nextcloud accounts. Within these, the existing files and calendars don’t show up. Pretty bad…

“My Way”

Here is what I found out:

1. Within LDAP, the field “uid” has the same value as the user name in nextcloud. For example, I do login with the user name “ernie” and within LDAP, the field “uid” has the value “ernie”
2. I map the field “uid” to the internal username within the expert tab of the LDAP integration
3. Next, I delete the records from oc_users
4. Finally, I look at the user list within nextcloud

So far, things look pretty OK. Logging in with the LDAP password gives me the same group set as before.
Hopefully, things go on smoothly.

Questions

• Has someone experience with this kind of migration?
• Do I have a chance to reach my goals?

Thanks + best regards, Uli

More Details

OS … actions related to the operating system, NC … actions related to nextcloud, DB … actions related to the database

0. LDAP: Make sure you have a field within LDAP which’s value contains the login names of your NC users
   (for me, this is the field “uid”)
1. OS: Do a backup
2. OS: Install the php ldap package: php7.0-ldap
3. NC: Create an admin user who isn’t in LDAP - “uli-admin”
4. NC: Login using this user
5. NC: Activate the LDAP/AD integration
6. NC: Configure the LDAP/AD integration
7. NC: LDAP/AD integration expert:
   • Internal username - internal attribute of user: uid
   • Delete LDAP user relations
   • Delete LDAP group relations
8. DB: Delete all users from table “oc_users” except “uli-admin”
9. NC: Show user list -> OK
10. NC: Do a login with a LDAP user -> OK

Nextcloud - LDAP - Server

Nextcloud - LDAP - User

Nextcloud - LDAP - Login

Nextcloud - LDAP - Advanced

Nextcloud - LDAP - Expert

MYSQL - Delete Users

delete from oc_users where uid<>'uli-admin';

Nextcloud - UserList

Findings After A Week

Works perfectly in a test environment. Users don’t see any difference apart from using a different password.

[Jeffery_Frederick]

I am interested in doing the same thing. Were you able to get this working?

Thanks!

[Uli_He]

Yes, it used to work perfectly for the last week in a test environment.
I just migrated the production environment this weekend. Hopefully,
nobody will complain
within the upcoming week.

Best regards, Uli

[jkaberg]

Hi @Uli_He

Would you mind shareing exactly how you did this (especially what you put in expert settings)? I’m headed this way aswell

Did you do anything with the database tabels etc?

[Uli_He]

Added “More Details” above…

[jkaberg]

Thanks for the detailed reply, I’ve just issued the changes to my install and it seems fine

How did you get the “user backend” column in the user overview? It isn’t showing for me

EDIT: Found it

[Uli_He]

Perfect, hopefully it works for you as good as for me. Best regards, Uli

[Patrick9999]

Anybody tested this with users that have shares enabled with other users ? I’ve configured LDAP and deleted the oc_users (except admin) as mentioned and the data for the users is indeed preserved but the shares don’t show the files. You see that its shared but when you click on the share you get the message: “You don’t have permission to upload or create files here”. Probably the user needs to reshare it or i’ve done something incorrect with the mapping ?\

-edit-
Got the problem i think, usernames are created (as defined) based on samaccountname (this is case-sensitive!) so i had previous Database usernames stored only in lowercase, now the usernames that are getting created are with a few capital letters (FirstnameLastname)…

[Bubbel]

I have just done the procedure, and it went quite fine, except for the fact that I had active sync clients running, which gotten me into trouble.

When I enabled LDAP, but not yet deleted the users yet, a desktop client went and tried to log in. Result was two accounts, one as the original and the LDAP username was appended with an underscore and four digits. Removing the local accounts and again deleting LDAP relations, ultimately got it working again, thou I got a bit scared, when I logged as a user, during the erroneous entries in and saw a pristine environment.

So now all is up and running. Also the shares are there, as nothing was ever changed…

[Julien_GILLES]

Just to mention that following the procedure I got crash trying to display users :

{no app in context} {“Exception”:“Sabre\DAV\Exception\BadRequest”,“Message”:“VCard object with uid already exists in this addressbook collection.”,“Code”:0,“Trace”:[{“file”:"/opt/nextcloud/apps/dav/lib/CardDAV/SyncService.php",“line”:277,“function”:“createCard”,…

I resolved the issue by deleting the lines in oc_cards that have uri starting with “Database:” :

delete from oc_cards where uri like ‘Database%’;

And user list appears correctly now !

Hope this helps.

[milni]

Still working fine with Nextcloud 17.0.1.1 (just the table names have changed, now without the oc_prefix).

I did a step extra: after migration to LDAP, I allow users to login with uid, mail and cn and none of them matches the original NC uid. (For migration, I setup another LDAP attribute containing the original NC uid.)

This appears to have invalidated any app tokens in NC (i.e. it was not enough to change the login name in clients, but also to generate a new token in NC).

Otherwise, all seems okay.

[pbear62]

I am testing the migration in a NC 18 container.
Using the procedure described by Uli_He above/

Not all of my users are in LDAP yet. So I need to maintain both LDAP and local authentication.

so I did not delete the ALL existing users. Instead, after configuring ldap, I ran the following commands (before any users logged back in.)

"update nextcloud.oc_ldap_user_mapping set owncloud_name = directory_uuid where owncloud_name <> directory_uuid;"
"delete from oc_users where uid in (select directory_uuid from oc_ldap_user_mapping);"

I did the same thing for the groups as well:

"update nextcloud.oc_ldap_group_mapping set owncloud_name = directory_uuid where owncloud_name <> directory_uuid;"
"delete from oc_groups where uid in (select directory_uuid from oc_ldap_group_mapping);"

Best I can tell, this preserved all calendar, contacts, files/shares etc.

I am still a little concerned about something happening where LDAP burps or is unavailable and a cleanup user activity deleted all my LDAP user’s data…

Is there a means to make the default behavior to NOT cleanup user files/setting and just leave the user orphaned so I can clean up manually?

[Keridos]

This causes sessions to be partially broken for me. It logs out some of my auth sessions every time the cron job runs. Everything else works fine. Did anyone have any success with this on NC 18 or 19 without any problems?

[ledufAkaDemy]

did somenone try to do reverse :
ldap accounting to internal database ?
ldap is a nightmare for us, after one year.