I am using ldap users from ad for authentication in Nextcloud which works be when looking at the users or searching for users to share with the lookup finds users by name but shows their sid and not the name.
What did I do wrong?
Thanks
Ian…
You should check your Expert Seetings of LDAP.
In all attributes check if it works with “cn”.
After that you could try to reset the user and group mapping. Same Register! But be careful with the Reset!
First try only to set the attrib as “cn” (nothing else without the taggs!!)
1 Like
Hi That sems to have fixed it for new users, Thanks.
Is there a way to get the existng users to show the accont name and not the sid without clearing the mapping and removing the users?
Thanks
Ian…
I suggest No.
It might need a “fresh” beginning.
But have a look at your server files …
I your data dir you should see all new and all old folders and files from your user accounts.
Save everything (!!!) - then reset all accounts. When every user loged in first time a new folder should be created with its user-/nickname!
Copy over the existing old files to your new user account folder on the server. Watch out for correct user access rights of all folders and files!
That should bring all things back to your user accounts - then with their real names 
I know this is a bit of a necro, but we ran into this with AD authentication in v15 and 16, and the fix was, as chrissi55 suggested, to use expert mode. Rather than using cn as the value, we selected sAMAccountName. This matched user names exactly to AD.
We also cleared the mapping and that brought all users in-line with the new settings.
2 Likes
I see the same issue. I am using plain LDAP rather than AD. I tried changing the “Internal Username” setting to cn and clicking on the “Clear Username LDAP Mapping” button. However, while this improves the situation, it isn’t quite right. To test this I created a user with the uid testuser. Their first name is “Test” and last name “User”. When i use cn instead of a random string of numbers and letters as the user name shown in the users list I get Test_User instead of testuser.
I can however log in to the account using the correct username testuser.
Can anyone suggest the correct thing to put here so it actually shows the correct username in the list of users?
I am resurrecting the old post as it is better to keep the information in one place
1 Like
To answer my own question, the solution in my case was to put uid in Internal Username Attribute and also in the “Override UUID detection section” change the “UUID Attribute for Users” to also be uid. Use at your own risk I’m a novice at LDAP. I don’t know if I actually needed it in the Internal Username Attribute or not, but I’m leaving it like that.
Although it says “Changes will have effect only on newly mapped (added) LDAP users and groups.” I clicked on the “Clear User Name” button and the correct name was now used for my test user.
1 Like
@crobarcro - You’re a hero, this exactly worked for me, as well. I’m running Nextcloud 19.0.1 on CentOS 8.2, and I set up Expert LDAP / AD integration exactly as you did:
- Internal Username Attribute: uid
- UUID Attribute for Users: uid
- Left-click "Clear Username-LDAP User Mapping button
That said, I’m pretty sure the problem still exists… we’ve just remapped the the UUID (which we WERE seeing) to take from the uid attribute. In my case, Nextcloud was using the value from ipaUniqueID, and Expert mode there lets me tell Nextcloud “No, don’t use ipaUniqueID for the UUID, use uid instead” and it’s mapping that.
Still doesn’t explain why uid isn’t just working in the first place. 
Changing the Expert mapping away from LDAP’s UID is a bad idea. If you ever have a user change their username, upn, or CN name, due to personal name change (marriage, divorce, etc) the user will NOT be able to login to Nextcloud. The mapping NEEDs to be an immutable value from LDAP/AD to avoid issues in the long run. This is why nextcloud defaults to a GUID value for the Intern UID, and hides the setting to change it under “Expert”.
We had this crop up when a name change occurred and we had mapped the Nextcloud UID to the UPN. They were forever locked out of nextcloud, because nextcloud doesn’t update the UID once its been set.
Only alternative is to go do “unsupported” changes inside the nextcloud database to manually change the Nextcloud UID to match the new value in LDAP or AD.
AD LDAP with nextcloud by default uses “objectGUID” which cannot be changed even in AD, this is a good thing, and the proper attribute to use for an LDAP matcher when using AD.
The real issue here is that the “UID” is used as a display name all over Nextcloud instead of the more logical “Display Name” attribute. Or even simply the “email” attribute that does get correctly updated inside nextcloud when changed in the upstream LDAP/AD directory.
I highly suggest anyone avoids changing the Expert setting for “internal username attribute”. It WILL lead to issues eventually if the attribute you chose ever changes. Things like “username” Samaccountname, userprinciplename, CN name, all get changed if the Person’s actual name changes, so you can easily get stuck with this issue down the road.
The problem, when you use default config and have the immutable UUID, the webdav url can’t be access without the UUID … So you can’t mass connect Network shared to https://xxx/remote.php/dav/files/%username%/)