I set up owncloud quite a while ago. In the meantime, the LDAP support got improved and I could use a LDAP attribute as the “technical” ownCloud user-ID. Currently, I use the legacy way, the LDAP UIDs. Is there a way to migrate from UID to e.g. username?
Maybe this helps. Otherwise you would have to share more details about what you’d like to do. Using LDAP uid is not legacy afaik. Keep in mind, using the username leads to the issue, that when the username changes, a new local user will be created. Most likely not intended behavior. If you’d like to share more details, please provide at least an example row of your current oc_ldap_user_mapping database table and how it should look like in the future.
1 Like
Hey ya. Thanks for your reply.
Alright, so I do have a classic LDAP set up. Beside an admin user, all users are authenticating against LDAP. Also, I use two accounts - one is my private account and one for business use.
This works well as long as I am only looking at the web interface and not looking beyond one account at a time.
It starts to get interesting when I use the Android client. Adding both accounts I have two ways to identify the accounts:
- The full name - which is identical for both accounts
- The user name - which is the UUID LDAP provides as userId
Also, on the file system, I do have UUIDs instead of user names.
With newer version of the LDAP module I can define an LDAP attribute which I like to use as a user ID field. As I have a “username” field I have a pretty good idea which one I will use 
Now, I am not the only one using the installation. Many users have quite a few files in their storages plus use contacts and calendar.
Is there any way of transitioning?
There is no easy way.
The problem is that the userid is used as the data directory in the file system as well as ID in several tables in the database. E.g referencing that data directory again.
So you could go into the expert tab, change the Internal Username Attribute to samaccountnameand click “Clear Username-LDAP User Mapping”. However if you do that all users will lose all their files and all existing shares will be gone as well.
To prevent that you could, not click that “Clear Username-LDAP User Mapping” button after changing to samaccountname. Do a occ user:sync -vvv -m disable -r "OCA\User_LDAP\User_Proxy" and then run a occ files:transfer-ownership <uid> <samaccountname> for every user. And then remove all users with .
That is the safest way, but has the downside that every users data will be moved into a subfolder with a name along the lines of "data from "
So the cleanest but most dangerous way would be to update the mapping. For that export your owncloud db, change every mention of the uid to samaccountname, re-import the db, and move every user’s data folder from ‘/path/to/owncloud/data/’ to ‘/path/to/owncloud/data/’. And don’t forget to update the setting in the expert tab of the user_ldap app.
Please note that I haven’t tried if this actually works (neither the first nor the second method), there might be pitfalls I’m unaware of.
I would recommend to setup a test environment to confirm this process and plan your maintenance. Additionally it is also very strongly advisable to ensure you always have point to roll back to.
1 Like
Stick to the uuid as the owncloud internal username. Not only is it used in internal tables, but the ID is also used as federated sharing ID. If you change it, existing federated shares would break.
If the only thing you want to accomplish is being able to distinguish accounts you can customize the display name and make it show the email address next to the display name. Check the 2nd User Display Name Field in the advanced ldap settings.
Using the samaccountname, cn or uid from ldap is dangerous, because these attributes are subject to change, eg in case of marriage.
Uuid is not perfect either because it changes when the user is migrated to a different ldap server or reimported as part of a batch update.
The best solution is to generate a new attribute. Ms ad nowadays has one. Google for source attribute and immutable ID.
Also note that owncloud has a fallback mechanism should the internal username attribute change. It will look up the user using the uuid attribute and update the dn in the ldap user mapping table. The original internal username is kept in there an will be used after login. Just don’t change the login and uuid at the same time.
2 Likes