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:
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”
I map the field “uid” to the internal username within the expert tab of the LDAP integration
Next, I delete the records from oc_users
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
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”)
OS: Do a backup
OS: Install the php ldap package: php7.0-ldap
NC: Create an admin user who isn’t in LDAP - “uli-admin”
NC: Login using this user
NC: Activate the LDAP/AD integration
NC: Configure the LDAP/AD integration
NC: LDAP/AD integration expert:
Internal username - internal attribute of user: uid
Delete LDAP user relations
Delete LDAP group relations
DB: Delete all users from table “oc_users” except “uli-admin”
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.
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)…
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…
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:” :
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).
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?
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?
