Обычно мы не используем перемещаемые профили, но нам нужно протестировать некоторый наш код, чтобы убедиться, что мы работаем с этим. Это заставило нас создать перемещаемый профиль, а затем попробовать использовать рассматриваемую программу.
На всех машинах, кроме одной, мы это примерили, все было хорошо. На этой машине произошел сбой продукта. Мы проследили сбои до двух явлений: он не может создать какой-либо COM-объект и не может читать Scripting.Dictionary.
Дальнейшая диагностика выявила ближайшую причину: ограничительный ACL на HKLM защищал HKEY_CLASSES_ROOT от пользователей домена. Он даже не давал доступа на чтение.
Парень, который столкнулся с этим, сделал:
secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose
net localgroup users accountname /add
и все стало лучше.
Я подозревал, что здесь задействована какая-то политика домена, которая должна быть установлена для использования перемещаемых профилей, что заставляет этот ACL по умолчанию устанавливаться более разрешительно. Конечно, это потому, что я предполагал, что для этого ACL было каким-то образом нормально быть настроенным таким образом по умолчанию при добавлении машины в домен.
С другой стороны, администратор клянется, что у нас нет политик, которые могли бы это объяснить. Боюсь, что нас поразил космический луч.
Ваш исходный пост и вопрос, который вы задали Бену Зи-Би, не имеют для меня смысла. Ваше редактирование делает вещи немного более ясными, но я все еще немного не уверен в том, что вы видите (подробнее ниже).
Похоже, вы не знаете, что на самом деле делают перемещаемые профили пользователей.
У каждого пользователя в операционной системе на основе NT есть свой личный куст реестра «HKEY_CURRENT_USER», хранящийся в файле «NTUSER.DAT» в их профиле пользователя (хранящемся либо в «C: \ Users \ username», либо в «C: \ Documents»). и "Настройки \ имя пользователя" по умолчанию и в зависимости от версии Windows). Этот куст реестра присоединяется к HKEY_USERS во время входа в систему и отключается во время выхода из системы. Это поведение одинаково, независимо от локального / ромационного статуса профиля пользователя.
Такое "индивидуальное" поведение "HKEY_CURRENT_USER" позволяет программам сохранять информацию о конфигурации конкретного пользователя в реестре в месте, которое является одинаковым для каждого пользователя (т. Е. Путь реестра не относится к имени учетной записи пользователя), но в то же время позволяет разным пользователям иметь разную информацию о конфигурации, поскольку каждый пользователь получает свою «собственную» версию «HKEY_CURRENT_USER».
«Перемещаемая» часть перемещаемых профилей пользователей исходит из функции загрузки данных профиля пользователя (включая файл «NTUSER.DAT») на сервер после выхода из системы, а также их загрузки и кэширования локально перед входом в систему. Такое поведение загрузки / выгрузки не меняет базового поведения функций реестра отдельных пользователей в Windows. Это просто вспомогательная функция, которая позволяет персональным настройкам пользователя «следовать» за ними с компьютера на компьютер.
Поддерево «HKEY_LOCAL_MACHINE» реестра остается специфичным для машины, независимо от пользователя, который вошел в систему. Списки контроля доступа защищают настройки, хранящиеся в этой области, от модификации непривилегированными пользователями, потому что это расположение информации о конфигурации, зависящей от компьютера. Эти ACL существуют не просто так!
Функциональность, о которой Бен З.Б. упоминает в своем ответе, является распространенным методом, который мы используем для изменения разрешений реестра на (потенциально большом количестве) компьютеров, когда плохо написанное программное обеспечение требует, чтобы непривилегированные пользователи имели менее ограничительные права в «HKEY_LOCAL_MACHINE» и т. Д. Кроме того, функциональность, о которой он говорил, имеет Нет ответвление для перемещаемых профилей пользователей вообще, поскольку перемещаемые профили пользователей связаны с кустами реестра «HKEY_USERS» и «HKEY_CURRENT_USER», ни один из которых не может быть изменен с помощью описываемой им функциональности.
Редактировать:
Я, конечно, не хочу обидеть. Разобравшись с существенный Количество программного обеспечения, разработанного на протяжении многих лет без какого-либо отношения к правильному использованию реестра, я, возможно, немного более защищен, чем мне нужно. Я отредактировал свой ответ, чтобы он был немного менее проповедническим и, надеюсь, более сжатым.
Никаких изменений ACL в корне «HKEY_CLASSES_ROOT» (или «HKEY_LOCAL_MACHINE», если на то пошло) не происходит при присоединении компьютера к домену. В вашем сообщении не описаны конкретные ACE, которые вы видите добавленными в ACL в корне «HKEY_CLASSES_ROOT», поэтому немного сложно говорить о вашей конкретной ситуации.
Любой ACL, относящийся к вашему домену, появляющийся в реестре, почти наверняка указывает на стороннюю модификацию. Microsoft очень, очень хорошо использует известные идентификаторы безопасности и локальные группы в элементах управления доступом, которые они помещают в реестр.
Похоже, что у вас есть объект групповой политики в вашем домене, который вносит изменения (с использованием функций, описанных B-Z, или посредством сценария) в реестр. Использование оснастки консоли управления «Результирующий набор политик» (RSoP), вероятно, будет полезно для проверки того, применяются ли какие-либо сценарии запуска, политика безопасности реестра и т. Д. (Хотя у вас могут быть запущенные сценарии запуска «лазейки», которые выполняются только на первая загрузка после присоединения к домену, которая больше не будет видна в RSoP после этой загрузки).
Вы также можете проверить, что изменение происходит, отключив компьютер от домена, применив шаблон безопасности по умолчанию (как вы указываете в своем комментарии к BZ), затем повторно подключившись к домену, изучив ACL перед перезагрузкой после присоединения к домену, и проверка ACL после повторной перезагрузки. Это сузится, когда произойдет изменение.
Использование перемещаемых профилей пользователей не вносит никаких изменений в конфигурацию машины. Флаг, относящийся к тому, следует ли считать профиль пользователя ромаингом, получается из Active Directory во время входа в систему и кэшируется в индивидуальном подразделе «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList».