Компания
116,64
рейтинг
12 января в 11:11

Разное → Смена SID при клонировании и массовом развёртывании

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:

  1. Что такое SID и каких он бывает типов?
  2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
  3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?

Эти вопросы будут рассмотрены в первую очередь в контексте задачи развёртывания/клонирования множества рабочих станций/серверов из одного мастер-образа в пределах одной компании.



В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

TL;DR
  1. Менять SID машины само по себе бессмысленно и даже вредно для современных ОСей (пример последствий смены SID на Windows 10 ниже).
  2. Для подготовки машины к клонированию/развёртыванию образа стоит использовать sysprep.
  3. SID машины будет иметь значение, только если одну из склонированных машин промоутить до домен контроллера. Так делать не стоит.
  4. Не стоит клонировать/развёртывать образ машины, которая УЖЕ добавлена в домен; добавление в домен нужно делать после клонирования/развертывания.

Что такое SID, его типы и чем отличается Machine SID от Domain SID?


Ликбез
SID (Security Identifier), или Идентификатор безопасности – Это структура данных переменной длины, которая идентифицирует учетную запись пользователя, группы, домена или компьютера (в Windows на базе технологии NT (NT4, 2000, XP, 2003,Vista,7,8)). SID ставится в соответствие с каждой учетной записью в момент её создания. Система оперирует с SID'ами учетных записей, а не их именами. В контроле доступа пользователей к защищаемым объектам (файлам, ключам реестра и т.п.) участвуют также только SID'ы.

В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.

Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:

Machine SID для машины с именем DEMOSYSTEM S-1-5-21-3419697060-3810377854-678604692
DEMOSYSTEM\Administrator S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEM\Guest S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEM\CustomAccount1 S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEM\CustomAccount2 S-1-5-21-3419697060-3810377854-678604692-1001

Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).

На машине вне домена используются локальные SID’ы, описанные выше. Соответственно, при соединении с машиной удалённо используется локальная аутентификация, поэтому даже имея 2 или более машин с одинаковым machine SID в одной сети вне домена, проблем с логином и работой внутри системы не будет, т.к. SID’ы в операциях удалённой аутентификации попросту не используются. Единственный случай, в котором возможны проблемы, это полное совпадение имени пользователя и пароля на двух машинах – тогда, например, RDP между ними может глючить.

Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:

Domain SID для домена BIGDOMAIN S-1-5-21-124525095-708259637-1543119021
BIGDOMAIN\DEMOSYSTEM$ (аккаунт машины (computer account)) S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAIN\JOHNSMITH (аккаунт пользователя (user account)) S-1-5-21-124525095-708259637-1543119021-20937

Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:

• Machine SID, определяющая машину как сущность, в рамках которой заданы группы и аккаунты (первая строчка в первой таблице).

• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).

Увидеть точное значение machine SID можно с помощью утилиты PsGetSid, запустив её без параметров. Второй SID, относящийся к домену, можно увидеть, запустив PsGetSid со следующими параметрами: psgetsid %COMPUTERNAME%$. Соответственно, для примера из таблиц это будет “psgetsid DEMOSYSTEM$".

Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.

Смена SID при клонировании или развёртывании


В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.

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

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

Проблемы, связанные со сменой SID


Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.

Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID'ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.

В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID'а отрабатывала не до конца, что и приводило к трагической гибели практически нерабочей копии Windows 10.

Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.

Использование Sysprep



Начиная с 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'ом, и т.д.

Итого


Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев.


Линки

Как изменить SID в Windows 7 и Windows Server 2008 R2 с помощью sysprep
How to View Full Details of All User Accounts in Windows 10
Миф о дублировании SID компьютера
Sysprep, Machine SIDs and Other Myths
The Machine SID Duplication Myth (and Why Sysprep Matters)
Yes you do need to worry about SIDs when you clone virtual machines – reasserting the ‘myth’
Why Sysprep is a necessary Windows deployment tool

Спасибо за внимание!
Автор: @chineek
Acronis
рейтинг 116,64

Комментарии (20)

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

    Кроме того, был возможен следующий сценарий для рабочих групп — две машины с одинаковым SID, локальные администраторы с разными паролями. Локальный администратор каждой машины может открывать административные сетевые ресурсы другой машины.

    Так же можно вспомнить, что у VMware есть утилита quickprep для «генерализации» виртуальной машины без смены локального SID. Используется с linked clone. Для большинства сценариев вполне работоспособна.

    Проблемы с WSUS мне не встречались, есть старая статья support.microsoft.com/en-us/kb/903262, в которой говорится что проблемы с WSUS связаны не с SID, а процессом генерализации.
  • 0
    Коротко и ясно.
    Пара вопросов, если можно:
    1. Добавление к рабочей группе будет сопроваждаться добавлением машине «Domain SID»? И если да, то где он будет храниться, только на самой машине?
    2. В чем разница между рабочей группой и домашней группой, в контексте «Domain SID»?
    Спасибо.
    • 0
      Спасибо за отзыв.
      1. Нет — domain SID свойство исключительно домена (это идентификатор аккаунта компьютера в рамках домена), поэтому добавление в рабочую группу на него не влияет. Логин на любой компьютер в рабочей группе осуществляется исключительно локальными аккаунтами.
      2. Как следует из п.1, разницы никакой нет в данном контексте.
  • 0
    Вспоминая свое далекое доадминское прошлое. И о том как делать не нужно :).

    Удаленный офис. Рабочая машина с переустановленной «с нуля» виндой. Создается локальный аккаунт с административными правами, с аналогичным доменному логином и паролем. Далее путем нехитрой социальной инженерии компьютер загоняется в домен. И вуаля. Недавний студент, ничего не понимающий в MS AD, процессе аутентификации и прочих страшных словах, имеет одновременно нормальный доступ ко всем доменным ресурсам и полноценный локальный админский аккаунт на своем рабочем ПК.

    Что говорит о том, что по крайне мере в Win Server 2000 в AD с sid-ами все было не так уж и уникально :).
    • 0
      Если в наличии имелся аккаунт с «аналогичным доменному логином и паролем», то в чем цимес социальной инженерии для загона машины в домен? :)
      • 0
        В том что доменный аккаунт был аккаунтом доменного пользователя. А не админа домена. А из под пользователя машину в домен не загонишь.
        • 0
          А! Изначально прочитал, что локальный админский аккаунт создается с логином паролем аналогичным аккаунту домен админа, а не простого доменного пользователя. Спасибо за пояснение — тогда действительно красивый лайфхак получился!
          • +2
            Я немного врежусь в тред.

            При дефолтных настройках контроллера домена на котором, расшарена папка с правами Everyone можно:

            С ПК, находящегося в рабочей группе, на котором локальный пользователь (не важно админ или нет) имеет такой же логин и пароль как и у доменного пользователя (тобишь не имеющего административных прав в домене) — можно заходить на расшаренную папку на КД без ввода каких либо паролей.

            ПК можно ввести в домен с правами обычного доменного пользователя, но требуется что бы были права локального админа на ПК. И совершить сиё действо можно не более 10 раз для доменного аккаунта без административных прав.

            зыю
            Я полагал ранее, что должна существовать учетная запись ПК в AD, и только тогда можно будет ввести ПК в домен под пользовательской учеткой, но токачто сделанное тестирование ради фана, показало, что учетная запись ПК созданная заранее не обязательна.

            Server 2012 R2 + Win7 Pro
        • +1
          Дефолтные настройки домена AD — авторизованный пользователь может добавить до 10 компьютеров и без наличия админских привилегий.
          Поддерживаю предыдущего оратора — где именно тут «социальная инжинерия»?
        • 0
          1. загонишь до 10 раз. на момент 2003 и насколько помню и далее.
          2. такие фишки устраняются легко политикой сброса локальных админов и установкой своих, и после перезагрузки вы идете опять устанавливать винду и применять социалку. на 3-4 итерации вас «погладят по головке». Хотите иметь админ доступ к тачке — лично у меня такое правило — хотите, получите, но мне не звоните по вопросам «че то у меня не работает ....». Покупаете тортик/пиво/одеваете платье с глубоким вырезом (последнее только если вы очаровательная девушка) и идете социалить к админу.
          • 0
            как быстро откомментили, опять же 1 пункт легко устраняется групповыми политиками, ибо зоопарк надоедает через полгода
            • 0
              Пункт 1 работает на самом деле начиная с Win Server 2000. Но исходя из того что из под «обычного доменного пользователя» PC в домен не добавлялся, админы организации были не совсем «просты» :). И по всей видимости параметр ms-DS-MachineAccountQuota скорректирован :).

              Удивляет то, что суть коммента была про «неправильное» получение прав локального админа на своем PC обычным пользователем AD, но всех комментирующих задело за больное всего одна фраза, имеющая косвенное отношение к делу.

              Да и описываемые события происходили 1,5 десятка лет назад как минимум.
  • 0
    Из собственного опыта уяснил, что ни sysprep, ни смена SID утилитой от Марка (про которую он в итоге сам написал, что операция смена SIDа бессмысленна) не нужны, тем более sysprep занимает очень и очень много времени, а ошибиться в unattended проще простого. В момент заведения машины в домен ей присваивается доменный SID и у неё должно быть только уникальное сетевое имя до 15 символов. Поэтому образы разливаю неподготовленные sysprep`ом, где в автозагрузке лежит PoSH скрипт, который генерирует сетевое имя на основе данных IP+дата+MAC и вводит в домен. Машины входят в домен десятками за раз и никаких проблем. А WSUSID генерируется заново путём удаления пары ключей из реестра и перезапуском службы.
    • +1
      Кстати, если у Лады приварить колёса, вместо того что бы завернуть болты, она тоже поедет.
      • 0
        Ваше предложение?
        • 0
          Один раз настроить MDT.
          • 0
            Спасибо, не надо. Работа с wim образами то ещё удовольствие, особенно когда нужно часто вносить изменения и тестировать их на живой машине. Тем более в этой статье описывается работа аналога WDS от акрониса.
            • 0
              WIM там трогать не приходится. К примеру, обновления обычно интегрируют через Sysprep and Capture, который легко заскриптовать.
              • 0
                Да уметь то он всё умеет (и через PoSH можно всеми службами управлять), но чтобы закэпчурить/задеплоить образ нужно отдавать всем клиентам по сети WinPE образ на 150-300МБ, даже по гигабитной сети 50 клиентов будут качать его несколько минут + время отработки sysprep по окончанию = много времени. Тот же клиент Ghost, который так же легко заскриптовать и на который ссылается материал по вашей ссылке, весит в 100 раз меньше и всё тоже самое можно сделать на нём, сэкономив кучу времени. Я пытался перейти на WDS/MDT ожидая получить ещё более быстрое время готовности клиентов (особенно когда ставят задачу сделать всё за пол часа), но увы, не все продукты Microsoft одинаково полезны для администрирования её же сети.
  • +1
    Не стоит клонировать/развёртывать образ машины, которая УЖЕ добавлена в домен

    Зависит от ПО. В VMware View у вас не будет работать создавание клонов (Full и Linked), если шаблон не был добавлен в домен перед этим.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное