DSM 7.0 Bug? LDAP user/group permissions merged with DSM user/group of same name

[fredbert]

I have joined my NAS to LDAP Server so that I have a second set of accounts. The DSM local user/group is the main one used for virtually everything, while LDAP is for second accounts used for Mail Server (to hide the .Maildir folder which would be visible in File Station), and VPN Server and SRM's VPN Plus. The DSM local user would be 'fred' and the LDAP user '[email protected]'.

When I set this up in DSM 6 I made the LDAP account have very restricted access to DSM 's other features, including assigning No Access to shared folders. Having migrated to DSM 7 I now have found, through a lot of trial and error, that DSM local users and groups that have an equivalent in LDAP will get assigned the LDAP's permissions. Noting that restrictive permissions get priority over permissive then this resulted in the DSM users and groups losing access to shared folders and some packages.

Further it seems that not all packages are affected, mostly it seems to be affecting file system related packages: File System and SMB are while SFTP and WebDAV are not, and neither are things like Drive (except for accessing Team folders). It was loss of access to a Team folder in Drive that first alerted me to this.

I've made a temporary renaming in LDAP Server's user names so that '[email protected]' is, e.g., '[email protected]'. This then gets propagated into whichever packages are being used.

The main thing to avoid is putting restrictive privileges to LDAP '[email protected]' group as this affects DSM's 'users' group, and so other groups.


Raised to Synology Support.

 

[fredbert]

Re Mail Server, using aliases of the old LDAP (DSM name) ‘fred’ to the new full LDAP name ‘[email protected]’ keeps the mail flowing as before.

 

[fredbert]

An update to this issue that I've experienced after many mails back and forth. Now has been taken up with HQ engineering but the situation, so far still exists.

Since changing the LDAP account name (short name) to not be the same as a DSM local name I find that changing it back will cause DSM to block access to its Edit settings. But this account still takes permissions from any LDAP group permissions.

I'm still seeing a DSM local user getting blocked to SMB due to the short named LDAP user's group permission being either not set or No Access.

While this may seem somewhat trivial for a home user, but what would be the impact of wanting to merge a user base where you can't easily rename accounts?

On a more interesting note, when logging into DSM (didn't try other service logins) using just a short name from LDAP will work ... this doesn't work if there's already a DSM local user with the same name.

* a short name in LDAP is the bit before the '@domain.com'

 

[fredbert]

Coming back to this as it's nearing an end. The original issue was that I have two sets of user accounts:

1. DSM local users
2. LDAP users

Each person has an account in each set (with the same short name), where the local accounts have SMB access but the LDAP do not.:

1. Local 'fred' for main access to packages and services.
2. LDAP 'fred@domain' for VPN access and Mail Server, plus DSM portal to manage their password.

After upgrading to DSM 7 I found that an SMB connection for 'fred' would fail, but if I changed the corresponding LDAP to, e.g., 'fred2@domain' then the connection for 'fred' succeeded. In DSM 6 local 'fred' could connect when there was LDAP 'fred@domain'.

After a long session of messages with Synology Support and having provided access we discovered that creating a new pair of local/LDAP accounts with the same SMB permissions did exhibit the problem. But left all my original accounts with the SMB issue. To address this 'a fix' was applied by Support, escalated to HQ engineering, so that now it works more or less as expected except for something discovered about Mac Finder when connecting to the NAS.

1. Scenario 1: Both accounts have the same password:
   1. Local 'fred': connects to DSM 'fred' shares.
   2. LDAP 'fred@domain': connects to DSM 'fred' shares.
2. Scenario 2: DSM and LDAP accounts have different passwords:
   1. Local 'fred': connects to DSM 'fred' shares.
   2. LDAP 'fred@domain': connection refused.

The response from Support was that they have identified that Mac's Finder will try to use the local account (i.e. just the shortname) when the LDAP authentication fails. I wonder if this is partly due to my Mac's network settings having 'domain' set as its search domain?

I tried the above scenarios using another Mac application, FileBrowser Pro, and it failed to connect in test 1.2 above. So Mac's Finder is trying to be smart and ends up connecting to the wrong NAS account (local one) when both accounts have the same password and LDAP account isn't allowed to use SMB access.


The long and the short of this is: it's best to avoid using reusing short names in local and LDAP accounts. Also use a different mix of password formula rules to try to avoid having the same password for local and LDAP accounts (if you are providing people with a pair of accounts, like me).