<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Hi Douglas,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks for the update and additional information. Sree is taking point on Q2 and will continue to dig into it. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: Arial, sans-serif; font-size: 10pt; color: blue;">Best regards,</span><span style="font-family: Arial, sans-serif; font-size: 10pt; color: navy;"><b><br>
<i>Jeff M</i></b></span><span style="font-family: Arial, sans-serif; font-size: 10pt; color: rgb(0, 32, 96);"><b><i><sup>c</sup></i></b></span><span style="font-family: Arial, sans-serif; font-size: 10pt; color: navy;"><b><i>Cashland (He/him)
</i>| Senior Escalation Engineer | Microsoft Corporation</b></span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: Arial, sans-serif; font-size: 9pt; color: blue;">Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"><span style="font-family: Arial, sans-serif; font-size: 8pt; color: blue;">Local country phone number found here:
<u><a href="http://support.microsoft.com/globalenglish" style="color: blue; margin-top: 0px; margin-bottom: 0px;">http://support.microsoft.com/globalenglish</a></u> | Extension 1138300</span></p>
<p style="margin: 0in; font-family: Calibri, sans-serif; font-size: 11pt;"> </p>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Douglas Bagnall <douglas.bagnall@catalyst.net.nz><br>
<b>Sent:</b> Tuesday, May 14, 2024 3:21 PM<br>
<b>To:</b> Jeff McCashland (He/him) <jeffm@microsoft.com><br>
<b>Cc:</b> cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>; Sreekanth Nadendla <srenaden@microsoft.com>; Microsoft Support <supportmail@microsoft.com><br>
<b>Subject:</b> [EXTERNAL] Re: [MS-DTYP] canonical ACL sort order Q4 - TrackingID#2405080040008294</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Thanks Jeff.<br>
<br>
That is helpful. I am happy to not worry about SACL ordering.<br>
<br>
>> Does that help? What problem are you trying to solve?<br>
<br>
What I am doing is looking over the code Samba has to ensure an ACL is in <br>
canonical order (we do it in four places, slightly differently each time).<br>
<br>
The main question probably the one called "Q2 - TrackingID#2405080040008193", <br>
about where callback ACEs go.<br>
<br>
I had naively assumed there would be a Windows API function for putting an ACL <br>
in the correct order which I could use to make test cases. I realise now that is <br>
impossible without knowing the inheritance tree.<br>
<br>
cheers,<br>
Douglas<br>
<br>
<br>
<br>
On 15/05/24 04:43, Jeff McCashland (He/him) wrote:<br>
> Hi Douglas,<br>
> <br>
> I reviewed the Windows source code where SACLs are processed, and I did not see
<br>
> any indication of a required or preferred order to SACL ACEs. However, I did <br>
> notice that when we process SACLs, we process the ACEs in this order: Audit, <br>
> Label (including trust label and filtering), Attribute, then Scope. However, <br>
> there's no reason to believe the ACEs need to be in this order. Also, I found a
<br>
> couple of notes to the effect that allow/deny has no effect on the ordering of <br>
> Audit ACEs, and Object ACEs follow non-Object ACEs.<br>
> <br>
> Does that help? What problem are you trying to solve?<br>
> <br>
> Best regards,*<br>
> /Jeff M/**/^c /**/Cashland (He/him) /| Senior Escalation Engineer | <br>
> Microsoft Corporation*<br>
> <br>
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) <br>
> Pacific Time (US and Canada)<br>
> <br>
> Local country phone number found here: <br>
> _https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916051257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zNUrAR0UKNO8D3RDTJBcDH1z6q3gejIv9ewH6mXNkT4%3D&reserved=0
<br>
> <<a href="http://support.microsoft.com/globalenglish">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916056569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XTKb7e4DYWieyuOOZ7JBwWlP5jqfFSdJUCJtGSJJhqM%3D&reserved=0</a>>_ |
Extension 1138300<br>
> <br>
> --------------------------------------------------------------------------------<br>
> *From:* Jeff McCashland (He/him) <jeffm@microsoft.com><br>
> *Sent:* Wednesday, May 8, 2024 11:12 AM<br>
> *To:* Douglas Bagnall <douglas.bagnall@catalyst.net.nz><br>
> *Cc:* cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>; Sreekanth <br>
> Nadendla <srenaden@microsoft.com>; Microsoft Support <supportmail@microsoft.com><br>
> *Subject:* Re: [MS-DTYP] canonical ACL sort order Q4 - TrackingID#2405080040008294<br>
> Hi Douglas,<br>
> <br>
> I will research your question and let you know what I find.<br>
> <br>
> Best regards,*<br>
> /Jeff M/**/^c /**/Cashland (He/him) /| Senior Escalation Engineer | <br>
> Microsoft Corporation*<br>
> <br>
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) <br>
> Pacific Time (US and Canada)<br>
> <br>
> Local country phone number found here: <br>
> _https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916059557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BT33TE%2FS77FSH%2FWC1fTeaxuyUGqUVg5S9pCXzRoeoC8%3D&reserved=0
<br>
> <<a href="http://support.microsoft.com/globalenglish">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916062264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iN2TpHYXM6DutixPu6FtUGoWaMdyhboEBt8zif4s%2B7Q%3D&reserved=0</a>>_ |
Extension 1138300<br>
> <br>
> --------------------------------------------------------------------------------<br>
> *From:* Sreekanth Nadendla <srenaden@microsoft.com><br>
> *Sent:* Wednesday, May 8, 2024 8:54 AM<br>
> *To:* Douglas Bagnall <douglas.bagnall@catalyst.net.nz><br>
> *Cc:* cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org><br>
> *Subject:* [MS-DTYP] canonical ACL sort order Q4 - TrackingID#2405080040008294<br>
> Dochelp in Bcc<br>
> <br>
> Hello Douglas, this e-mail thread will be used to track the investigation for <br>
> the following issue<br>
> <br>
> *ISSUE:*<br>
> <br>
> There are a wide range of formulations of canonicity, from<br>
> Microsoft and elsewhere, not all of which can be compatible. For<br>
> example,<br>
> <a href="https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonacl?view=net-8.0">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.security.accesscontrol.commonacl%3Fview%3Dnet-8.0&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916064855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iFwSXfzevBIV%2Fx3x6L0pXQAvYSMybdJR8qj7leFdUxE%3D&reserved=0</a><br>
> would not sort the ACEs lexicographically, but by SID.<br>
> <br>
> *Do SACLs have a canonical ordering, beyond having explicit ACEs first?*<br>
> <br>
> Regards,<br>
> <br>
> Sreekanth Nadendla<br>
> <br>
> Microsoft Windows Open Specifications<br>
> <br>
> <br>
> --------------------------------------------------------------------------------<br>
> *From:* Douglas Bagnall <douglas.bagnall@catalyst.net.nz><br>
> *Sent:* Tuesday, May 7, 2024 8:11 PM<br>
> *To:* Interoperability Documentation Help <dochelp@microsoft.com>; <br>
> cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org><br>
> *Subject:* [EXTERNAL] [MS-DTYP] canonical ACL sort order<br>
> hi Dochelp.<br>
> <br>
> I have questions about the definition of the canonical ACL form, to do<br>
> with the status of callback ACEs and the ordering of inherited ACEs.<br>
> <br>
> MS-DTYP 2.4.5 says:<br>
> <br>
> > An ACL is said to be in canonical form if:<br>
> ><br>
> > * All explicit ACEs are placed before inherited ACEs.<br>
> ><br>
> > * Within the explicit ACEs, deny ACEs come before grant ACEs.<br>
> ><br>
> > * Deny ACEs on the object come before deny ACEs on a child or property.<br>
> ><br>
> > * Grant ACEs on the object come before grant ACEs on a child or property.<br>
> ><br>
> > * Inherited ACEs are placed in the order in which they were inherited.<br>
> <br>
> I think the third and fourth clauses are talking about the OBJECT ACE<br>
> types, saying that e.g. ACCESS_ALLOWED_OBJECT_ACE_TYPE comes after<br>
> ACCESS_ALLOWED_ACE_TYPE. But is it also talking about ACEs with the<br>
> INHERIT_ONLY_ACE flag? Or some other mechanism?<br>
> <br>
> Logically it would seem that callback ACEs should be placed is a similar<br>
> position to the OBJECT ones.<br>
> <br>
> Relevantly, MS-ADTS 6.1.3.1 says:<br>
> <br>
> > ACE ordering rules apply only to ACLs in canonical form (see [MS-DTYP]<br>
> > section 2.4.5), and only when the forest functional level is<br>
> > DS_BEHAVIOR_WIN2003 or above. The following rules are applied, in the<br>
> > following order:<br>
> ><br>
> > 1. Explicit ACEs come before inherited ACEs.<br>
> ><br>
> > 2. Deny ACEs come before Allow ACEs.<br>
> ><br>
> > 3. Regular ACEs come before object ACEs.<br>
> ><br>
> > 4. Within each group, the ACEs are ordered lexicographically (that is, based on<br>
> > octet string comparison rules).<br>
> ><br>
> > Rules 3 and 4 above are enforced only when the forest functional level is<br>
> > DS_BEHAVIOR_WIN2003 or above. Otherwise, the order of ACEs within each group<br>
> > defined by rules 1 and 2 is retained as supplied by the user or replication<br>
> > partner.<br>
> <br>
> Point 4 (sorting "lexicographically" via binary comparison), would sort<br>
> the ACE structures primarily by ACE type, followed by flags, followed by<br>
> the type specific members (often the SID is next).<br>
> <br>
> That would put the DENY ACEs in this order:<br>
> <br>
> ACCESS_DENIED_ACE_TYPE (1)<br>
> ACCESS_DENIED_OBJECT_ACE_TYPE (6)<br>
> ACCESS_DENIED_CALLBACK_ACE_TYPE (10)<br>
> ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12)<br>
> <br>
> and similarly for the ALLOW ACEs. But by rule 3, we already have put<br>
> "regular" ACEs before object ACEs, so if callback ACEs count as regular,<br>
> we'd end up with<br>
> <br>
> ACCESS_DENIED_ACE_TYPE (1)<br>
> ACCESS_DENIED_CALLBACK_ACE_TYPE (10)<br>
> ACCESS_DENIED_OBJECT_ACE_TYPE (6)<br>
> ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12)<br>
> <br>
> Are one of these orderings considered to be part of the canonical form?<br>
> <br>
> Either would be consistent with my understanding of MS-DTYP 2.4.5 with<br>
> respect to plain and object ACEs.<br>
> <br>
> (As far as I can tell, the ordering within a block of DENY or ALLOW ACEs<br>
> doesn't matter with respect to the eventual outcome, but putting the<br>
> fancy kinds at the back is likely to be more efficient as it might avoid<br>
> the extra work they entail).<br>
> <br>
> Also I note the MS-DTYP definition says little about the ordering of<br>
> DENY and ALLOW ACEs in the inherited sections. In places where canonical<br>
> ACLs are constructed, such as<br>
> <br>
> <a href="https://learn.microsoft.com/en-us/windows/win32/SecAuthZ/order-of-aces-in-a-dacl">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916067461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IWgz5iswN3yTpruWFGDnmpWxHW8Z1WvlvbPsytt6qSA%3D&reserved=0</a>
<<a href="https://learn.microsoft.com/en-us/windows/win32/SecAuthZ/order-of-aces-in-a-dacl">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916070071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zubTLNAtgNQ%2FBMEeyDmpM%2FdPiZeRQPayy9AuDLnhaEA%3D&reserved=0</a>><br>
> <br>
> > The following steps describe the preferred order:<br>
> ><br>
> > 1. All explicit ACEs are placed in a group before any inherited ACEs.<br>
> ><br>
> > 2. Within the group of explicit ACEs, access-denied ACEs are placed before<br>
> > access-allowed ACEs.<br>
> ><br>
> > 3. Inherited ACEs are placed in the order in which they are inherited. ACEs<br>
> > inherited from the child object's parent come first, then ACEs inherited from<br>
> > the grandparent, and so on up the tree of objects.<br>
> ><br>
> > 4. For each level of inherited ACEs, access-denied ACEs are placed before<br>
> > access-allowed ACEs.<br>
> <br>
> the inherited ACEs are placed in stripes like of DENY and ALLOW ACEs,<br>
> like tree rings. This is not part of the definition in MS-DTYP, which<br>
> only says "inherited ACEs are placed in the order in which they were<br>
> inherited". Should it be part of MS-DTYP 2.4.5?<br>
> <br>
> Of course, when looking at a DACL in isolation, there is no way of<br>
> knowing where the inherited ACEs were inherited from, so the question is<br>
> kind of moot. Maybe that is why MS-DTYP doesn't want to say much, and<br>
> why the MS-ADTS algorithm just flattens the inheritance, potentially<br>
> changing the outcome (by bringing a grandparent DENY in front of a<br>
> parent ALLOW).<br>
> <br>
> I'll note there are a wide range of formulations of canonicity, from<br>
> Microsoft and elsewhere, not all of which can be compatible. For<br>
> example,<br>
> <a href="https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonacl?view=net-8.0">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.security.accesscontrol.commonacl%3Fview%3Dnet-8.0&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916072596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TK4xuTW%2F4H0XIGr6E787Z2MM6qIlpozrjxJQXFtYRPQ%3D&reserved=0</a>
<<a href="https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonacl?view=net-8.0">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.security.accesscontrol.commonacl%3Fview%3Dnet-8.0&data=05%7C02%7Cjeffm%40microsoft.com%7C99ff5d8a279448c74ec808dc74643286%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638513220916075116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LEKn%2B0ajpjEkioxXguykIKteM%2B0en8hiigHCLMiVMpI%3D&reserved=0</a>><br>
> would not sort the ACEs lexicographically, but by SID.<br>
> <br>
> Do SACLs have a canonical ordering, beyond having explicit ACEs first?<br>
> <br>
> cheers,<br>
> Douglas<br>
<br>
</div>
</span></font></div>
</body>
</html>