[cifs-protocol] [EXTERNAL] Re: DirSync ACLs and Deleted Objects - TrackingID#2310230040015878
Andrew Bartlett
abartlet at samba.org
Thu Nov 9 05:31:14 UTC 2023
I think so. So is it:
IF (for each term)
dirSync per-object security modeparent does not allow visibility (no
specific requirement that this be due to CN=Deleted Objects)object and
attributes are otherwise visibleObject is deleted or recycledDeleted
or recycled attribute has changed since last sync
Thanks,
Andrew Bartlett
On Thu, 2023-11-09 at 05:10 +0000, Obaid Farooqi via cifs-protocol
wrote:
> Hi Andrew:
> Can you please let me know if the information I provided resolves
> your issue?
>
>
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
>
>
>
>
> From: Obaid Farooqi
>
> Sent: Tuesday, October 31, 2023 2:18 PM
>
> To: Andrew Bartlett <abartlet at samba.org>
>
> Cc: cifs-protocol mailing list <cifs-protocol at lists.samba.org>;
> Microsoft Support <supportmail at microsoft.com>
>
> Subject: RE: [EXTERNAL] Re: DirSync ACLs and Deleted Objects -
> TrackingID#2310230040015878
>
>
>
> Hi Andrew:
> Here is the logic for returning deleted and/or recycled state:
>
>
> dirSyn per-object security modeparent does not allow visibilityObject
> is deleted or recycledDeleted or recycled attribute has changed since
> last sync
>
> If LDAP_DIRSYNC_OBJECT_SECURITY is specified and all conditions above
> are true and caller has asked for deleted and/or recycled, just
> return the state of the object.
>
> The wording in the MS-ADTS for LDAP_DIRSYNC_OBJECT_SECURITY can also
> be made clearer. I’ll file a TDI to include above logic as well as
> clean up the existing wording. But before
> that, I want to know if the information above resolves your issue?
>
>
>
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
>
>
>
>
> From: Andrew Bartlett <abartlet at samba.org>
>
>
> Sent: Sunday, October 29, 2023 1:29 PM
>
> To: Obaid Farooqi <obaidf at microsoft.com>
>
> Cc: cifs-protocol mailing list <cifs-protocol at lists.samba.org>;
> Microsoft Support <supportmail at microsoft.com>
>
> Subject: [EXTERNAL] Re: DirSync ACLs and Deleted Objects -
> TrackingID#2310230040015878
>
>
>
>
> > Do you mean "whether an object is returned or not"?
>
>
>
>
>
> Yes.
>
>
>
>
>
> To expand further: In DirSync as described the behaviour is that a
> deleted object only returns the GUID and deletion state.
>
>
>
>
>
> What I mean by a filter attack is that because not all Deleted
> objects are returned, only those that match the filter, we can work
> out if the object matched the filter by noting if it was returned
> (just a GUID and deletion state), or not
> (no object returned).
>
>
>
>
>
> What I'm getting at is that it appears that the object ACLs,
> including list children, ACLs, are applied for other objects - we
> don't have an information leak for 'live' objects. But that isn't
> documented.
>
>
>
>
>
> And there seems to be some special codepath (required to keep this
> protocol plausibly working) for Deleted objects, either for all
> deleted objects or a specific exemption for the CN=Deleted Objects
> SD.
>
>
>
>
>
> Thanks so much for your assistance!
>
>
>
>
>
> Andrew Bartlett
>
>
>
>
>
> On Fri, 2023-10-27 at 19:29 +0000, Obaid Farooqi wrote:
>
> > Hi Andrew:
> > I'll help you with this issue.
> > I need a little clarification. I did not understand what you have
> > in the following sentence between dashes:
> > "They are stripped of most information, but a filter attack (eg
> > search for CN=a*) can be used to discover the values - an object is
> > returned nor not - showing that the objects are readable in that
> > context."
> >
> > Do you mean "whether an object is returned or not"?
> >
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> >
> > -----Original Message-----
> > From: Obaid Farooqi
> > Sent: Monday, October 23, 2023 5:18 PM
> > To: Andrew Bartlett <
> > abartlet at samba.org
> >
> > >
> > Cc: cifs-protocol mailing list <
> > cifs-protocol at lists.samba.org
> >
> > >; Microsoft Support <
> > supportmail at microsoft.com
> >
> > >
> > Subject: DirSync ACLs and Deleted Objects -
> > TrackingID#2310230040015878
> >
> > Hi Andrew:
> > Thanks for contacting Microsoft. I have created a case to track
> > this issue. A member of the open specifications team will be in
> > touch soon.
> >
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> >
> > -----Original Message-----
> > From: Andrew Bartlett <
> > abartlet at samba.org
> >
> > >
> > Sent: Monday, October 23, 2023 4:15 PM
> > To: cifs-protocol mailing list <
> > cifs-protocol at lists.samba.org
> >
> > >; Interoperability Documentation Help <
> > dochelp at microsoft.com
> >
> > >
> > Subject: [EXTERNAL] DirSync ACLs and Deleted Objects
> >
> > Hi Dochelp,
> >
> > MS-ADTS 3.1.1.3.4.1.3 LDAP_SERVER_DIRSYNC_OID describes
> > LDAP_DIRSYNC_OBJECT_SECURITY as:
> >
> > Windows Server 2003 operating system and later: If
> > this flag is present, the client can only view objects and
> > attributes
> > that are otherwise accessible to the client. If this flag is not
> > present, the
> > server checks if the client has access rights to read the changes
> > in the NC.
> >
> > Windows 2000 operating system: Not supported.
> >
> >
> > However, there is an exception. Objects that are deleted are
> > returned, despite the ACL on CN=Deleted objects. They are stripped
> > of most information, but a filter attack (eg search for CN=a*) can
> > be used to discover the values - an object is returned nor not -
> > showing that the objects are readable in that context.
> >
> > MSRC has just closed my case (82978) as it was determined this
> > issue doesn't cross any MSRC recognized security boundaries.
> >
> > However, neither is this documented. There is nothing in the above
> > reference nor in MS-DRSR 5.115.3 ProcessDirSyncSearchRequest that
> > explains how ACLs are applied to DirSync in the normal case, nor
> > the apparent exception for CN=Deleted Objects.
> >
> > The reason I say 'apparent exception' is that, if the ACL that
> > blocks 'list children' on CN=Deleted Objects were honoured, then:
> >
> > bin/ldbsearch -H ldap://192.168.122.230 -Uandrew%password ou=spy2\*
> > --
> > controls=dirsync:1:1:0
> > Can't load /usr/local/samba/etc/smb.conf - run testparm to debug it
> >
> > # record 1
> > dn:
> > objectGUID: 0ae90a39-9fbe-4a77-8651-abefa1f1eace
> > isDeleted: TRUE
> > isRecycled: TRUE
> >
> > Should not be able to return anything, and shouldn't indicate that
> > an object known previously as spy2 existed.
> >
> > From testing, it appears that only this special DN is excluded - if
> > we have an object that is hidden because the parent denies 'List
> > Children', then these don't show up. So, if we are going to get
> > our DirSync behaviour more consistent, we would like to be sure of
> > exactly what the rules are here.
> >
> > Thanks,
> >
> > Andrew Bartlett
> >
> > --
> > Andrew Bartlett (he/him)
> > https://samba.org/~abartlet/
> >
> >
> > Samba Team Member (since 2001)
> > https://samba.org/
> >
> >
> > Samba Team Lead
> > https://catalyst.net.nz/services/samba
> >
> >
> > Catalyst.Net Ltd
> >
> > Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
> > company
> >
> > Samba Development and Support:
> > https://catalyst.net.nz/services/samba
> >
> >
> >
> > Catalyst IT - Expert Open Source Solutions
> >
> >
> >
>
> --
>
> Andrew Bartlett (he/him) https://samba.org/~abartlet/
>
>
> Samba Team Member (since 2001)
> https://samba.org
>
>
> Samba Team Lead https://catalyst.net.nz/services/samba
>
>
> Catalyst.Net Ltd
>
>
>
>
>
> Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
> company
>
>
>
>
>
> Samba Development and Support:
> https://catalyst.net.nz/services/samba
>
>
>
>
>
> Catalyst IT - Expert Open Source Solutions
>
>
>
>
>
>
> _______________________________________________cifs-protocol mailing
> listcifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20231109/332d5f14/attachment.htm>
More information about the cifs-protocol
mailing list