[Samba] Synology shares not accessible...

[Ingo Asche]

Hi Matthias,

thanks for your input, but you should have read the complete trail...

This has nothing to do with SMB1 or such things.

Their Samba, called SMB-Service, worked as version 4.15.9-0619 (Their 
build of Samba 4.15.9) with my 4.17.8 AD domain and with new version 
4.15.9-0632 no longer.

They admitted it has to do with the mentioned bug report, which they 
reversed in their version. One of their recommendation was to use an 
older Samba version as DC, which is inacceptable or connect via IP.

Regards
Ingo
https://github.com/WAdama

Matthias Kühne | Ellerhold Aktiengesellschaft via samba schrieb am 
29.06.2023 um 10:38:
> Hallo,
>
> just my 2 cents: So Samba 4.12 works, but 4.13+ doesnt?
>
> Maybe you can use the same strategy here as used for Win XP or older OS:
> Setup an isolated (virtualized?) DC with samba 4.12 just for the
> synology to connect to? You could use firewalld/ufw rules to only allow
> traffic to the samba ports from one single source IP-adress (the
> synology) to limit the exposure...
>
> Just until synology fixes the bug?
>
> Is Samba 4.12 AD compatible with 4.18?
>
> Have a nice day, Matthias.
>
> Am 29.06.23 um 10:00 schrieb Rowland Penny via samba:
>>
>> 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.
>>
>> Rowland
>>
>>