NT Authority \ System & SDDL Error

Question

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

Они используют SCCM (я не знаю версию), а программный пакет - пакет InstallShield .exe .msi.

При попытке использовать пользователя NT Authority \ System для установки пакета на свое тестовое устройство установка завершается сбоем вскоре после завершения прилагаемого программного пакета стороннего производителя. Журнал ошибок показывает, что это ошибка SDDL 1943. Любая идея, почему это произойдет в учетной записи NTA \ System, а не в локальной учетной записи администратора для данной машины?

Молчаливый установить строку, мы используем это setup.exe/s/v «/ дп AgreeToLicense = Да SETUPTYPE = Типичный»

Я не DEV, так что я не имею прямой доступ к любому коду в программное обеспечение, просто техническая поддержка уровня 3, работающая с клиентами.

Answer 1

Похоже, что ваш MSI использует таблицу MsiLockPermissionsEx, чтобы указать строку SDDL на каком-либо ресурсе, устанавливая или настраивая (файл, каталог, службу или запись в реестре). Либо строка SDDL неправильно сконфигурирована (маловероятно, если она работает с одной учетной записью, но не с другой), либо ACL в целевом каталоге/службе/разделе реестра поврежден, что не совсем неслыханно.

Вы можете попытаться заставить клиента развернуть учетную запись домена в качестве локального администратора на компьютерах, а затем установить SCCM для запуска пакета с этой учетной записью. Я бы не рекомендовал этого, хотя он несет в себе собственные риски безопасности.

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

Извините, но я не могу помочь.

Answer 2

Я думаю, что нашел проблему. Во время установки .msi записывает файл на рабочий стол для чтения для параметров конфигурации для службы, которая устанавливается. У меня был файл (и я уверен, что клиент сделал тоже), уже написанный на рабочем столе, когда я пытался вызвать System User для установки. Это похоже на проблему с ACL в отношении чтения/записи системного пользователя на локальный пользовательский рабочий стол. Когда файл был удален, я получил ошибку 1406, чтобы он не мог записать значение ключа. Глядя на рабочий стол, файл также никогда не записывался на локальный рабочий стол. Когда файл уже был там (как таковой с предыдущей установкой), я получаю ошибку в исходном сообщении. На этом этапе я продвигаюсь вперед, проверяя это как ошибку ACL и уведомляя разработчиков о моих выводах.