Have to keep logging in to synology console for AD users to be able to connect
pluckyhd opened this issue · 11 comments
I am seeing where the mapped drives constantly lose connection due to credentials on windows pcs. If I relogon the user direct to the synology dashboard (as we have to do initially) the share regains permissions. leading me to believe its being reset after it validates. Has anyone else seen this issue?
I am curious if it becauase we use MFA. It works once we login but not then eventually "times out" and we have to relogin to the NAS directly for access again.
I had the behavior at the very beginning once. A user had created very many teams groups. At the beginning all groups (also from teams) were synchronized. Synology then suddenly messed up the permissions from time to time. As a workaround I used the group filter to synchronize only the security groups (GRAPH_FILTER_GROUPS=securityEnabled eq true). After that the problem did not occur anymore.
I'll leave the issue open for a while. Maybe more people will report here with their experiences :)
I've just been through the same issue of randomly disappearing folder shares for LDAP-wrapper users. In our case the Synology NAS drive had been upgraded from DSM 6 and what isn't apparent is that DSM 7 will not treat LDAP permissions on shared folders reliably unless to upgrade each share to Windows ACL. I've put a full explanation of our experience on the Synology forum
Further to my earlier comment, we are still suffering disappearing folder shares in SMB where the share permissions are set against Groups rather than Users. It almost seems like the synchronisation of the Group data is failing and therefore cannot be applied to the folder share until an admin takes an action to update the LDAP data.
@calummacleanmtl
For us it has helped with exactly that issue to enable the "Enable UID/GUIS shifting"
@noque-lind
Thanks for that pointer. I've implemented that but now whilst user permissions and groups are applying correctly, access through SMB is not working at all. Has anyone else seen similar issues ?
We are experiencing similar issues. We had it working (even without "Enable UID/GID shifting") but after some time it (access to smb, not the web portal) stopped working altogether, for all users. Tried "Enable UID/GID shifting" without success. The LDAP users are all correctly showing, with correct permissions, but are not getting access to the shares when trying to access via Explorer on Windows 11.
I got everything working with the UID/GID shifting but to access the UID/GID shifting option, I had to leave the LDAP directory and join it again. I then had further issues because I had accidentally added a space into the LDAP_SAMBADOMAIN variable. Seems obvious now but "dc=example, dc=com" would only recognise logins from user@example and rejects user@example.com. I found that problem by searching the log files.
The random effects of not using UID/GID shifting are that you MIGHT have the same userid or groupid in the Synology device account list which is the same as a userid in the LDAP directory. This doesn't cause any problem for logging in through the web portal to get to files, but Samba relies on checking the userid permissions and inherited groupid permissions to see what you can get access to. You may have no conflict to start with and all works OK, but after adding some more users or groups, a conflict can then occur. With UID/GID shifting Synology adds 1,000,000 to the ID's of LDAP users and groups.
When there is a userid conflict between the device accounts and LDAP, the results are more unpredictable than you can imagine. Shares may be available in Samba intially on login, then are blocked within a minute. Logging into the web portal sometimes made them accessible in Samba again momentarily.
I got everything working with the UID/GID shifting but to access the UID/GID shifting option, I had to leave the LDAP directory and join it again. I then had further issues because I had accidentally added a space into the LDAP_SAMBADOMAIN variable. Seems obvious now but "dc=example, dc=com" would only recognise logins from user@example and rejects user@example.com. I found that problem by searching the log files.
The random effects of not using UID/GID shifting are that you MIGHT have the same userid or groupid in the Synology device account list which is the same as a userid in the LDAP directory. This doesn't cause any problem for logging in through the web portal to get to files, but Samba relies on checking the userid permissions and inherited groupid permissions to see what you can get access to. You may have no conflict to start with and all works OK, but after adding some more users or groups, a conflict can then occur. With UID/GID shifting Synology adds 1,000,000 to the ID's of LDAP users and groups.
When there is a userid conflict between the device accounts and LDAP, the results are more unpredictable than you can imagine. Shares may be available in Samba intially on login, then are blocked within a minute. Logging into the web portal sometimes made them accessible in Samba again momentarily.
Thanks, I read your issue about these problems and made sure I do not have them.
Could it be that it somehow cached the LDAP uids etc. (from when I didn't have UID/GID shifting enabled) ? I have deleted the persistent docker storage but would assume these uids may be stored somewhere in the synology settings..
During my fault finding, I discovered that there is a difference between the way that DSM 6 and 7 manage SMB permissions for LDAP. In DSM 6, there is an smb.share.conf file created that stores the allow/deny permissions for LDAP users and groups on SMB shares. In contrast I found after much confusion that migrating to DSM 7, the smb.share.conf file does not get updated or accessed. I think that DSM 7 queries the LDAP service directly whilst DSM 6 uses a config file. It's always a good idea to clear the SMB cache if there are issues: Control Panel > File Services > SMB Settings > Advanced Settings.