Вопросы Теги

Назначение определенного SID машины новой системе Windows

Программа установки Windows назначает уникальный идентификатор машины системе Windows во время установки. Идентификатор безопасности компьютера не отображается в сети, и поэтому обычно не имеет значения, что это такое, но идентификаторы безопасности локальных пользователей основаны на идентификаторе безопасности компьютера, и это может создать проблемы при совместном использовании профилей пользователей и созданных пользователями файлов на Тома NTFS. Даже если файлы и папки имеют списки управления доступом только с предопределенными, не зависящими от компьютера идентификаторами безопасности, такими как встроенная группа администраторов, их владельцем является создавающий локальный пользователь, идентифицируемый с помощью идентификатора безопасности компьютера и идентификатора пользователя RID. Этот сценарий подходит, например, если вы хотите создать сценарий своей системы разработки со свежего установочного носителя Windows, как если бы это был контейнер Linux. В этом случае вы хотите, чтобы каждая создаваемая вами система Windows имела один и тот же SID машины.

Однако утилита SysInternals NewSID была устаревшей и удалена еще в 2009 году, а не работает должным образом в современных версиях Windows. Есть ли способ достичь того же результата с помощью обычных инструментов развертывания Windows? Марк Руссинович намекнул в своем посте, осуждающем NewSID, что это может иметь место, но если это так, то эта возможность не задокументирована.Конечно, в этом нет ничего удивительного: у Microsoft долгая история недокументированных функций, восходящая к временам MS-DOS.

0
задан 23 July 2021 в 10:22
1 ответ

Недокументированная утилита SetupCl.exe , которая является частью инструментария установки Windows и очищает образ системы как один из этапов процесса обобщения, который запускается при загрузке новой системы Windows, обычно выполняет такие действия. при генерации новых идентификаторов дисков исправьте точки повторной обработки и замените ссылки на системный корень по умолчанию (обычно X: \ ) на то, что подходит для вашей целевой системы (обычно C: \ ) во всех разделах реестра и, возможно, файлах конфигурации. Эта утилита вызывается процессом установки Windows при первой загрузке и управляется разделом реестра SYSTEM \ Setup \ SetupCl \ PendingRequest . Значение DWORD OperationFlags в этом ключе является битовым полем, которое указывает, какие преобразования будет выполнять утилита.

В дополнение к упомянутым выше преобразованиям, SetupCl может заменить существующий компьютерный SID новым. Это преобразование запрашивается установкой бита 2 ( 0x4 ) в OperationFlags в ключе SYSTEM \ Setup \ SetupCl \ PendingRequest . Два необязательных двоичных значения SidAccountDomainOld и SidAccountDomainNew в одном и том же ключе предоставляют идентификаторы безопасности исходного и целевого компьютера. Если SID источника опущен, SetupCl берет его из работающей системы. Если целевой SID опущен, SetupCl генерирует новый.Эти значения содержат идентификатор SID машины в двоичной форме и имеют длину 24 байта (8-байтовый заголовок фиксированной длины и 4 32-битных вспомогательных полномочия). Чтобы заставить SetupCl назначить конкретный SID машины, установите бит 2 в OperationFlags и создайте значение SidAccountDomainNew , содержащее SID.

Эта процедура связана с несколькими сложностями:

  1. Она работает с образами, подготовленными с помощью sysprep / generalize , но не работает с образами Windows, только что развернутыми с помощью DISM или Expand-WindowsImage ] командлет. Свежие образы также находятся в обобщенном состоянии с ожидающим запросом SetupCl , настроенным в кусте SYSTEM для запуска при первой загрузке, но для этого запроса не установлен бит 2. Установка его в автономном образе приводит к тому, что образ не может быть развернут. Чтобы обойти это ограничение, нужно выполнить дополнительный раунд обобщения / специализации. Один из способов сделать это - использовать связанные файлы автоматической установки: в первом файле автоматической установки указывается одна команда Microsoft-Windows-Setup-Shell / FirstLogonCommands для выполнения sysprep / generalize / oobe / unattend: <второй unattend файл> / выключение .

  2. Добавление значения SidAccountDomainNew в Интернете до или после sysprep / generalize не работает, скорее всего потому, что sysprep планирует выполнение некоторых заключительных шагов на выключение системы.Подключите автономный образ Windows после завершения sysprep / generalize и выключения системы, загрузите куст SYSTEM и добавьте его в этот момент.

  3. sysprep / generalize не работает, если есть ожидающая перезагрузка из-за установки программного обеспечения. Перезагрузите систему перед обобщением или выполните дополнительный этап обобщения / специализации перед установкой программного обеспечения в образ.

1
ответ дан 28 July 2021 в 14:06

Теги

Похожие вопросы