САМОВАРчик

ktokto 02.10.2012, 01:47:54 #1

Ссылки:
Что в SID-е тебе моем?!

...весьма важно, чтобы изменение SID-а компьютера утилитами SysPrep или NewSID происходило как можно ближе к моменту инсталляции системы (пока не сделано много особенных прав доступа, не заведено много пользователей и т.п.). Это связано с тем, что при установке на компьютер какого-то дополнительного ПО могут появиться ресурсы илли другие объекты безопасности, о существовании которых не подозревает ваша версия NewSID или SysPrep. И при смене SIDа ACL на этих объектах безопасности не будут обновлены, как следствие будут нарушены права доступа и работоспособность дополнительного ПО может быть потеряна.

Как поменять SID и имя клонированной виртуальной машины

На самом деле менять SID не обязательно:
Миф о дублировании SID компьютера

...Дублирование SID
Пропагандируемый Microsoft способ создания установки Windows, пригодный для развертывания системы на группы компьютеров, заключается в установке Windows на эталонный компьютер и подготовке системы к клонированию с помощью утилиты Sysprep. Этот метод называется "обобщением образа", поскольку при его загрузке Sysprep персонализирует установку, генерируя новый SID компьютера, определяя имеющиеся аппаратные средства, сбрасывая счетчик активации и устанавливая прочие настройки, в том числе – имя компьютера.

Однако, некоторые IT-администраторы сначала ставят Windows на одну из своих систем, устанавливают и настраивают приложения, а затем используют такие средства развертывания, которые не сбрасывают SID на установочных образах Windows. До сих пор наилучшим средством в таких ситуациях было использование утилит для смены SID, таких как NewSID. Эти утилиты генерируют новый идентификатор безопасности машины, а затем пытаются обновить его во всех мыслимых местах, включая файловую систему и списки управления доступом в реестре. Причина, по которой Microsoft не поддерживает подобный способ изменения системы, довольно проста – в отличие от Sysprep, сторонние утилиты могут и не знать обо всех тех местах, где Windows хранит идентификатор безопасности компьютера. А раз так, то и надежность компьютера, на котором имеется и старый и новый SID, не может быть гарантирована.

Так что же, можно считать проблемой наличие нескольких машин с одинаковыми SID? Только в одном случае - если Windows при каких-либо обстоятельствах ссылается на SID других компьютеров. К примеру, если во время подключения к удаленной системе SID локального компьютера был передан на одну из удаленных систем и использовался там для проверки прав доступа, тогда дублированный идентификатор SID мог бы стать причиной наличия бреши в системе безопасности, поскольку удаленная машина не смогла бы отличить SID удаленной учетной записи от аналогичного SID локальной учетной записи (при условии, что в идентификаторах совпадают и SID компьютера, и RID). Однако как мы отмечали, Windows не позволяет пройти аутентификацию на удаленном компьютере, используя учетную запись, известную только локальному компьютеру. Вместо этого необходимо указать либо входные параметры, являющиеся локальными для удаленной системы, либо параметры учетной записи домена, считающегося доверенным для удаленной системы. Удаленный компьютер получает SID для локальной учетной записи в своей собственной базе данных учетных записей (SAM), а сведения об аккаунте домена об берет в базе Active Directory на контроллере домена. Удаленный компьютер никогда не предоставляет SID компьютера подключающейся машине.

Другими словами, не SID предоставляет доступ к компьютеру, а имя пользователя и пароль учетной записи: одно лишь знание SID учетной записи на удаленной машине не позволит получить доступ к компьютеру или его ресурсам. Чтобы еще раз убедиться в этом, достаточно вспомнить тот факт, что встроенные учетные записи (например, Local System) имеют одинаковые SID на любом компьютере, что могло бы стать серьезной уязвимостью, если бы доступ основывался на SID.

Как я уже сказал ранее, из этого правила есть одно исключение, и это исключение – сами контроллеры домена. У каждого домена есть уникальный SID домена, генерируемый случайным образом при установке домена, и все SID компьютеров, входящих в состав домена, совпадают с SID домена. Поэтому в определенном смысле эту ситуацию можно рассматривать, как использование идентификатора SID другими компьютерами. Это означает, что компьютеры, являющиеся частью домена, не могут иметь те же самые SID компьютера, что и контроллер домена. Однако, как и эти компьютеры, каждый контроллер домена имеет учетную запись компьютера в домене, по которой и осуществляется их идентификация при авторизации на удаленной системе.

В целом ряде статей, посвященных дублированию SID, включая эту статью из базы знаний Microsoft, содержится предупреждение, что наличие у нескольких компьютеров одинаковых SID приводит к тому, что ресурсы на сменных носителях (например, на отформатированных в NTFS внешних дисках) не могут быть защищены средствами локальной учетной записи. Однако в них упускается из виду то обстоятельство, что права доступа на таких накопителях защитить не получится в любом случае, поскольку подсоединить их можно к такой машине, которой безразличны права доступа NTFS. Более того, сменные накопители чаще всего используют права доступа по умолчанию, позволяющие осуществлять доступ хорошо известным идентификаторам SID (группы "Администраторы", к примеру), одинаковым на любой системе. Это фундаментальное правило физической защиты, поэтому в Windows 7 включена функция Bitlocker-to-Go, позволяющая зашифровывать данные на сменных носителях.

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

Новая лучшая политика
Удивительно, что дублирование SID так долго считалось не подлежащей обсуждению проблемой лишь потому, что все думали, что кому-то об этом точно известно. К моему сожалению, на самом деле NewSID никогда не была по-настоящему полезной утилитой, и скучать по ней теперь нет никакого смысла. Официальная политика Microsoft по данному вопросу тоже изменится, поэтому можно рассчитывать на то, что в будущих версиях Sysprep этап генерации SID будет пропущен...

оригинал статьи: http://blogs.technet.com/b/markrussinov … 91024.aspx

и скачать то теперь NewSID нельзя: http://technet.microsoft.com/en-us/sysi … 97418.aspx и http://technet.microsoft.com/ru-ru/sysi … 97418.aspx

Хотя народ всё равно меняет SID'ы (и в Windows7): http://forum.oszone.net/nextnewesttothread-162781.html и http://www.brajkovic.info/windows-serve … g-sysprep/

ktokto 03.12.2012, 01:22:13 #2

ещё одна утилита для смены SID: http://www.stratesave.com/html/sidchg.html
платная.

ktokto 14.05.2016, 10:34:45 #3

обобщающая, полезная статья: https://habrahabr.ru/company/acronis/blog/273793/

ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.

нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.

Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID'а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

Удаляется имя машины
Машина выводится из домена: это нужно для последующего успешного добавления в домен с новым именем
Удаляются plug-and-play драйвера, что уменьшает риск возникновения проблем с совместимостью на новом «железе»
Опционально удаляются Windows Event Logs (параметр 'reseal')
Удаляются точки восстановления
Удаляется профиль локального администратора и этот аккаунт отключается
Обеспечивается загрузка целевой машины в режим аудита, позволяющий устанавливать дополнительные приложения и драйверы
Обеспечивается запуск mini-setup при первом запуске для смены имени машины и другой дополнительной конфигурации
Сбрасывается период активации Windows (сброс возможен до 3 раз)

Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep'ом, и т.д.

нельзя клонировать машины для развертывания на них Exchange Server без sysprep со сменой SID. Сталкивались, проблемы, не делайте так.

Добавление к рабочей группе будет сопровождаться добавлением машине «Domain SID»? И если да, то где он будет храниться, только на самой машине?

Нет — domain SID свойство исключительно домена (это идентификатор аккаунта компьютера в рамках домена), поэтому добавление в рабочую группу на него не влияет. Логин на любой компьютер в рабочей группе осуществляется исключительно локальными аккаунтами.

ни sysprep, ни смена SID утилитой от Марка (про которую он в итоге сам написал, что операция смена SIDа бессмысленна) не нужны, тем более sysprep занимает очень и очень много времени, а ошибиться в unattended проще простого. В момент заведения машины в домен ей присваивается доменный SID и у неё должно быть только уникальное сетевое имя до 15 символов. Поэтому образы разливаю неподготовленные sysprep`ом, где в автозагрузке лежит PoSH скрипт, который генерирует сетевое имя на основе данных IP+дата+MAC и вводит в домен. Машины входят в домен десятками за раз и никаких проблем. А WSUSID генерируется заново путём удаления пары ключей из реестра и перезапуском службы.

Вывод: если не будет домена не надо использовать NewSID (и аналогичные утилиты), если быдет домен - тоже не надо, используйте sysprep.

Имена ПК не длиннее 15 символов, ага.

Утилиту PsGetSid иметь всё равно полезно, чтобы смотреть SID'ы.