New UUIDs (and new profiles) after LDAP change

ℹ️ Support
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 23.0.3
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.3
  • Web server and version (e.g, Apache 2.4.25):
    • nginx 1.24.0
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • nginx 1.24.0
  • PHP version (e.g, 8.3):
    • 8.3
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • When I changed the LDAP settings
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • Archive
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • neither, nor.

Summary of the issue you are facing:

We wanted to change the LDAP basis from AD to OpenLDAP. All users and groups are synchronized between AD and OpenLDAP. When we changed the mapping from AD to OpenLDAP, we realized that the user login with a new UUID and from the user’s perspective it looks like, if all data are gone.

Steps to replicate it (hint: details matter!):

  1. use AD as LDAP basis, put some data in your account

  2. change to OpenLDAP as LDAP basis

  3. relogin and see your data are gone

Disclaimer

This is NO bug, imho. I guess, it has technical reasons why the UUID change. I just need a hint, how to solve this.

First approach: Can I give the users their old UUIDs back, so that they have their data back? Where do I change this?

Second approach: Can I copy the data from oldUUID to newUUID, so that they have their data back? I see the data under /var/lib/nextcloud/data/[UUID], but I guess there are other data linked to the UUID in the DB, e.g. settings, talks, etc. A lot of effort in my imagination… Or is there somewhere a script by chance?

Thank you for that great piece of sofware :blue_heart:

[edit]

Addendum

After reverting the configuration to its original state, users have regained their “old” UUIDs and thus their data.

However, our goal remains to migrate the configuration from Active Directory to OpenLDAP.

Any help or comments on this topic are very welcome.

[/edit]

2

Yeah this seems like something you’d deal with as part of the Active Directory->OpenLDAP migration itself IMO. Mostly outside the scope of Nextcloud itself.

For example retaining the original AD derived UUID in the new LDAP platform - different scenarios:

  • directly mapped to the target platform’s equivalent in its database (100% invisible to LDAP consumers)
  • in a custom attribute in the target platform (not invisible to LDAP consumers, but likely just a one-time configuration change)

I believe you could use something like Ldap Synchronization Connector (LSC) to assist with this process. You’d then also have to have OpenLDAP create this attribute and populate it for new LDAP users as well. And lastly point Nextcloud at that new custom attribute (under Expert Settings).

There are other potential approaches based on my understanding, such as directly migrating the AD objectGUID values into OpenLDAP’s native entryUUID field. These would eliminate the need to create and manage a new attribute, but require other approaches (e.g. using slapadd).

1 Like
3

I’m not givin’ up here… :smiley:

I do understand the idea of using UUIDs. If I change my login name from du to ds due to marriage or if I move an entity within the directory, the UUID does not change.

The drawbacks are:

  • this internal username is also used in logging, a the user’s directory and in commands like occ ldap:check-user --update 43A…
  • this internal username is also used for all the *DAV urls
  • if you migrate from one directory type to another, the UUID changes

While I can live with drawback 1 and 2, it is difficult with drawback 3:

MariaDB [nextcloud]> SELECT * FROM oc_ldap_user_mapping WHERE ldap_dn LIKE "%=du,%";
+--------------------------------------+--------------------------------------------------------+--------------------------------------+------------------------------------------------------------------+
| owncloud_name                        | ldap_dn                                                | directory_uuid                       | ldap_dn_hash                                                     |
+--------------------------------------+--------------------------------------------------------+--------------------------------------+------------------------------------------------------------------+
| 43AD3B... | cn=du,ou=company,ou=users,ou=corp,dc=corp,dc=internal | 43AD3B... | 0e4fbce9dac2834a9 |
| 7cc9e9... | uid=du,ou=company,ou=users,ou=corp,dc=corp,dc=internal        | 7cc9e9... | b627c52106fbeebb9f |
+--------------------------------------+--------------------------------------------------------+--------------------------------------+------------------------------------------------------------------+
2 rows in set (0.001 sec)

The first entry is from an Active Directory, the second is an entry from a sync’ed OpenLDAP server.

Did ever, ever someone changed the LDAP type? Is there an approach to “search and replace” entries in the database?

Just for the sake of documentation, the following resources are useful: