[Samba] Synology shares not accessible...

Rowland Penny rpenny at samba.org
Thu Jun 29 08:00:13 UTC 2023

On 29/06/2023 07:38, Ingo Asche via samba wrote:
> Hi,
> there is some progress, even I would'nt call it that. At least they 
> admitted it's caused through some changes from their side.
> @Rowland: Remember that "old Samba method" part?
> This is their answer. I don't know what to make of it. Maybe someone 
> with more knowledge about the develoment of Samba can give me a hint:
> ================================================================================
> Being denied access is indeed influenced by our product design.
> As "Domain Client", in comparison to the newer version of open-source 
> Samba, we perform additional "lookupsids", which means we are affected 
> by the response from the AD server.
> Open-source Samba has already made changes in version 4.13 to no longer 
> perform lookupsids (samba#14539 
> <https://bugzilla.samba.org/show_bug.cgi?id=14539>), so the listed Samba 
> member servers will not be affected by invalid SIDs.
> However, the official modification will impact our ID mapping (recorded 
> in SYNOSMB#998), so we have reverted to the behavior prior to version 
> 4.13, where we perform lookupsids.
> Additionally, we have designed application privileges that require 
> information about the user's group list to determine if the user has 
> permission to use the SMB service.
> When the user's group list cannot be obtained, it will also result in a 
> failure with an "access denied" response.
> Here are the main issues related to lookupsids: receiving errors for 
> invalid SIDs.
> If the Samba AD Server returns "STATUS_SOME_UNMAPPED" the 
> above-mentioned problem will not occur.
> In terms of understanding, an invalid SID signifies a problem with the 
> format or structure of that SID, rather than its nonexistence.
> In addition, it appears that Samba has been returning this error code 
> for quite some time (STATUS_SOME_UNMAPPED) but changed to 
> (NT_STATUS_INVALID_SID) since Samba AD Server 4.17.x
> Users only need to add the Security Authentication Authority 
> (S-1-18-*)'s predefined_names_S_1_18 predefine patch to the Samba AD 
> code to make it work.
> But third-party AD servers (Samba AD Server) are beyond our control, so 
> we can only provide the reasons and solutions mentioned above.
> Otherwise, we recommend that users use an older version of AD or, at 
> least, have Windows clients joined to new Samba AD but use IP connections.
> Note: It is inevitable for open-source Samba to have certain 
> considerations and thus not suggesting User to apply the code since they 
> are not officially released. Who will guarantee code that hasn't been 
> officially released yet?
> ================================================================================

My reading of the above (which could be wrong) is:

A respected member of the Samba team decided that using 'lookupsids' 
wasn't required just to find out if the SID was a user or group, other 
Samba team members agreed and the code was altered and backported to a 
couple of earlier versions.

It would seem that synology disagreed with this, possibly because of 
other changes they have made (that is a pure guess) and have reverted 
that change, or to put it another way, they seem to have forked Samba. 
On top of that, they seem to be recommending using old EOL versions of 
Samba, versions that could contain bugs that have been fixed in later 
versions, these 'bugs' could be CVE related.

What conclusions to make from that is up to you, but this just confirms 
what I thought about synology.


More information about the samba mailing list