Nextcloud version: 24.0.4
Operating system and version: Yunohost 11.0.9.14
nginx: nginx-extras/stable,now 1.18.0-6.1+deb11u2 amd64
PHP version: 8.0
The issue you are facing:
I have added some users on the Nextcloud instance with the plugin Registration. The users added by this way are not included in the LDAP which is configured with Yunohost and his SSO.
I thought it was possible to add some of them to the Yunohost LDAP creating a user with the admin Yunohost with the same name and same password.
Doing this seems matching, the user created in the Yunohost’s LDAP can connect to the SSO and also in Nextcloud, he keep all his datas, contacts, calendars and shares.
But, something happened, normally the Yunohost’s users are included in the group all_users
. Here, the users added on the LDAP are not in this group. A new folder have been created with like user_XXXX
(where XXXX is a number). This user user_XXXX
is on the group all_users
, but he is not in the users activated and his folder is empty.
for example:
par exemple:
~# ls -l /home/yunohost.app/nextcloud/data/user_7590/
total 0
~# ls -la /home/yunohost.app/nextcloud/data/user_7590/
total 8
drwxr-xr-x 2 nextcloud nextcloud 4096 Sep 14 15:47 .
drwxr-x--- 36 nextcloud nextcloud 4096 Sep 18 12:27 ..
Connecting to mysql and reading the tables I see this:
table oc_accounts_data
MariaDB [nextcloud]> SELECT * FROM oc_accounts_data;
| 10418 | user | displayname | User Name |
| 10419 | user | address | |
| 10420 | user | website | |
| 10421 | user | email | user@foo.tld |
| 10422 | user | phone | |
| 10423 | user | twitter |
and later the user_XXXX
(same user
name)
| 11879 | user_7590 | displayname | User Name |
| 11880 | user_7590 | address | |
| 11881 | user_7590 | website | |
| 11882 | user_7590 | email | user@nom_domaine_yunohost.tld |
| 11883 | user_7590 | phone | |
| 11884 | user_7590 | twitter | |
| 11885 | user_7590 | organisation | |
| 11886 | user_7590 | role | |
| 11887 | user_7590 | headline | |
| 11888 | user_7590 | biography | |
| 11889 | user_7590 | profile_enabled | 1
If I do
MariaDB [nextcloud]> SELECT * FROM oc_users;
I see only the users (no user_XXXX
), also in
MariaDB [nextcloud]> SELECT * FROM oc_user_status;
But on LDAP tables
MariaDB [nextcloud]> SELECT * FROM oc_ldap_user_mapping;
Here I see only user_XXXX
in fact of user
but the uid is user
| user_7991 | uid=user,ou=users,dc=yunohost,dc=org
The filter for Users in LDAP settings on Yunohost is:
(&(|(objectclass=posixAccount))(|(memberof=cn=admins,ou=groups,dc=yunohost,dc=org)(memberof=cn=all_users,ou=groups,dc=yunohost,dc=org)))
The filter for login attributes is:
(&(&(|(objectclass=posixAccount))(|(memberof=cn=admins,ou=groups,dc=yunohost,dc=org)(memberof=cn=all_users,ou=groups,dc=yunohost,dc=org)))(uid=%uid))
The filter for Goups
(&(objectclass=top)(memberUid=*))
So, I need a clarification, can I stay like this ? I can’t understand why the user is not in the LDAP but can be connected with the SSO, so with the user_XXXX
, I imagine. Do I have to do something to resolve this ? Or is it secure ?
In the admin documentation I can read this, but I am not sure understand all:
Internal Username:
The internal username is the identifier in Nextcloud for LDAP users. By default it will be created from the UUID attribute. The UUID attribute ensures that the username is unique, and that characters do not need to be converted. Only these characters are allowed: [a-zA-Z0-9_.@-]. Other characters are replaced with their ASCII equivalents, or are simply omitted.
The LDAP backend ensures that there are no duplicate internal usernames in Nextcloud, i.e. that it is checking all other activated user backends (including local Nextcloud users). On collisions a random number (between 1000 and 9999) will be attached to the retrieved value. For example, if “alice” exists, the next username may be “alice_1337”.
The internal username is the default name for the user home folder in Nextcloud. It is also a part of remote URLs, for instance for all *DAV services.
You can override all of this with the Internal Username setting. Leave it empty for default behavior. Changes will affect only newly mapped LDAP users.
When configuring this, be aware that the username in Nextcloud is considered immutable and cannot be changed afterwards. This can cause issues when using an attribute that might change, e.g. the email address of a user that will get changed during name change.