О! Очередная ахинея! Вы просто каталогами пользоваться не умели, что в 2000 году, что сейчас, раз такое пишете.

SID - это идентификатор субъекта. Он состоит из блоков, которые хорошо известны:
S-(version 1)-(base authority)-(sub aiuthority-1)-...-(sub aiuthority-N)-(RID)
RID - это относительный идентификатор, часть из которых, что называется, well-known и они есть не у всех субъектов.
base authority у обычных пользователей 5 (NT Authority), но есть и другие.
Например:
S-1-5-18 - это SYSTEM, то же самое что и root.
S-1-5-21-ХХХХХ-ХХХХХ - доменные пользователи и группы.
Их там много, есть документация. https://learn.microsoft.com/en-us/openspecs/windows_protocol...
Эта нотация нужна чтобы максимально избежать коллизий в именовании субъектов, локализовав их в sub-authority. При этом есть выделенные base authority для тех задач, когда разработчику нужно чтобы SID специально были не уникальны.

Вы понимаете, что это просто идентификатор пользователя?! RID - это числовой идентификатор пользователя, это то же самое, что UID и GID. SID выполняет ту же самую функцию.

> ACL такая классная вещь, которую можно сломать такой простой операцией, как удаление объекта в системе авторизации, которому присвоен определенный SID для файла

Ну то есть если вы ввели Linux в домен, например в ту же FreeIPA и выдали UNIX Permissions для пользователя с определенным идентификатором, или создали локального пользователя и выдали права ему. А потом их удалили, то что у вас будет на ФС? А?! Правильно! UID и GID там будет торчать от старого пользователя. И когда там старый SID остался торчать в Windows, то это чем отличается от от торчащих UID и GID, я стесняюсь спросить?

В чем собственно проблема? Ну не принято удалять пользователей в каталогах, если в других частях инфраструктуры есть ссылки на них. Принято их выключать или вычищать за ними. Ты еще поди из тех кто удалял пользователей и пытался создать с тем же именем...

А альтернатива какая? Запускать всё под тонной локальных пользователей? Ну на твоём локалхосте это работает, на то он и локалхост.

> Конфликтные ACL никак не фиксятся.

Вот тебе каноничный алгоритм:
1. Применить все явные Deny записи в ACL
2. Применить все явные Allow записи в ACL
3. Применить все унаследованные Deny записи в ACL
4. Применить все унаследованные Allow записи в ACL
У тебя лапки, просто. Во-первых если уж ты так ненавидишь ACL, то зачем тебе Deny-правила. Тебе же с UNIX Permissions всё будет хорошо. Во-вторых, наследование всегда имеет низкий приоритет.
- Если ты унаследовал записи от вышестоящего каталога, они всегда пойдут во вторую очередь
- Windows Explorer создаёт временные (volatile) записи в ACL, если пользователь с правами администратора лазит по каталогам, в которых ему быть нельзя, но нажимает кнопочку со щитком "Продолжить" в GUI.
В изначальном каталоге эти временные записи будут явными, а в дочерних, если для объекта включено наследование всех прав, станут унаследованными.
Твоя временность и конфликты все от неграмотности и не умения читать документацию.

> наличие "broadcast SID", которые всегда валидны для любого объекта. Поэтому помимо SID для доступа к службе всегда нужно подключаться через третью службу, которая всегда будет проверять, а не подменил ли ты себе SID.

Вся эта инфраструктура рассчитана на применение Kerberos. KDC должен выдать билет, который ты там будешь предъявлять. Если тебе нужно аутентифицироваться НА службе, тебе нужен TGS, SPN и делегирование. Опять же, Kerberos 5 он не только в Windows так работает. Он везде такой, там всегда есть третья проверяющая сторона.

Объясни членораздельно, что ты собрался проверять и что ты имеешь в виду под "broadcast SID"? Ты имеешь в виду какие-то well-known учетные записи вроде NT AUTHORITY\NETWORK SERVICE, которые могут указывать на разные учетные записи в каталоге. Или ты говоришь про виртуальные SID в стиле NT SERVICE\myservicename
Опять же, не вижу связи конкретно с ACL. Применение виртуальных аккаунтов как раз наоборот помогает абстрагироваться от доменных и локальных пользователей при работе с локальной файловой системой. В чем тут дыра?