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

[Jeff McCashland (He/him)]

Hi Christof,

Thank you for the follow up. I will raise the question of documentation with our LDAP team. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol 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

-----Original Message-----
From: Christof Schmitt <cs at samba.org> 
Sent: Monday, November 21, 2022 12:24 PM
To: Andrew Bartlett <abartlet at samba.org>
Cc: Jeff McCashland (He/him) <jeffm at microsoft.com>; 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 Sat, Nov 19, 2022 at 07:51:02AM +1300, Andrew Bartlett wrote:
>    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

The driver of this is the attempt to implement a poor workaround for the missing S4U2SELF support in Samba. The current code falls back to LDAP queries, but those do not cover the case where a user is in a trusted domain, but it then a member of a group in the local domain where Samba is joined. Probably there are many more cases that cannot be covered, but i am looking at this one in particular.

This dochelp query was driven by the observation that the group membership can be queried by DN and GUID, but not by SID, and this difference is not obvious from documentation. Now my understanding is that this particular case of querying the group by the SID of a member requires LDAP referral chasing, so this won't be useful for the usecase here.

>From my side, this query can be closed. I just want to leave the question, whether it would make sense to add a comment to the documentation that referral chasing is required for this particular scenario.

Regards,

Christof