<html><head>
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F4E79;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"><div>I think we may be at an impass, that what we want just isn't possible.</div><div><br></div><div>As I understand the original question, we don't want to be doing following referrals - that makes no sense in a filter parameter - the client is trying to use a SID in a filter (as this is more efficient and less subject to races if you know the SID), but that SID is not in the same domain as the server we are doing the filter on, it is over a trust within the same forest.</div><div><br></div><div>This also explains Christof's failure to reproduce the workaround, of client-side referral chasing with LDP, because it makes no sense in the protocol to get a referral in regards to a filter (referrals are for results in subtrees). Referral chasing in response to a filter would, if returned, encourage the client to re-issue the query to another domain, which would then be missing the base, for example. </div><div><br></div><div>As I understand the question, we had hoped that there would be a way for the server to be encouraged to do the SID -> DN lookup across the trust for us, again to reduce the race conditions and simplify the client. </div><div><br></div><div>Christof,</div><div><br></div><div>Does this match what you were asking and where you think we are at?</div><div><br></div><div>Andrew Bartlett</div><div><br></div><div>On Fri, 2022-11-18 at 16:43 +0000, Jeff McCashland (He/him) wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div class="WordSection1"><p class="MsoNormal"><span style="color:#1F4E79">Hi Andrew,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F4E79">The response from our LDAP team is:<o:p></o:p></span></p><p class="MsoNormal">Referral chasing is entirely client driven, it is not related to TLS, SASL, Delegation or other. The LDAP server gives the client a referral to another Naming Context that is a child of the Subtree search that was just performed. It is entirely up to the client what to do with that information and if it so chooses, it would establish a new connection and new Bind (with whichever auth method it chooses) to one of the DCs that host the referred naming context.<o:p></o:p></p><p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F4E79">I hope that helps!<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p><div><div><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">Best regards,</span><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:navy"><br><i>Jeff M</i></span></b><b><i><sup><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#002060">c</span></sup></i></b><b><i><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:navy">Cashland (He/him)</span></i></b><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:navy">| Senior Escalation Engineer<i> | Microsoft</i></span></b><b><span style="font-family:"Arial",sans-serif;color:navy"></span></b><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:navy">Protocol Open Specifications Team<o:p></o:p></span></b></p><p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:blue">Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:blue">Local country phone number found here:</span><span style="color:#2F5496"><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=02%7C01%7Cjeffm%40microsoft.com%7C92c4c7bb8c6d4412e78108d80d79f45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637274164726698458&sdata=KtEL7V58Q7rscYvr9cPik%2FmYKZIv0rh3E3kBdGywwwI%3D&reserved=0"><span style="font-size:8.0pt;font-family:"Arial",sans-serif">http://support.microsoft.com/globalenglish</span></a></span><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:blue"> | Extension 1138300<o:p></o:p></span></p></div></div></div></div><p class="MsoNormal"><span style="color:#1F4E79"><o:p> </o:p></span></p><div><div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Andrew Bartlett <abartlet@samba.org> <br><b>Sent:</b> Tuesday, November 15, 2022 11:44 AM<br><b>To:</b> Jeff McCashland (He/him) <jeffm@microsoft.com>; Christof Schmitt <cs@samba.org><br><b>Cc:</b> cifs-protocol@lists.samba.org; Microsoft Support <supportmail@microsoft.com><br><b>Subject:</b> Re: [EXTERNAL] Re: [cifs-protocol] [MS-ADTS] SID as DN alternative for querying groups by member - TrackingID#2209290040008412<o:p></o:p></p></div></div><p class="MsoNormal"><o:p> </o:p></p><div><p class="MsoNormal">On Tue, 2022-11-15 at 18:50 +0000, Jeff McCashland (He/him) wrote:<o:p></o:p></p></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><o:p> </o:p></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>1. Not using SASL/Kerberos<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>2. Not using signing and encryption<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>3. Attempting Simple Bind on cleart-text LDAP port rather than using TLS<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Do all of these need to be set?<o:p></o:p></pre></blockquote><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Following up on this, so given that Samba clients work hard to use Kerberos with SASL encryption (and not TLS due to issues around channel binding) that this feature won't work?<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Is it the case that on Windows this is a simple forwarding of the simple bind DN and cleartext password from one server to another, but that advanced techniques like S4U2Proxy are not used?<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Andrew Bartlett<o:p></o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><pre>-- <o:p></o:p></pre><div><p class="MsoNormal">Andrew Bartlett (he/him) <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F~abartlet%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C0ca71cdb73334e0d836808dac741cf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638041382724992818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=89Au16OKk9Edo%2B1gROP43LLBCUQ4GaGMbMgeN8triJw%3D&reserved=0">https://samba.org/~abartlet/</a><o:p></o:p></p></div><div><p class="MsoNormal">Samba Team Member (since 2001) <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C0ca71cdb73334e0d836808dac741cf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638041382724992818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xgEbYkWReiBrQolYEWRv8qwA9l3hUp8Ska9M2FwZ8Hk%3D&reserved=0">https://samba.org</a><o:p></o:p></p></div><div><p class="MsoNormal">Samba Team Lead, Catalyst IT <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcatalyst.net.nz%2Fservices%2Fsamba&data=05%7C01%7Cjeffm%40microsoft.com%7C0ca71cdb73334e0d836808dac741cf11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638041382724992818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=haEIb2XBnp401SmNQedAj1PcUEmfN%2FADjD2SpNWTxKw%3D&reserved=0">https://catalyst.net.nz/services/samba</a><o:p></o:p></p></div><div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal">Samba Development and Support, Catalyst IT - Expert Open Source Solutions<o:p></o:p></p></div></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div><div><p class="MsoNormal"><o:p> </o:p></p></div></div></div></blockquote><div><br></div><div><span><pre>-- <br></pre><pre>Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
</pre></span></div></body></html>