Import LDAP users & get rid of LDAP

Hello there,

TL;DR: I would like to convert my LDAP users to regular users and drop the LDAP backend. I am looking for an automated way to do that. I am not afraid of scripting some stuff to do that.

I have been using Nextcloud for a while now and I love it even more every day. A few years ago, I set up a LDAP server and configured Nextcloud to use it as a backend to provide users. It worked well for a while. However, with time, we closed the other services we used and now only Nextcloud still requires the LDAP.

I would like to drop the dependency in LDAP but keep my users. That would mean import the LDAP users as regular Nextcloud users, keeping their data. I’m OK with:

  • losing the passwords. Nextcloud doesn’t know them anyway. And there is the password recovery function;
  • loosing the shares. It’s a bit annoying, but recreating them isn’t that hard.

I was thinking about something like:

  • save the files;
  • save the list of usernames & email addresses;
  • drop LDAP and the associated users;
  • batch create users with the saved usernames & email addresses;
  • move the old users files to the newly created users;
  • rescan the files.

However, there might be a better way (is there?) and I should probably take care of calendars, contacts & tasks.

Any help would be greatly appreciated!

— Niols

Software & versions:

  • Nextcloud 16.0.3
  • Debian 10 (Buster), upgraded from 9 (stretch)
  • nginx 1.14.2 (from APT repositories)
  • PHP 7.3 (from APT repositories)
  • MariaDB 15.1 (from APT repositories)

I would encourage you to keep and integrate you LDAP, but to your question: I think what you are looking for is going to fall under the occ command which allows CLI management of Nextcloud.

Another option: install and migrate LDAP to your Nextcloud server and keep the LDAP dependency. It should be a lot less work, and you can continue to manage the LDAP directory using your existing tools. Running OpenLDAP should use a minimal amount of memory, and gives you a more flexible authentication solution if you want to change this again in the future.

I have moved some of my LDAP users to regular ones, by simply creating a new local user in NC and then use the cli tool to migrate all dara of my LDAP user account over to the new local user. This successfully moved all data and even pertained all shares, either received or granted, for the new local user account.

I would really like to get rid of LDAP. Not really for speed or memory usage (although having the authentication backend and Nextcloud on the same machine will clearly speed things up) but rather because I’m tired of maintaining too many (in my opinion) things.

Being able to create regular users and then migrate information from LDAP users to regular seems good to me. But I couldn’t see anything in the occ command about migrating data from one user to an other. Did I miss it?

This is the command you’re looking for:

sudo -u www-data php ./occ files:transfer-ownership [--path PATH] [--] <source-user> <destination-user>

Oh, nice, I didn’t think that I could find that there. I guess I can use:

./occ dav:move-calendar

for calendars. But I can’t find a similar command for addressbooks. Or are these being taken care of by files:transfer-ownership? (Probably not.)

When I used the files:transfer-ownership command, my new local user account also got the calendar from the ldap account I wanted to get rid of.

I just gave it a try. Files are transferred to a directory “transferred from […]”. Calendars and contacts are not transferred. I can probably move calendars using dav:move-calendar. But I don’t know how I could move contacts. Any idea?

Edit: cleanup instructions and add handling of groups.

I finally took some time to explore this issue. It turns out I got the rather simple following solution working: In the MySQL database, I created one new user per LDAP user with the same uid. I then disabled the LDAP app. This works because all the tables then refer to the uid that remains defined.

Potentially annoying consequences can be:

  • that this solution relies directly on the layout of MySQL tables and is thus not stable,

  • that the uid used in the database is not necessarily the one one had to enter to connect (in my case, it wasn’t an issue),

  • that the users loose their passwords (as it is never imported from LDAP). I decided to tell them in advance that they would have to use the “forgotten password” functionality, but that implies having a working e-mail configuration.

This is very experimental and might very well not work for other versions of Nextcloud! But it did work for me and version 17.0.0.

This obviously should occur in prod only after some testing on a safe copy of the targetted instance.

Here goes:

  1. Turn on maintenance mode.
    (CLI) php occ maintenance:mode --on

  2. Check for incoming trouble.

    1. Users that will see a change of login id after the process.
      (SQL) SELECT * FROM oc_ldap_user_mapping WHERE owncloud_name != directory_uuid
      The owncloud_name is the uid that will be used after, the directory_uuid is the one that was used with the LDAP.

    2. Name clashes between normal and LDAP users.
      (SQL) SELECT uid FROM oc_users, oc_ldap_user_mapping WHERE owncloud_name=uid
      If it is non empty, you are probably going to be in trouble. I don’t know. It should probably not happen anyway.

    3. Name clashes between normal and LDAP groups
      (SQL) SELECT gid FROM oc_groups, oc_ldap_group_mapping WHERE gid = owncloud_name
      If it is non empty, you are probably going to be in trouble. Again, it should probably not happen.

  3. Import users and groups

    1. Create one normal user per LDAP user.
      (SQL) INSERT INTO oc_users (uid, uid_lower) SELECT owncloud_name, owncloud_name FROM oc_ldap_user_mapping

    2. Create on normal group per LDAP group.
      (SQL) INSERT INTO oc_groups (gid) SELECT owncloud_name FROM oc_ldap_group_mapping

    3. I don’t know how to import group membership easily. So you will have the groups, but they will be empty and you will have to add people to the group again. This comes from the way in which LDAP stores the groups.

  4. Disable LDAP.
    (CLI) php occ app:disable user_ldap

  5. Cleanup.

    1. Remove LDAP user bindings.
      (SQL) DELETE FROM oc_ldap_user_mapping

    2. Remove LDAP group bindings
      (SQL) DELETE FROM oc_ldap_group_mapping

    3. Remove LDAP group memberships
      (SQL) DELETE FROM oc_ldap_group_members

  6. Turn off maintenance mode
    (CLI) php occ maintenance:mode --off