Смена id windows после клонирования

Время на прочтение6 мин

Количество просмотров104K

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

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

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

Картинка с сайта: habr.com

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

Что такое 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 в конце. Для примера:

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

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

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

Таким образом, машина 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 в подавляющем большинстве случаев.

Картинка с сайта: habr.com

Линки

— Как изменить 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

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

Картинка с сайта: www.wittytool.com

In Windows 10, the Security Identifier (SID) acts as a unique identifier for user accounts and devices, playing a vital role in security by managing access to resources. Changing the SID is essential when addressing security issues or cloning complications, as duplicate SIDs can result in unauthorized access and privilege escalation. While traditional methods such as Sysprep are frequently employed, there are other options available. This guide delves into how to change SID Windows 10 without Sysprep, offering a practical method for effectively managing security.

Understanding SID in Windows 10

What is SID?

A Security Identifier (SID) serves as a unique code assigned to each user account and device within a Windows environment. This identifier plays a crucial role in maintaining security by controlling access to resources. Each SID consists of a string of characters that Windows uses to identify users and devices. The SID ensures that only authorized users can access specific files, folders, and system settings. Without a unique SID, the system cannot differentiate between different users or devices, leading to potential security risks.

Also learn: [solved] How to Recreate Recovery Partition in Windows 10/11

Why Change SID?

Changing the SID becomes necessary when addressing security vulnerabilities. Attackers often exploit SID injection techniques to escalate privileges and bypass security controls. A compromised SID can allow unauthorized access to sensitive information, leading to data breaches. By changing the SID, you enhance the security posture of your Windows 10 system. This proactive measure prevents attackers from exploiting known vulnerabilities associated with duplicate SIDs.

Cloning a Windows 10 machine without altering the SID can lead to significant problems. Multiple devices with the same SID create conflicts within network environments. These conflicts result in issues with user permissions and access control. When two devices share an identical SID, the system cannot distinguish between them, causing operational disruptions. Changing the SID resolves these conflicts, ensuring smooth operation and proper resource allocation. This step is vital for maintaining a secure and efficient network infrastructure.

Preparing for SID Change

Backup Important Data

Before changing the SID, prioritize data protection. Use third-party software like Wittytool DiskClone. This free tool provides automatic backups for Windows OS, applications, and hard drives. Regular backups prevent data loss and facilitate recovery if issues arise. With this tool, you can also do a network clone easily. Now download this tool and follow the steps below:

Step 1. Turn to Backup tab, click Create backup.

Картинка с сайта: www.wittytool.com

Step 2. Choose the data which you want to backup, then click Start Backup.

Картинка с сайта: www.wittytool.com

Step 3. The software will perform an automatic and fast backup, and once the process is complete, you can easily locate the backup file.

Ensure System Compatibility

Verify system compatibility before proceeding with the SID change. Confirm that the hardware and software meet the requirements for the chosen method. Check for updates to ensure that the system runs the latest version of Windows 10. Compatibility checks prevent potential conflicts and ensure a smooth transition. Evaluate third-party tools for compatibility with the current system configuration. A thorough assessment minimizes risks and enhances the success of the SID change process.

Also learn: Windows 10 System Restore Taking a Long Time: Solutions and Tips

Methods to Change SID Windows 10 Without Sysprep

Changing the SID in Windows 10 without using Sysprep requires careful consideration and precise execution. Explore two primary methods: using third-party tools and manual processes.

(Recommended) Using Third-Party Tools to Change SID Windows 10

Third-party utilities provide a simplified solution for modifying Windows SIDs in Windows 10 environments. These specialized tools streamline the process through automation while minimizing potential configuration errors. While SIDCHG was historically a common choice for its straightforward SID modification interface, this legacy tool has become outdated.

For modern implementations, we recommend utilizing WittyTool DiskClone‘s “Change Windows SID” feature, which offers enhanced reliability and maintains user-friendly operation. It remains popular among system administrators for the operational efficiency and reduced technical complexity.

Now Continue using the WittyTool Disk Clone software and follow the step-by-step instructions to change the Windows SID.

Step 1. Access the SID Change Feature

① Launch Wittytool DiskClone and navigate to the left-side menu.
② Click Tools → Select Change SID.

Картинка с сайта: www.wittytool.com

Step 2. Confirm and Execute

① A confirmation dialog will appear: “Do you want to continue with the execution?”
② Click YES to initiate the SID change process.

Картинка с сайта: www.wittytool.com

Step 3: Reboot and Validate

If successful:

①A prompt will display: “The command to modify SID is currenty being executed, After completion, the system will automatically restart.”

②Click OK → The system will reboot automatically, and the new SID will take effect.

Картинка с сайта: www.wittytool.com

If failed:

①An error message will appear.

②Install pending Windows updates via Settings → Windows Update, then retry.

Картинка с сайта: www.wittytool.com

Key Notes:
⚠️ Run the software as Administrator if permission errors occur.
⚠️ Temporarily disable third-party antivirus to avoid conflicts.

Note: Microsoft does not officially support third-party tools for SID changes. Ensure a thorough understanding of potential risks before proceeding.

Manual SID Change Process

For those with technical expertise, a manual process offers more control over the SID change.

Registry Editing

1. Open Registry Editor: Press Win + R, type regedit, and press Enter. This opens the Registry Editor.
2. Navigate to SAM Database: Locate the Security Account Manager (SAM) database. Exercise caution when editing registry entries.
3. Modify SID Entries: Carefully alter the SID values. Ensure accuracy to prevent system instability.
4. Save and Exit: Save changes and exit the Registry Editor. Restart the computer to apply changes.

Command Line Instructions

1. Open Command Prompt: Access the Command Prompt with administrative privileges.
2. Use WMIC Commands: Execute wmic useraccount get name,sid to list current SIDs. Identify the SID to change.
3. Apply Changes: Use specific commands to modify the SID. Double-check syntax to avoid errors.
4. Restart System: Reboot the system to finalize changes. Verify the new SID through system checks.

Both methods require attention to detail and a clear understanding of potential risks. Changing the SID Windows 10 without Sysprep can enhance security and resolve cloning issues, but always proceed with caution.

Verifying SID Change

Checking New SID

You need to confirm the success of the SID change. Open the Command Prompt with administrative privileges. Type wmic useraccount get name,sid and press Enter. This command will display the current SIDs for all user accounts. Compare the new SID with the previous one. Ensure that the SID has changed correctly. Verification guarantees that the change sid windows 10 process completed successfully.

Troubleshooting Common Issues

Issues may arise after changing the SID. You might encounter login problems or access denials. Restart the system to resolve minor glitches. Check for any software conflicts by reviewing recent installations. Use the Event Viewer to identify specific errors. Access the Event Viewer by typing eventvwr in the Run dialog. Look for warnings or errors related to user accounts. If problems persist, consider restoring from a backup. Regular backups ensure data safety during the change sid windows 10 process.

Conclusion

Explore the methods to change the SID in Windows 10 without Sysprep. Each method offers unique benefits and challenges. Effective SID management is crucial for maintaining security and preventing unauthorized access. Follow best practices to ensure a secure computing environment. Regularly review and update security protocols to align with modern standards. Always give top priority to data security and system compatibility. Implementing these strategies will enhance your network’s security and efficiency.

Перемещаясь из одной компании в другую, практически везде вижу одну и ту же картину: клонированные с помощью Acronis или Ghost рабочие станции, а также тиражированные на гипервизоре VMWare сервера не распознаются сервером Windows Server Update Services (WSUS). То есть, компьютеры видят WSUS и ставят с него обновления, на самой же консоли управления WSUS их не видно — из 600 рабочих станций распознаются, к примеру, всего 100.

Причина весьма проста — после первого же визита на Windows Update служба WUAUServ генерирует уникальный идентификатор SusClientId, затем администратор сохраняет образ уже обновленной операционной системы. У всех растиражированных с данного образа копии ОС этот идентификатор будет одинаков.

Заменить SusClientId просто, и статей на эту тему предостаточно. Меня же интересовало написание скрипта, который можно применить в любой компании сразу ко всем машинам. Думается, мне не жалко им поделиться с вами. Сохраните скрипт в шаринг NetLogon контроллера домена, затем сконфигурируйте его запуск в качестве Startup Script для всех компьютеров домена. Для отсылки уведомлений на почту раскидайте на все компьютеры программу BLAT (http://www.blat.net/).

@echo off
set NetworkFolder=\\FileServer\Data\Computer_Reports\SusClientId
set LogFileName=C:\Windows\SusClientId.txt
set MailServer=mail.company.lv
set MailFrom=%ComputerName%@Company.local
set RcptTo=ITSupport@Company.lv

set SusClientId=None
if not exist %NetworkFolder% goto End
if exist «%NetworkFolder%\Computer_%ComputerName%.txt» goto End
echo Checking WSUS Client ID on %ComputerName% at %date% %time% > «%LogFilename%»
for /f «tokens=2,*» %%a in (‘reg query HKLM\Software\Microsoft\Windows\Currentversion\WindowsUpdate /v SusClientId 2^>NUL ^| findstr SusClientId’) do set SusClientId=%%b
echo Current ID = %SusClientId% >> «%LogFilename%»
if not exist «%NetworkFolder%\ID_%SusClientId%.txt» goto Update

:ResetID
reg delete HKLM\Software\Microsoft\Windows\Currentversion\WindowsUpdate /f /v SusClientId
reg delete HKLM\Software\Microsoft\Windows\Currentversion\WindowsUpdate /f /v SusClientIdValidation
net stop WUAUServ
ping localhost
net start WUAUServ
ping localhost
wuauclt /resetauthorization /detectnow

for /f «tokens=2,*» %%a in (‘reg query HKLM\Software\Microsoft\Windows\Currentversion\WindowsUpdate /v SusClientId 2^>NUL ^| findstr SusClientId’) do set SusClientId=%%b
echo WSUS ID has been updated >> %LogFilename%
echo New ID = %SusClientId% >> %LogFilename%
if exist «%NetworkFolder%\ID_%SusClientId%.txt» goto End
ping localhost
blat.exe %LogFilename% -f %MailFrom% -to %RcptTo% -subject «WSUS Client ID Update Notification» -server %MailServer%

:Update
echo %ComputerName% > «%NetworkFolder%\ID_%SusClientId%.txt»
echo %SusClientId% > «%NetworkFolder%\Computer_%ComputerName%.txt»
:End

Как оно работает:

1. Отрабатывая впервые, скрипт сохраняет в сетевой папке %NetworkFolder% два файла: %ComputerName%.txt и ID_%SusClientId%.txt. Ну вот так мне захотелось.
2. В дальнейшем, если файл с именем компьютера уже есть, скрипт просто заканчивает свою работу. Это означает, что он уже отстрелялся ранее.
3. Если же обнаруживается, что файла с именем компьютера нет, а файл с идентификатором есть, выходит, что этот ID уже занят кем-то другим. В этом случае скрипт уничтожает свой текущий SusClientId и генерирует его заново. Новый идентификатор высылается на заданный почтовый адрес для того, чтобы отметить сам факт его успешной замены.

Заметил, что при первой зачистке существует вероятность генерации нового идентификатора, идентичного предыдущему. С остальным, думаю, разберётесь сами.