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
Mostly you have second what I thought already. At least what they say about using an old Samba version. Another thought just accured to me: But why they changed it after three years the change is already in use. Why now? But as you said, that's something only Synology can answer. Regards Ingo https://github.com/WAdama Rowland Penny via samba schrieb am 29.06.2023 um 10:00:> > 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 > >
Matthias Kühne | Ellerhold Aktiengesellschaft
2023-Jun-29 08:38 UTC
[Samba] Synology shares not accessible...
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 > >-- Senior Webentwickler Datenschutzbeauftragter Ellerhold Aktiengesellschaft Friedrich-List-Str. 4 01445 Radebeul Telefon: +49 (0) 351 83933-61 Web: www.ellerhold.de Facebook: www.facebook.com/ellerhold.gruppe Instagram: www.instagram.com/ellerhold.gruppe Twitter: https://twitter.com/EllerholdGruppe Amtsgericht Dresden / HRB 23769 Vorstand: Stephan Ellerhold, Maximilian Ellerhold Vorsitzender des Aufsichtsrates: Frank Ellerhold ---Diese E-Mail und Ihre Anlagen enthalten vertrauliche Mitteilungen. Sollten Sie nicht der beabsichtigte Adressat sein, so bitten wir Sie um Mitteilung und um sofortiges l?schen dieser E-Mail und der Anlagen. Unsere Hinweise zum Datenschutz finden Sie hier: http://www.ellerhold.de/datenschutz/ This e-mail and its attachments are privileged and confidential. If you are not the intended recipient, please notify us and immediately delete this e-mail and its attachments. You can find our privacy policy here: http://www.ellerhold.de/datenschutz/