<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: 12pt; color: rgb(0, 0, 0);">
Dochelp in Bcc</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hello Douglas, thank you for your questions about Microsoft Open Specifications. Since you have multiple questions here, we will create sperate incidents for each of them to track the investigations. Please stand by while we work on it. You'll receive separate
e-mails with incident numbers.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Regards,</span></p>
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Sreekanth Nadendla</span></p>
<p style="margin-top: 0px; margin-bottom: 0px;"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; font-size: 15px; color: black;">Microsoft Windows Open
Specifications</span></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 7, 2024 8:11 PM<br>
<b>To:</b> Interoperability Documentation Help <dochelp@microsoft.com>; cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org><br>
<b>Subject:</b> [EXTERNAL] [MS-DTYP] canonical ACL sort order</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">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%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378695121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CBrpNXxW1LpEgR2JCm5L6R0YLhld1DYAkYC8dFX43LE%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%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378701549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pfebzEmURR5OTZQD%2B1JkZVW1KzYXj%2BmJO%2BVe%2Fvt3Rzc%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>
</div>
</span></font></div>
</body>
</html>