TLDR for this topic and visitors who find it in the future: BEFORE YOU LOG IN YOUR FIRST LDAP USER, if you want sAMAccountName based user ids and storage paths (rather than cryptic GUID) study up on your LDAP settings – because it will be a PITA to change it after the fact.
Hi,
We’re using LDAP authentication and have it working fine.
The only dislike about it is that each user “account” as far as Nextcloud is concerned for each user is this long HEX value like…
4573E888-357C-437D-8FF6-CED99EF1AA9C Joe Username
Users can authenticate using the (windows doamin) sAMAccountName just fine, which is great.
It would just make more sense for us (and be easily readable) if users were listed by their unique sAMAccountName and had their docs stored in:
You are referring to the GUID. You can change this to use the sAMAccountName instead for the username. It’s on one of the advanced tabs in the LDAP configuration.
Ah I wish I had seen those ADVANCED | EXPERT tab options hiding in the top right corner when first setting up!
What would be the impact of changing EXPERT > Internal Username = sAMAccountName now?
In productive (but test) environment we have…
Users are setup with GUID already
Users data path is based on GUID (i.e. /var/www/nextcloud/data/GUID)
We have users in groups
We have group folders with access linked to groups
Users may have personal files/folders shared
Users may have calendar items
So I’m thinking my migration plan in order to switch over to sAMAccountName is…
Make note in external spreadsheet of group mapping to group folders
Make note in external spreadsheet of users (including GUID, paths, group memberships)
Wait until off hours / low usage time
TAKE A SNAPSHOT of the system (using ZFS filesystem) – for rollback in case of disasterous results
cp -Rp /var/www/nextcloud/data/FOR_EACH_GUID /tmp/NEXTCLOUD_GUID_DATA_BACKUP/FOR_EACH_GUID
(probably a better/fancy way to do this with sed/awk to match GUID type dir names, but I have small number of users so I can do this manually. My goal is to not backup __groupfolders and other folders)
Change EXPERT > Internal Username to = sAMAccountName - EXPERT > Username-LDAP User Mapping > CLEAR USERNAME-LDAP MAPPING (???) - EXPERT > GroupName-LDAP User Mapping > CLEAR GROUPNAME-LDAP MAPPING (???)
(not sure if I should clear these?.. I guess I’ll find out.)
Log in one of my existing GUID-based test users who has…
– Calendar entries
– Local shares with inviduals
– Local shares with groups
– Member of group shares
And see what happens.
If a new data path is created on the login (which I expect) like /var/www/nextcloud/data/USERNAME then I would need to then migrate that users files from /tmp/NEXTCLOUD_GUID_DATA_BACKUP/USERNAME to the new location… and cross my fingers I guess.
OTOH, for some people an easier/safer way to solve the problem (wanting to see sAMAccountName in the user list) may be to use the field…
ADVANCED > Directory Settings > 2nd User Display Name Field = samaccountname
This will now make your users in list look like this:
4573E888-357C-437D-8FF6-CED99EF1AA9C Joe Username(JoeUsername123)
(where JoeUsername123 is the persons samaccountname)
I may just leave it like this to avoid the headaches of relinking and migrating/moving files around, worrying about broken calendar entries, permissions in/on groups and group folders.
I can probably convince myself that the GUID based paths in data/ add some very minor level of security through obscurity as well. Right? Yeah. Ok… I think that’s solved. for me
Although I will probably open request to allow username searching by more than displayname.
I could be mistaken but I think what happens is users already created will retain their GUID name and new ones will be created with the sAMAccountName as they log in.
This is one of those settings it’s best not to change after setting up. I personally don’t like the GUIDs and have done a couple setups with the sAMAccountName with no problems. The sAMAccountName also has to be unique so there should not be any problem with name collisions.
Yeah, I was thinking that might be how it works until / if you don’t clear the LDAP link… whatever is in the system is what it is. So old users would be uid by GUID (objectGUID?) and new users would be named by sAMAccountName.
Also, I did also notice the option:
ADVANCED > Special Attributes > User Home Folder Naming Rule
Which I assume you can set to something to represent GUID (objectGUID?) if you wanted to keep (and continue) using the existing GUID based data paths – and have new users paths created in the same manner. Theory… haven’t tested.
I’ve only cleared the LDAP link on test installations, or before any of the LDAP accounts were actually used. There’s a fairly ominous warning next to the big red button, and I don’t know all of the ramifications of doing it, so take care if you go that route.
The best advice I can give on that is get it squared away how you like it before you unleash your users on it.
