Bonjour,
Je poste ici un problème rencontré qui n’en est peut-être pas un ??
J’ai ouvert un post sur le forum de Yunohost ici: https://forum.yunohost.org/t/probleme-ldap-apres-ajout-au-sso-de-yunohost-dutilisateurs-deja-enregistres-dans-nextcloud-avec-registration/21334
et aussi sur le forum de Nextcloud:
https://help.nextcloud.com/t/having-trouble-with-user-authentification-ldap-on-yunohost-adding-an-existing-user-not-included-in-ldap-to-yunohost-ldap/146092/2
Pour faire court (comme j’ai déjà bien étoffé ces 2 topics), j’ai permis sur une instance Nexcloud propulsée par Yunohost, des inscriptions avec l’extension Registration. Du coup j’ai des utilisateurs non LDAP et les utilisateurs Yunohost sont dans le LDAP et appartiennent au group par défault all_users.
Puis pour certains, je veux les rajouter à Yunohost, sans perdre leurs datas, contacts, calendriers, partages…
Quand je créé un utilisateur Yunohost avec même nom d’utilisateur et même mot de passe, il peut se connecter via le sso et retrouve ses datas, etc…
Mais en fait Nextcloud a créé un autre utilisateur user_XXXX qui est rattaché, c’est lui qui est dans le groupe all_users, son dossier est vide (les données sont dans le dossier user), par contre user n’est pas dans le groupe all_users…
Je retrouve dans la documentation admin ce comportement:
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.
Les utilisateurs user_XXXX n’existent pas dans les utilisateurs actifs, ils sont dans le groupe all_users
Si je me connecte à mysql et regarde dans les tables oc_accounts_data
MariaDB [nextcloud]> SELECT * FROM oc_accounts_data;
il se passe un truc chelou !
Par exemple
| 10418 | user | displayname | User Name |
| 10419 | user | address | |
| 10420 | user | website | |
| 10421 | user | email | user@foo.tld |
| 10422 | user | phone | |
| 10423 | user | twitter |
et plus bas l’utilisateur bizarre, pourtant avec le mail du serveur yunohost !
| 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
J’ comprends absolument rien à ce mic-mac !!
Avec mysql, dans les bases de données, si je fais un
MariaDB [nextcloud]> SELECT * FROM oc_users;
Je ne vois que les noms des utilisateurs avec leur nom (et pas de utilisateur_XXXX), pareil pour MariaDB [nextcloud]> SELECT * FROM oc_user_status;
Par contre si je regarde cette table
MariaDB [nextcloud]> SELECT * FROM oc_ldap_user_mapping;
là j’ai une liste des utilisateurs yunohost et ceux qui ont été rajoutés après ont leur identifiant bizarre en user_XXXX au lieu du user
| user_7991 | uid=user,ou=users,dc=yunohost,dc=org
En fait, je ne sais pas si c’est vraiment un problème, c’est à dire quand je lis ceci: 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”. Je crois comprendre que les utilisateurs user et user_XXXX sont bien «attachés».
Est-ce que je peux laissé comme cela ?? C’est ma question, ça me semble pas terrible, d’où mon inquiétude…