Несоответствие NTFS ACL в PowerShell

У меня есть случай, когда у пользователя когда-то был доступ к каталогу, а теперь этот пользователь был удален. Фактически их учетная запись была полностью удалена из AD.

Обычно, когда кто-то видит, что пользователь удален, но имеет явный ACL, определенный для каталога, тогда его SID будет оставлен позади, отмечая, что ACL существует, и больше не имеет ссылки на все другие атрибуты AD, такие как имя и т. Д. осиротевшая запись ACL, оставленная там, я предполагаю, преднамеренно на случай, если вам потребуется восстановить пользователя.

Однако у меня есть случай чего-то другого, если я смотрю на вкладку свойств / безопасности каталога, ни соответствующий пользователь, ни SID пользователя не присутствуют.

Однако, если я проверю свойство доступа объекта, возвращаемого CMDLET Get-ACL, я получаю другой результат.

Если я выполню команду на файловый сервер, я действительно получаю DOMAIN \ username с явным разрешением

Если я запускаю ту же самую команду в том же каталоге с другого сервера (например, контроллера домена), я получаю список samne, но во всех других экземплярах, кроме локальных, пользователь отображается как SID. Поэтому я должен предположить, что на файловом сервере просто куда-то кэширован его SID для UN, это составляет который отклонение, однако не учитывает тот факт, что на вкладке безопасности не отображаются те же записи разрешений.

Еще хуже, если я углублюсь на несколько уровней глубже и проверю подобъекты этого каталога с помощью powershell, я вижу те же результаты, это разрешение определено, но только в PowerShell, окна по-прежнему ничего не показывают.

Итак, я пошел на третье мнение и использовал accessenum из sysinternals, он НЕ показывает посторонний ACL, однако CALCS показывает! так что теперь мы вернулись к соотношению 1: 1: есть / нет параметр без каких-либо доказательств, подтверждающих действительность того и другого.

Каталог находится непосредственно в корне диска, ни один из методов PowerShell, CACLS и т. Д. Не показывает это разрешение, определенное на самом диске, и у меня нет причин подозревать, что это было в прошлом.

Я не решаюсь попытаться сделать что-то вроде удаления ACL с помощью PowerShell или CACLS, не понимая, что здесь происходит. Точно так же типичное принудительное право владения / наследования вниз по дереву каталогов, удаление всех разрешений и переопределение будет огромным мероприятием, потому что ПОД этим каталогом находится большая файловая структура, списки ACL которой разветвляются во многих местах.

Чтобы убедиться, что я не имею дела с повреждением диска или недействительными данными, я выполнил CHKDSK на рассматриваемом диске, который не сообщил об ошибке.

Я думаю, это либо ошибка, либо где-то повреждение, но не знаю, где искать дальше, может быть, шестнадцатеричный редактор на самом диске?

Итак, нашел ли я какую-то ошибку, ошибку или просто упустил из виду что-то явно очевидное?