Set the Federated Cloud ID to something "nice"

ℹ️ Support
1

I am running a Nextcloud installation on my own domain together with some other web applications. Hence, the subdomain which hosts Nextcloud is cloud.my-domain.tld. User accounts follow the pattern <firstname>.<lastname>. All web applications, incl. Nextcloud, use LDAP authentication. Moreover, each user has a mail address with the pattern <firstname>.<lastname>@my-domain.tld.

Currently, Nextcloud generates Federated Cloud IDs which look like <long-incomprehensible-uuid>@cloud.my-domain.tld.

Two questions:

  1. Is it possible to change the domain part to my-domain.tld (instead of cloud.my-domain.tld) so that is is identical to the mail domain?
  2. Is it possible to use the actual user name, i.e. <firstname>.<lastname>, as the local part (i.e. the part before the @-sign) as the Federated Cloud ID? This LDAP UUID is not user-friendly.
2
  1. No
  2. No

Much luck,
ernolf

3

With respect to question 2:

NC uses the name of the local NC account as the local-part of the Federated Cloud ID. If one configures the “LDAP User and Group Backend” such that it does not draw a random UUID for the local NC accounts which mirror the LDAP accounts, but to use a (unique) LDAP attribute, e.g. the uid attribute, then the local-part will be that value (also the sub-directories inside the data-directory with the personal files of each user will become more readable).

For my setup the necessary options were:

+-------------------------+-------------+
| Configuration           | s01         |
+-------------------------+-------------+
| ldapExperiencedAdmin    | 1           |
| ldapExpertUUIDGroupAttr | cn          |
| ldapExpertUUIDUserAttr  | uid         |
| ldapExpertUsernameAttr  | uid         |
| ldapGidNumber           | cn          |
| ldapGroupDisplayName    | displayName |
| ldapUserDisplayName     | displayName |
| ldapUserDisplayName2    | mail        |
+-------------------------+-------------+
1 Like
4

Yes, it is possible to set the Federal Cloud ID to any value. I had changed the domain, had already created a lot of users and had to change them to the new domain. I am running NC27 with mariadb under docker.

The Federal Cloud ID is stored in the oc_cards and oc_cards_properties tables and can be changed there:

  1. Put NC in maintenance mode:
    docker exec -u www-data nextcloud php occ maintenance:mode --on

  2. Read tables:
    docker exec mariadb mariadb-dump -u user -pPW database oc_cards_properties >oc_cards_properties.org.sql
    docker exec mariadb mariadb-dump -u user -pPW database oc_cards >oc_cards.org.sql

  3. Copy (save) and edit tables:
    cp -a oc_cards_properties.org.sql oc_cards_properties.sql
    cp -a oc_cards.org.sql oc_cards.sql
    mcedit oc_cards_properties.sql
    mcedit oc_cards.sql

  4. Transfer back tables with changed content:
    cat oc_cards_properties.sql|docker exec --interactive mariadb mariadb -u user -pPW database
    cat oc_cards.sql|docker exec --interactive mariadb mariadb -u user -pPW database

  5. Switch off maintenance mode:
    docker exec -u www-data nextcloud php occ maintenance:mode --off

1 Like
5

Are there any known drawbacks if the federated cloud ID is changed manually, especially regarding synchronization of OC cards across federated NC servers?

I once restored a user manually which (obviously) had the same uid as the previous user and that led to to some follow-up errors during synchronization. Some other server had still cashed the user with that uid but with a different “etag” and then complained during synchronization about a unique id constraint validation. The solution was to delete that stalled, offending user entry from the other NC servers which still had that uid cached.

I am wondering if there could be similar effects I should be prepared of when I change the Federated Cloud ID.

1 Like
6

Cool that you figured that out :+1:
did you test this between multiple servers?
… that would (imho) only be possible for the part before the @ sign (Q 1 of OP) since the part behind the @ sign would break the functionality in the fediverse. :thinking:

ernolf

7

Manually changing (probably intentional) unchangeable values to “any value” naturally opens the door to all sorts of mischief.

My problem was a specific one: The manual regarding the domain change is clear, it is “not supported”. And so the IDs after the change from olddomain to newdomain all remained nickname@olddomain. I had to fix this by changing all nickname@olddomain to nickname@newdomain. This works great with the procedure above and a text editor using search/replace, but you certainly shouldn’t make any mistakes.