В моем журнале событий поврежден DACL «Атрибуты записи» в 4656 событиях аудита файлов.
Я написал сценарий процедуры в PowerShell для получения журналов событий безопасности с моего сервера Windows 2012r2. Изучая ошибку в моей процедуре синтаксического анализа события в xml, я обнаружил очень странную проблему в свойстве «Причины доступа» события 4656:
%% 4423: %% 1801 D: (A; ID; FA ;; ; это все, что у меня есть на данный момент.
Так что, по-видимому, я обнаружил жучок "IsTextUnicode"/"Bush Hid The Facts", который существовал в окнах с момента моего рождения... Язык SDDL, определяющий ACE, является null terminated string. Способ, которым нули обрабатываются в различных кодировках, заставляет функцию ConvertSecurityDescriptorToStringSecurityDescriptor делать эту фанковую магию. Обратите внимание, что функция IsTextUnicode и функция ConvertSecurityDescriptorToStringSecurityDescriptor используют одну и ту же библиотеку: Advapi32.
Вышеизложенное предполагает, что запись повреждается во время аудиторской записи. Я также предполагаю, что это не ошибка в функции AuthzReportSecurityEvent, которая разбирает выходы вышеуказанных функций. Вся документация, которую я прочитал в MSDN, относится к перечислениям, структурам и функциям сервера 2003. Поэтому все эти функции и структуры могут отличаться от того, что я читал в MSDN.
Этот вопрос также может быть во время чтения логов; речь идет о функциях ReadEventLog (Также разделяет Advapi32) и FormatMessage.
Уверен, что свойство "Причины доступа" было добавлено в структуру аудита файлов в 2012 году в рамках "динамического контроля доступа". Вот оно. Любая из вышеперечисленных функциональных проблем может относиться к теперь увеличенному размеру сообщения о событии.
https://en.wikipedia.org/wiki/Bush_hid_the_facts https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656
EDIT: Microsoft утверждает, что исправила эту ошибку в vista, но, как вы можете видеть, здесь возникает проблема преобразования юникода. Ошибка та же самая. Раскрою, что функция IsTextUnicode - это статистический анализ передаваемой в функцию строки. И хотя она никогда не будет идеальной, эта проблема связана с завершением строки, содержащейся в подразделе сообщения о событии. Каждая секция сообщения о событии также содержит байт-терминатор, поэтому я предполагаю, что два завершающих байта вызывают проблему разбора в логике функции преобразования unicode/ansi, как при чтении, так и при записи.