[cifs-protocol] [EXTERNAL] Re: [MS-ADTS] SID as DN alternative for querying groups by member - TrackingID#2209290040008412

Andrew Bartlett abartlet at samba.org
Fri Nov 18 18:51:02 UTC 2022


I think we may be at an impass, that what we want just isn't possible.

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.

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. 

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. 

Christof,

Does this match what you were asking and where you think we are at?

Andrew Bartlett

On Fri, 2022-11-18 at 16:43 +0000, Jeff McCashland (He/him) wrote:
> Hi Andrew,
>  
> The response from our LDAP team is:
> 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.
>  
> I hope that helps!
>  
> Best regards,
> Jeff McCashland (He/him)| Senior Escalation Engineer |
> MicrosoftProtocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-
> 08:00) Pacific Time (US and Canada)
> Local country phone number found
> here:http://support.microsoft.com/globalenglish | Extension 1138300
>  
> From: Andrew Bartlett <abartlet at samba.org> 
> Sent: Tuesday, November 15, 2022 11:44 AM
> To: Jeff McCashland (He/him) <jeffm at microsoft.com>; Christof Schmitt
> <cs at samba.org>
> Cc: cifs-protocol at lists.samba.org; Microsoft Support
> <supportmail at microsoft.com>
> Subject: Re: [EXTERNAL] Re: [cifs-protocol] [MS-ADTS] SID as DN
> alternative for querying groups by member -
> TrackingID#2209290040008412
>  
> On Tue, 2022-11-15 at 18:50 +0000, Jeff McCashland (He/him) wrote:
> >  
> > > 1.    Not using SASL/Kerberos
> >  
> > > 2.    Not using signing and encryption
> >  
> > > 3.    Attempting Simple Bind on cleart-text LDAP port rather than using TLS
> >  
> >  
> >  
> > Do all of these need to be set?
>  
> 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?
>  
> 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?
>  
> Andrew Bartlett
>  
> -- 
> Andrew Bartlett (he/him)       https://samba.org/~abartlet/
> Samba Team Member (since 2001) https://samba.org
> Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba
>  
> Samba Development and Support, Catalyst IT - Expert Open Source
> Solutions
>  
>  
>  
>  

-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20221119/df82db35/attachment.htm>


More information about the cifs-protocol mailing list