January 12, 2016 at 11:11SID change during cloning and mass deployment
Hello, Habr! The topic mentioned in the title still gives rise to multiple discussions and misunderstandings between system administrators. In my article I will try to answer the following questions:
These issues will be considered primarily in the context of the task of deploying / cloning multiple workstations / servers from one master image within the same company. The reasoning was based on a popular article by Mark Russinovich (also available in Russian ), which is often misinterpreted (judging by the comments and “response articles”), which leads to unpleasant consequences. Welcome to cat.
First of all, it is important to distinguish between the SID of the computer (Machine SID) and the SID of the domain (Domain SID), which are independent and are used in different operations.
Machine SID and Domain SID consist of a base SID (base SID) and a relative SID (Relative SID = RID), which is “glued” at the end to the base. The basic SID can be considered as an entity within which groups and accounts can be defined. A machine (computer) is an entity within which local groups and accounts are defined. Each machine is assigned a machine SID, and the SIDs of all local groups and accounts include this Machine SID with an RID added at the end. For example:
It is SIDs (and not names) that are stored in access tokens and security descriptors, and it is SIDs that are used to check access to Windows system objects (including, for example, files).
On a machine outside the domain, local SIDs described above are used. Accordingly, when connecting to a machine, local authentication is used remotely, therefore even having 2 or more machines with the same machine SID on the same network outside the domain, there will be no problems with login and work inside the system, because SIDs in remote authentication operations are simply not used. The only case in which problems are possible is a complete coincidence of the username and password on two machines - then, for example, the RDP between them may fail.
When the machine is added to the domain, a new SID comes into play, which is generated at the stage of adding. Machine SID does not go anywhere, as well as local groups and users. This new SID is used to represent the machine account within the domain. For example:
Thus, the DEMOSYSTEM machine now has two independent SIDs:
• Machine SID, which defines the machine as an entity within which groups and accounts are defined (first line in the first table).
• SID of the machine account (computer account SID) within the BIGDOMAIN domain (second line in the second table).
You can see the exact value of machine SID using the utility PsGetSid , starting it without parameters. Second the SID, on the domain, it can be seen running PsGetSid with the following parameters:
The main point is that SIDs must be unique within the authority to which they apply. In other words, if a machine SID S-1-5-21-3419697060-3810377854-678604692-1000 is assigned to a DEMOSYSTEM machine, it doesn’t matter that another machine on the same network has the same machine SID, because this SID is used only locally (within the DEMOSYSTEM machine). But within the BIGDOMAIN computer domain, the SID of both machines must be unique for it to work correctly in this domain.
As applied to the Acronis Snap Deploy 5 product (the main purpose is mass deployment of systems from the master image), in which the SID change functionality was present from the very first version, this means that we, like many users, mistook the prevailing opinion that you need to change the SID.
However, based on the foregoing, there is nothing wrong with deploying (or cloning) a machine without changing Machine SID at all, if this deployment occurs before the machine is added to the domain. Otherwise, problems will arise.
There is one exception to this rule:you cannot clone a machine if in the future the role of this clone is planned to be promoted to the domain of the controller. In this case, the Machine SID domain of the controller will coincide with the computer SID in the created domain, which will cause problems when trying to add the original machine (from which cloning was made) to this domain. This obviously only applies to the Windows server family.
To revise the point of view on the functionality of changing SID we were prompted by the release of a new version of Windows. During the first test deployment of the Windows 10 image with a change of SID on the resulting machine, it turned out that the Start button stopped being pressed (and this turned out to be just the tip of the "iceberg"). If you deploy the same image without changing the SID, then this problem does not arise.
The main reason is that this option makes changes to almost the entire file system of the deployed machine. Changes are made to the Windows registry, to NTFS permissions (NTFS permissions) for each file, to SIDs of local users (since the SID of a user includes machine SID as well; more details here ), etc.
In the case of Windows 10, most of the registry keys could not be modified ("Error code = C0000005. Access violation" and other errors) and, as a result, our SID change function did not work out to the end, which led to almosttragic death non-working copy of Windows 10.
It was decided to remove this option if we find Windows 10 (or Windows Server 2016) in the master image. The decision was made on the basis of theoretical calculations described above, plus, of course, it was confirmed by practice when testing the recently released Acronis Snap Deploy 5 update in many combinations: with and without renaming machines after deployment, adding to the domain and workgroup, deploying from master images taken from different states of the master machine (it was added to the domain or workgroup in different tests), etc.
Starting with Windows NT, cloning (deploying) an OS using only NewSID has never been recommended by Microsoft itself. Instead, it is recommended to use the native Sysprep utility (see KB314828 ), which, in addition to changing the SID, also makes a large number of other changes, and with each new version of Windows there are only more of them. Here is a small (incomplete) list of major changes:
Thus, cloning / deployment without using Sysprep can affect (read “most likely to break”) the functionality of Windows Update, Network Load Balancing, MSDTC, Vista and above Key Manager Activation (KMS), which is linked to CMID (not to be confused with Machine SID), also modified by Sysprep, etc.
Repeating TL; DR from the beginning of the article, the main conclusion can be drawn as follows: to prepare the image of the machine for cloning / deployment, sysprep should be used in the vast majority of cases.
- How to change the SID in Windows 7 and Windows Server 2008 R2 using sysprep
- How to View Full Details of All User Accounts in Windows 10
- The Myth of Duplicating the SID of a Computer
- 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
Thank you for your attention!
- What is a SID and what types can it be?
- When will having two or more machines with the same Machine SID cause problems? Or, in other words, when does (need to) change Machine SID?
- What is Sysprep and is Sysprep needed for cloning / deployment?
These issues will be considered primarily in the context of the task of deploying / cloning multiple workstations / servers from one master image within the same company. The reasoning was based on a popular article by Mark Russinovich (also available in Russian ), which is often misinterpreted (judging by the comments and “response articles”), which leads to unpleasant consequences. Welcome to cat.
TL; DR
- Changing the SID of a machine in itself is pointless and even harmful for modern OSes (an example of the consequences of changing SID on Windows 10 below).
- To prepare a machine for image cloning / deployment, use sysprep.
- The SID of the machine will only matter if one of the inclined machines is promoted to the controller domain. This is not worth doing.
- Do not clone / deploy an image of a machine that is ALREADY added to the domain; adding to the domain must be done after cloning / deployment.
What is a SID, its types, and how is Machine SID different from Domain SID?
Educational program
“ SID (Security Identifier), or Security Identifier — This is a variable-length data structure that identifies a user, group, domain, or computer account (on Windows based on NT technology (NT4, 2000, XP, 2003, Vista, 7.8) ) SID is mapped to each account at the time of its creation. The system operates with SIDs of accounts, and not their names. Only SIDs also participate in the control of user access to protected objects (files, registry keys, etc.). ”
First of all, it is important to distinguish between the SID of the computer (Machine SID) and the SID of the domain (Domain SID), which are independent and are used in different operations.
Machine SID and Domain SID consist of a base SID (base SID) and a relative SID (Relative SID = RID), which is “glued” at the end to the base. The basic SID can be considered as an entity within which groups and accounts can be defined. A machine (computer) is an entity within which local groups and accounts are defined. Each machine is assigned a machine SID, and the SIDs of all local groups and accounts include this Machine SID with an RID added at the end. For example:
| Machine SID for a machine named 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 |
It is SIDs (and not names) that are stored in access tokens and security descriptors, and it is SIDs that are used to check access to Windows system objects (including, for example, files).
On a machine outside the domain, local SIDs described above are used. Accordingly, when connecting to a machine, local authentication is used remotely, therefore even having 2 or more machines with the same machine SID on the same network outside the domain, there will be no problems with login and work inside the system, because SIDs in remote authentication operations are simply not used. The only case in which problems are possible is a complete coincidence of the username and password on two machines - then, for example, the RDP between them may fail.
When the machine is added to the domain, a new SID comes into play, which is generated at the stage of adding. Machine SID does not go anywhere, as well as local groups and users. This new SID is used to represent the machine account within the domain. For example:
| Domain SID for BIGDOMAIN | S-1-5-21-124525095-708259637-1543119021 |
| BIGDOMAIN \ DEMOSYSTEM $ (machine account) | S-1-5-21-124525095-708259637-1543119021-937822 |
| BIGDOMAIN \ JOHNSMITH (user account) | S-1-5-21-124525095-708259637-1543119021-20937 |
Thus, the DEMOSYSTEM machine now has two independent SIDs:
• Machine SID, which defines the machine as an entity within which groups and accounts are defined (first line in the first table).
• SID of the machine account (computer account SID) within the BIGDOMAIN domain (second line in the second table).
You can see the exact value of machine SID using the utility PsGetSid , starting it without parameters. Second the SID, on the domain, it can be seen running PsGetSid with the following parameters:
psgetsid %COMPUTERNAME%$. Accordingly, for an example from the tables it will be “ psgetsid DEMOSYSTEM$".The main point is that SIDs must be unique within the authority to which they apply. In other words, if a machine SID S-1-5-21-3419697060-3810377854-678604692-1000 is assigned to a DEMOSYSTEM machine, it doesn’t matter that another machine on the same network has the same machine SID, because this SID is used only locally (within the DEMOSYSTEM machine). But within the BIGDOMAIN computer domain, the SID of both machines must be unique for it to work correctly in this domain.
SID change when cloning or deploying
As applied to the Acronis Snap Deploy 5 product (the main purpose is mass deployment of systems from the master image), in which the SID change functionality was present from the very first version, this means that we, like many users, mistook the prevailing opinion that you need to change the SID.
However, based on the foregoing, there is nothing wrong with deploying (or cloning) a machine without changing Machine SID at all, if this deployment occurs before the machine is added to the domain. Otherwise, problems will arise.
There is one exception to this rule:you cannot clone a machine if in the future the role of this clone is planned to be promoted to the domain of the controller. In this case, the Machine SID domain of the controller will coincide with the computer SID in the created domain, which will cause problems when trying to add the original machine (from which cloning was made) to this domain. This obviously only applies to the Windows server family.
SID Change Issues
To revise the point of view on the functionality of changing SID we were prompted by the release of a new version of Windows. During the first test deployment of the Windows 10 image with a change of SID on the resulting machine, it turned out that the Start button stopped being pressed (and this turned out to be just the tip of the "iceberg"). If you deploy the same image without changing the SID, then this problem does not arise.
The main reason is that this option makes changes to almost the entire file system of the deployed machine. Changes are made to the Windows registry, to NTFS permissions (NTFS permissions) for each file, to SIDs of local users (since the SID of a user includes machine SID as well; more details here ), etc.
In the case of Windows 10, most of the registry keys could not be modified ("Error code = C0000005. Access violation" and other errors) and, as a result, our SID change function did not work out to the end, which led to almost
It was decided to remove this option if we find Windows 10 (or Windows Server 2016) in the master image. The decision was made on the basis of theoretical calculations described above, plus, of course, it was confirmed by practice when testing the recently released Acronis Snap Deploy 5 update in many combinations: with and without renaming machines after deployment, adding to the domain and workgroup, deploying from master images taken from different states of the master machine (it was added to the domain or workgroup in different tests), etc.
Using sysprep
Starting with Windows NT, cloning (deploying) an OS using only NewSID has never been recommended by Microsoft itself. Instead, it is recommended to use the native Sysprep utility (see KB314828 ), which, in addition to changing the SID, also makes a large number of other changes, and with each new version of Windows there are only more of them. Here is a small (incomplete) list of major changes:
- The name of the machine is deleted.
- The machine is displayed from the domain: this is necessary for the subsequent successful addition to the domain with a new name
- Plug-and-play drivers are removed, which reduces the risk of compatibility problems on the new hardware
- Optionally deleted Windows Event Logs ('reseal' parameter)
- Recovery points are deleted
- The local administrator profile is deleted and this account is disabled.
- The target machine is loaded into audit mode , which allows installing additional applications and drivers
- Provides run mini-setup when you first start to change the machine name and other additional configuration
- The Windows activation period is reset (up to 3 times possible)
Thus, cloning / deployment without using Sysprep can affect (read “most likely to break”) the functionality of Windows Update, Network Load Balancing, MSDTC, Vista and above Key Manager Activation (KMS), which is linked to CMID (not to be confused with Machine SID), also modified by Sysprep, etc.
Total
Repeating TL; DR from the beginning of the article, the main conclusion can be drawn as follows: to prepare the image of the machine for cloning / deployment, sysprep should be used in the vast majority of cases.
Links
- How to change the SID in Windows 7 and Windows Server 2008 R2 using sysprep
- How to View Full Details of All User Accounts in Windows 10
- The Myth of Duplicating the SID of a Computer
- 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
Thank you for your attention!