Как сбросить sid windows 10 при клонировании диска

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

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

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

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

Что такое SID, его типы и чем отличается Machine SID от Domain 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
DEMOSYSTEMAdministrator	S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEMGuest	S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEMCustomAccount1	S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEMCustomAccount2	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
BIGDOMAINDEMOSYSTEM$ (аккаунт машины (computer account))	S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAINJOHNSMITH (аккаунт пользователя (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

Спасибо за внимание!

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

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

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

Что такое SID, его типы и чем отличается Machine SID от Domain 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
DEMOSYSTEMAdministrator	S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEMGuest	S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEMCustomAccount1	S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEMCustomAccount2	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
BIGDOMAINDEMOSYSTEM$ (аккаунт машины (computer account))	S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAINJOHNSMITH (аккаунт пользователя (user account))	S-1-5-21-124525095-708259637-1543119021-20937

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

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

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

Основная суть в том, что 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 их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

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

Итого

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

Источник

Как сбросить SID у системы Windows

Что важно если система (Windows) было клонирована средствами Virtualbox. При попытке ввода в домен Вы можете получить сообщение вида:

« The domain join cannot be completed because the SID of the domain you attempted to join was identical to the SID of this machine. This is a symptom of an improperly cloned operating system install. You should run sysprep on this machine in order to generate a new machine SID »

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

На Windows Server 2012 R2 — Win + X → Command Prompt (Admin)

C:Windowssystem32>cd Sysprep

C:WindowsSystem32Sysprep>sysprep /oobe /generalize /shutdown

[stextbox style=»color: #ff00ff;»>На заметку: На других линейках операционной системы Windows все тоже самое, главное запустить консоль командной строки с правами Администратора.[/stextbox]

После исполнения данной команды система выключиться, потребуется ее включить и необходимо будет указать текущую страну или регион (« Country or region »), используемый язык (« App language »), раскладку клавиатуры (« Keyboard layout »), согласиться с лицензионный соглашение, задать пароль на учетную запись Администратора, система после уйдет в перезагрузку, а когда загрузиться то будет полностью обнуленной, как будто Вы ее только что поставили (USB Flash Drive, DVD/CD ROM) из образа (и не будет клонированной). Я делаю после этого (я решил задокумментировать все это столкнувшись в очередной раз на Windows Server 2012 R2 Standard, а потому и действия сочетаний клавиш привожу относительно ей):

Win + X → Command Prompt (Admin)

C:Windowssystem32>net user Administrator | findstr /C:expires

Account expires Never

Password expires 11/6/2018 8:42:46 PM

C:Windowssystem32>wmic useraccount where name=’Administrator’ set passwordexpires=FALSE

Updating property(s) of ‘\WIN-ENBQ1C4A7CMROOTCIMV2:Win32_UserAccount.Domain=»WIN-ENBQ1C4A7CM»,Name=»Administrator»‘

C:Windowssystem32>net user Administrator | findstr /C:expires

Account expires Never

Password expires Never

Property(s) update successful.

А раз так, то и использовать ее можно хоть в домене, хоть где либо еще.

Не стоит об этом забывать и тратить драгоценное время если моделируете различные ситуации под Virtualbox, ESXi перед тем как все сделать на боевом окружении.

Итого заметка работоспособна, на этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Источник

Сбросить sid windows 10

Sysprep — Утилита системной подготовки Microsoft Windows к развертыванию. Sysprep первоначально был представлен для использования с Windows NT 4.0

Примечание: Изменение SID вашего железа может помочь вам продолжать использовать программы, которые требуют ввода лицензионного ключа. Чтобы не тратить время на поиски ключа в интернете, просто смените SID и пользуйтесь платной программой ещё 30 или более дней.

Ранее для изменения SID применялась утилита NewSID, однако сейчас ее использование не поддерживается Microsoft, кроме того, использовать ее в новых ОС, типа Windows Server 2008 R2, просто опасно. Поэтому для изменения SID вашего ПК лучше всего использовать sysprep, использовать эту утилиту достаточно просто, и далее я опишу всю последовательность шагов.

Чтобы запустить утилиту, нажмите сочетание клавиш Win + R и напишите в поле ввода: sysprep

В результате откроется папка, расположенная в каталоге C:WindowsSystem32. Запустите приложение: sysprep.exe

Перед вами появится окно System Preparation Tool. В качестве действия по очистке системы выберите Enter System Out-of-Box Experience (OOBE), а если у вас русская версия, то выбирайте: Переход в окно приветствия системы (OOBE). Если вы хотите изменить SID, то выберите опцию Generalize или Перезагрузка в русской версии (внимание: галочка не выбрана по умолчанию). В качестве опции отключении (Shutdown Options) выберите Reboot (Перезагрузка).

Выполнение процедуры sysprep займет некоторое время. После перезагрузки вам придется указать ряд настроек, такие как страна, регион, время, дата и тип раскладки клавиатуры. Кроме того, вам придется принять (ну или отклонить 🙂) лицензионное соглашение (EULA). После загрузки в консоли Server Manager вы можете убедиться, что все настройки изменились. Теперь вы можете воспользоваться утилитой PsGetSid для того, чтобы узнать текущий новый SID вашей операционной системы.

Источник

Восстановление поврежденного профиля Windows

Не знаете, что делать, если не запускается учетная запись пользователя Windows или возникает ошибка «не удается войти в учётную запись»? Решение этих и других проблем со входом в профиль будет приведено ниже.

Содержание:

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

Утеря или повреждение профиля – достаточно неприятная ситуация, которая ограничивает доступ к некоторым функциям и данным, поэтому с данной проблемой необходимо справиться как можно быстрее.

Ошибка службы профилей пользователей (ProfSvc) имеет следующий вид:

Почему происходит повреждение профиля пользователя?

Повреждение профиля Windows может быть вызвано разными причинами.

Самыми частыми из них являются:

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

Поиск идентификатора безопасности учетной записи

Работа на временном профиле сильно ограничивает возможности, поэтому при выявлении подобной проблемы необходимо сразу приступить к её решению. Первое, что необходимо сделать – попробовать выйти с профиля и зайти на него вновь. Данный совет дает сама система, и этим не следует пренебрегать.

Если перезаход не помог, следует узнать идентификатор безопасности учетной записи (SID). Чтобы это сделать, понадобится командная строка или Windows PowerShell, запущенные с правами администратора.

Шаг 1. Нажимаем ПКМ по кнопке «Пуск» и выбираем пункт «Командная строка(Администратор)» или «Windows PowerShell(Администратор)».

Шаг 2. В командной строке необходимо ввести «whoami /user». Данная команда покажет SID текущего профиля.

Шаг 3. Копируем SID сочетанием клавиш Ctrl+C. Важно: SID имеет вид многозначного числового кода. В нашем случае это — S-1-5-21-4159091151-714581226-3499032617-1001.

После того, как SID был скопирован в буфер обмена, необходимо отредактировать реестр для восстановления профиля.

Как сделать бекап реестра?

Важно! Любые манипуляции с редактором реестра могут привести к неожиданным последствиям, поэтому нижеописанные шаги следует выполнять с максимальной осторожностью. Перед началом работы с реестром настоятельно рекомендуется создать запасную копию (бекап) текущего реестра.

Чтобы выполнить данную функцию, следует:

Шаг 1. Открыть редактор реестра, как описано ниже, и нажать на пункт «Файл» в верхнем левом углу. В выпадающем списке следует выбрать «Экспорт».

Шаг 2. В открывшемся окне необходимо присвоить имя запасному файлу реестра, а также сохранить его в нужном месте. Для экономии времени рекомендуется использовать сохранение только выбранной ветви реестра. Если пользователь собирается редактировать не только одну ветвь, лучше сделать бекап всего реестра.

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

Теперь переходим к восстановлению профиля.

Шаг 1. Нажимаем ПКМ по кнопке «Пуск» и выбираем пункт «Выполнить». В открывшемся окне вводим команду regedit и подтверждаем действие кнопкой «Ок».

Шаг 2. В редакторе реестра следует перейти по пути «КомпьютерHKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList».

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

Чтобы не терять время, рекомендуем просто скопировать КомпьютерHKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList и вставить в адресную строку.

В зависимости от системы и версии ОС, следующие действия могут немного различаться между собой, поэтому будут рассмотрены все варианты последующих действий, подходящих для всех случаев:

1. Если идентификатор SID указан в разделе «ProfileList» дважды, следует удалить один раздел без расширения .BAK. Это можно сделать, нажав по разделу правой клавишей мыши и выбрав пункт «Удалить».

3. Если присутствует одна папка с идентификатором без расширений, следует нажать по ней ЛКМ и перейти в пункт «ProfileImagePath». Далее нужно кликнуть по нему ПКМ и выбрать пункт «Изменить», как показано на скриншоте.

В строке «Значение» необходимо ввести правильный путь к папке своего профиля на системном диске. Проверить его можно, зайдя на диск С (диск, где установлена ОС) и выбрав папку «Пользователи». В нашем случае правильный путь к папке профиля имеет вид «C:UsersUser».

Соответственно путь в папке «ProfileImagePath» должен быть указан таким же.

Далее необходимо отредактировать параметр «State». Кликаем по нему ПКМ и выбираем пункт «Изменить».

В открывшемся окне в пункте «Значение» следует указать цифру «0».

На этом устранение ошибки Windows «не удается войти в учетную запись» можно считать законченным. После закрытия редактора реестра и перезагрузки компьютера профиль будет восстановлен.

Возможные проблемы с восстановлением профиля

В некоторых случаях восстановление профиля вышеописанными способами может не сработать. Это обусловлено сильным повреждением системных данных профиля или другими неполадками. В этом случае лучшим выходом будет создание нового профиля с правами администратора. Данная мера не позволит восстановить предыдущие настройки, поэтому подгонять новый профиль под свои нужды придется заново.

Для создания нового профиля следует загрузить систему в безопасном режиме. Загрузка безопасного режима детально описана в статье «Как загрузить безопасный режим в Windows»

После перезагрузки системы в безопасном режиме необходимо открыть командную строку или Windows PowerShell с правами администратора и ввести команду «net user administrator /active:yes».

После этого можно воспользоваться созданием новой учетной записи с правами администратора. Как это сделать, можно прочитать в статье «Изменение имени учетной записи Windows».

Часто задаваемые вопросы

Это сильно зависит от емкости вашего жесткого диска и производительности вашего компьютера. В основном, большинство операций восстановления жесткого диска можно выполнить примерно за 3-12 часов для жесткого диска объемом 1 ТБ в обычных условиях.

Если файл не открывается, это означает, что файл был поврежден или испорчен до восстановления.

Используйте функцию «Предварительного просмотра» для оценки качества восстанавливаемого файла.

Когда вы пытаетесь получить доступ к диску, то получаете сообщение диск «X: не доступен». или «Вам нужно отформатировать раздел на диске X:», структура каталога вашего диска может быть повреждена. В большинстве случаев данные, вероятно, все еще остаются доступными. Просто запустите программу для восстановления данных и отсканируйте нужный раздел, чтобы вернуть их.

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

Сохранить их можно после регистрации программы – повторное сканирование для этого не потребуется.

Источник

Как узнать идентификатор безопасности (SID) пользователя в Windows 10

В данной статье рассмотрено несколько способов, с помощью которых можно узнать идентификатор безопасности (SID) пользователя в операционной системе Windows 10.

Операционная система использует именно идентификаторы безопасности (SID) для контроля доступа к различным ресурсам, таким как объекты файловой системы, ключам реестра, сетевым каталогам, что означает, что даже если вы измените имя пользователя, то это не повлияет на какие-либо предварительные настройки для этой учетной записи, поскольку каждая конфигурация привязана к SID, который остается постоянным.

Идентификатор безопасности может быть полезен во время выполнения определенных команд, связанных с безопасностью компьютера.

Как узнать идентификатор безопасности (SID) пользователя в командной строке

Чтобы узнать SID текущего пользователя воспользуемся утилитой whoami, для этого откройте командную строку и выполните следующую команду:

Также узнать SID текущего пользователя можно выполнив следующую команду:

wmic useraccount where name=»%username%» get name,sid

Чтобы узнать все SID присутствующие в операционной системе, выполните команду:

Чтобы узнать SID определённого пользователя, выполните следующую команду:

wmic useraccount where name=»TestUser1″ get sid

Чтобы узнать имя пользователя учетной записи по SID (обратная процедура), выполните команду:

wmic useraccount where sid=» S-1-5-21-3210479907-464018182-414762983-1002 » get name

Как узнать идентификатор безопасности (SID) пользователя в Windows PowerSell

Также узнать идентификатор безопасности можно используя консоль Windows PowerShell.

Чтобы узнать все идентификаторы безопасности (SID) в консоли Windows PowerShell, выполните команду:

Get-WmiObject Win32_UserAccount | Select Name,SID

Чтобы узнать SID определённого пользователя, выполните следующую команду:

Также узнать SID определённого пользователя, можно выполнив команду:

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

Где вместо SID укажите нужный идентификатор безопасности.

В данном примере команда выглядит так:

Как узнать идентификатор безопасности (SID) в редакторе реестра

Используя редактор реестра, также можно узнать идентификатор безопасности (SID), для этого откройте редактор реестра нажав сочетание клавиш + R и в открывшемся окне Выполнить введите regedit и нажмите клавишу Enter ↵.

В открывшемся окне редактора реестра, скопируйте/вставьте или перейдите по следующему пути:

В разделе ProfileList вы увидите всех пользователей и их идентификаторы SID.

Источник

Сброс sid windows 10

Sysprep — Утилита системной подготовки Microsoft Windows к развертыванию. Sysprep первоначально был представлен для использования с Windows NT 4.0

Примечание: Изменение SID вашего железа может помочь вам продолжать использовать программы, которые требуют ввода лицензионного ключа. Чтобы не тратить время на поиски ключа в интернете, просто смените SID и пользуйтесь платной программой ещё 30 или более дней.

Ранее для изменения SID применялась утилита NewSID, однако сейчас ее использование не поддерживается Microsoft, кроме того, использовать ее в новых ОС, типа Windows Server 2008 R2, просто опасно. Поэтому для изменения SID вашего ПК лучше всего использовать sysprep, использовать эту утилиту достаточно просто, и далее я опишу всю последовательность шагов.

Чтобы запустить утилиту, нажмите сочетание клавиш Win + R и напишите в поле ввода: sysprep

В результате откроется папка, расположенная в каталоге C:WindowsSystem32. Запустите приложение: sysprep.exe

Перед вами появится окно System Preparation Tool. В качестве действия по очистке системы выберите Enter System Out-of-Box Experience (OOBE), а если у вас русская версия, то выбирайте: Переход в окно приветствия системы (OOBE). Если вы хотите изменить SID, то выберите опцию Generalize или Перезагрузка в русской версии (внимание: галочка не выбрана по умолчанию). В качестве опции отключении (Shutdown Options) выберите Reboot (Перезагрузка).

Выполнение процедуры sysprep займет некоторое время. После перезагрузки вам придется указать ряд настроек, такие как страна, регион, время, дата и тип раскладки клавиатуры. Кроме того, вам придется принять (ну или отклонить 🙂) лицензионное соглашение (EULA). После загрузки в консоли Server Manager вы можете убедиться, что все настройки изменились. Теперь вы можете воспользоваться утилитой PsGetSid для того, чтобы узнать текущий новый SID вашей операционной системы.

Источник

Как сбросить SID у системы Windows

Что важно если система (Windows) было клонирована средствами Virtualbox. При попытке ввода в домен Вы можете получить сообщение вида:

« The domain join cannot be completed because the SID of the domain you attempted to join was identical to the SID of this machine. This is a symptom of an improperly cloned operating system install. You should run sysprep on this machine in order to generate a new machine SID »

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

На Windows Server 2012 R2 — Win + X → Command Prompt (Admin)

C:Windowssystem32>cd Sysprep

C:WindowsSystem32Sysprep>sysprep /oobe /generalize /shutdown

[stextbox style=»color: #ff00ff;»>На заметку: На других линейках операционной системы Windows все тоже самое, главное запустить консоль командной строки с правами Администратора.[/stextbox]

После исполнения данной команды система выключиться, потребуется ее включить и необходимо будет указать текущую страну или регион (« Country or region »), используемый язык (« App language »), раскладку клавиатуры (« Keyboard layout »), согласиться с лицензионный соглашение, задать пароль на учетную запись Администратора, система после уйдет в перезагрузку, а когда загрузиться то будет полностью обнуленной, как будто Вы ее только что поставили (USB Flash Drive, DVD/CD ROM) из образа (и не будет клонированной). Я делаю после этого (я решил задокумментировать все это столкнувшись в очередной раз на Windows Server 2012 R2 Standard, а потому и действия сочетаний клавиш привожу относительно ей):

Win + X → Command Prompt (Admin)

C:Windowssystem32>net user Administrator | findstr /C:expires

Account expires Never

Password expires 11/6/2018 8:42:46 PM

C:Windowssystem32>wmic useraccount where name=’Administrator’ set passwordexpires=FALSE

Updating property(s) of ‘\WIN-ENBQ1C4A7CMROOTCIMV2:Win32_UserAccount.Domain=»WIN-ENBQ1C4A7CM»,Name=»Administrator»‘

C:Windowssystem32>net user Administrator | findstr /C:expires

Account expires Never

Password expires Never

Property(s) update successful.

А раз так, то и использовать ее можно хоть в домене, хоть где либо еще.

Не стоит об этом забывать и тратить драгоценное время если моделируете различные ситуации под Virtualbox, ESXi перед тем как все сделать на боевом окружении.

Итого заметка работоспособна, на этом я прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059
Yandex-деньги: 41001520055047

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Источник

Сброс sid windows 10

Сообщения: 35554
Благодарности: 6326

В результате откроется папка, расположенная в каталоге C:WindowsSystem32. Запустите приложение: sysprep.exe

Перед вами появится окно System Preparation Tool. В качестве действия по очистке системы выберите Enter System Out-of-Box Experience (OOBE), а если у вас русская версия, то выбирайте: Переход в окно приветствия системы (OOBE). Если вы хотите изменить SID, то выберите опцию Generalize или Перезагрузка в русской версии (внимание: галочка не выбрана по умолчанию). В качестве опции отключении (Shutdown Options) выберите Reboot (Перезагрузка).

Выполнение процедуры sysprep займет некоторое время. После перезагрузки вам придется указать ряд настроек, такие как страна, регион, время, дата и тип раскладки клавиатуры. Кроме того, вам придется принять (ну или отклонить 🙂) лицензионное соглашение (EULA). После загрузки в консоли Server Manager вы можете убедиться, что все настройки изменились. Теперь вы можете воспользоваться утилитой PsGetSid для того, чтобы узнать текущий новый SID вашей операционной системы.

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

Содержание статьи

Третьего ноября этого года в Sysinternals был закрыт проект по развитию

NewSID – утилиты, позволяющей менять идентификатор защиты компьютера
(machine SID). Я написал NewSID (тогда она называлась NTSID) в 1997 году,
поскольку на тот момент единственной программой, позволявшей менять SID, была
утилита от Microsoft под названием

Sysprep, которая не поддерживала смену идентификаторов защиты на тех
машинах, на которых уже были установлены приложения.

Идентификатор защиты компьютера – это уникальный идентификатор, генерируемый
программой установки Windows Setup, который Windows использует как основной
идентификатор безопасности для определяемых администратором локальных аккаунтов
и групп. После того, как пользователь авторизуется в системе, он представляется
ей своими идентификаторами SID пользователя и группы в соответствии с
авторизацией объекта (проверками прав доступа). И если две машины могут иметь
одинаковый идентификатор защиты, то и аккаунты с группами на них могут также
иметь одинаковые идентификаторы. Кажется очевидным, что наличие нескольких
компьютеров с одинаковыми SID в пределах одной сети небезопасно, не правда ли?
По крайней мере, так принято было думать.

Причиной, по которой я начал рассматривать возможность отправки NewSID на
покой, были отзывы пользователей. Хотя в целом применение утилиты на Windows
Vista было успешным, некоторые пользователи сообщали об ошибках в работе
компонентов системы после использования NewSID. К тому же, сам я не проводил ее
полного тестирования. Когда я принялся за изучение отзывов, я сделал шаг назад,
чтобы понять, как дублированные SID могут становиться причинами проблем,
поскольку раньше я принимал возможность этого на веру, как и все остальные. И
чем больше я об этом думал, тем крепче была моя убежденность, что дублирование
сертификатов безопасности, то есть наличие множества компьютеров с одинаковыми
SID, само по себе не может быть причиной для возникновения проблем с
безопасностью или чем-нибудь еще. Я поделился своими мыслями с командами
разработчиков Windows, занимающимися безопасностью и развертыванием систем, и
там никто не смог придумать такую последовательность действий, при которой две
системы с одинаковыми SID, работающие в пределах рабочей группы или домена,
могли бы стать причиной ошибки. С этого момента решение закрыть NewSID стало
очевидным.

Я понимаю, что новость о том, что в наличии дублированных SID нет ничего
страшного, станет для многих неожиданностью, особенно если учесть, что практика
смены идентификаторов безопасности при развертывании систем из образов
применяется еще со времен Windows NT. Эта статья разоблачает миф об опасности
дублирования SID, и чтобы его развеять, я сначала объясню, что же такое
идентификаторы безопасности компьютера и как они используются Windows, после
чего продемонстрирую, что за одним исключением, Windows никогда не показывает
идентификаторы безопасности вне компьютера, а потому иметь машины с одинаковыми
SID абсолютно нормально.

Идентификаторы безопасности (SID)

Windows использует идентификаторы SID для представления не только машин, а
вообще всего пространства имен System Security Principal, частью которого
являются машины, учетные записи домена, пользователей и групп безопасности. Их
имена — лишь более понятные для пользователей формы представления SID,
позволяющие например переименовать учетную запись без необходимости обновлять
для отображения внесенных изменений ссылающиеся на эту учетную запись списки
управления доступом (ACL). Идентификатор SID — это числовое значение
переменной длины, формируемое из номера версии структуры SID, 48-битного кода
агента идентификатора и переменного количества 32-битных кодов субагентов и/или
относительных идентификаторов (RID). Код агента идентификатора (identifier
authority value) определяет агент, выдавший SID. Таким агентом обычно является
локальная система или домен под управлением Windows. Коды субагентов
идентифицируют попечителей, уполномоченных агентом, который выдал SID, a RID —
не более чем средство создания уникальных SID на основе общего базового SID.

Увидеть, что собой представляет SID машины можно, если воспользоваться
утилитой

PsGetSid, запущенной через командную строку без параметров:

В этом SID номер версии равен 1, код агента идентификатора — 5, а далее идут
коды четырех субагентов. Одно время в Windows NT идентификатор SID мог
использоваться для идентификации компьютера в сети, поэтому для обеспечения
уникальности при генерировании SID в Windows Setup он содержит один
фиксированный (21) и три генерируемых случайным образом (числа после «S-1-5-21»)
кода субагентов.

Еще перед тем, как вы создадите первую учетную запись в системе, Windows
определяет несколько встроенных пользователей и групп, включая учетные записи
«Администратор» и «Гость». Вместо того, чтобы генерировать новые случайные
идентификаторы SID для этих учетных записей, Windows обеспечивает их
непохожесть, просто добавляя в SID уникальные для каждой учетной записи числа,
называемые относительными идентификаторами (Relative Identifier, RID). Для
упомянутых выше встроенных учетных записей RID определены заранее, поэтому у
пользователя «Администратор» RID всегда равен 500:

После установки системы Windows назначает новым локальным учетным записям
пользователей и групп номера RID, начинающиеся со значения 1000. Чтобы увидеть
имя учетной записи, которой принадлежит указанный SID, можно воспользоваться
PsGetSid. Пример внизу демонстрирует, что локальный SID с параметром RID, равным
1000, принадлежит учетной записи Abby — аккаунту администратора, имя которого
система обязала меня ввести во время установки:

Плюс к этим динамически создаваемым SID, система определяет несколько
аккаунтов, которые также всегда имеют предопределенные значения SID. Один из
примеров – группа Everyone, SID которой в каждой системе Windows имеет значение
S-1-1-0:

Другой пример — учетная запись Local System, под которой выполняются
некоторые системные процессы, такие как Session Manager (Smss.exe), Service
Control Manager (Services.exe) и Winlogon (Winlogon.exe):

Идентификаторы безопасности и списки управления доступом (ACL)

После того, как пользователь вошел в систему Windows под своей учетной
записью, подсистема локальной авторизации (Local Security Authority Subsystem,
Lsass.exe) создает сессию входа и маркер для нее. Маркер — это структура данных,
которую ядро Windows определяет для представления учетной записи и которая
содержит в себе SID этой учетной записи, а также SID групп, к которым
принадлежит данная учетная запись на момент входа в систему и назначенные для
этой учетной записи и групп привилегии безопасности. Когда последний маркер,
ссылающийся на сессию входа, удаляется, LSASS удаляет и сессию входа, после чего
пользователь считается вышедшим из системы. Ниже можно увидеть информацию о моей
интерактивной сессии входа, отображенную с помощью утилиты Sysinternals

LogonSessions:

А здесь (в окне Handle Process Explorer) можно увидеть информацию о маркере,
который Lsass создал для этой сессии. Обратите внимание, что число, следующее за
именем учетной записи (7fdee), соответствует идентификатору входной сессии из
LogonSessions:

По умолчанию процессы наследуют копию маркера своего родительского процесса.

Так, каждый процесс, запущенный в моей интерактивной сессии, имеет копию
маркера, изначально унаследованного им от процесса Userinit.exe, который первым
создается Winlogon при каждом интерактивном входе в систему. Вы можете
посмотреть содержимое маркера процесса, сделав двойной щелчок на строке процесса
в

Process Explorer и переключившись на вкладку Security в диалоговом окне
свойств процесса:

Когда один из моих процессов открывает объект операционной системы, например,
файл или ключ системного реестра, подсистема безопасности осуществляет проверку
прав доступа, в ходе которой сверяются те записи в списке управления доступом
(ACL) объекта, которые ссылаются на 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 будет пропущен.

Adblock
detector

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

Системное администрирование, ИТ-инфраструктура, Восстановление данных, Блог компании Acronis, Inc

---

Рекомендация: подборка платных и бесплатных курсов создания сайтов — https://katalog-kursov.ru/

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

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

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

Что такое SID, его типы и чем отличается Machine SID от Domain 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
DEMOSYSTEMAdministrator	S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEMGuest	S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEMCustomAccount1	S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEMCustomAccount2	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
BIGDOMAINDEMOSYSTEM$ (аккаунт машины (computer account))	S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAINJOHNSMITH (аккаунт пользователя (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 у обоих машин должен быть уникальным для корректной работы в этом домене.

В применении к продукту 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

Спасибо за внимание!