SID change during cloning and mass deployment
Hi, Habr! The subject 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 one company.
')
The reasoning of the reasoning was a popular article by Mark Russinovich (also available in Russian ), which is often incorrectly interpreted (judging by the comments and “answer articles”), which leads to unpleasant consequences. Welcome under cat.
First of all, it is important to distinguish 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” to the base to the end. The base SID can be viewed 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 the addition of a RID at the end. For example:
It is the SIDs (and not the names) that are stored in access tokens and security descriptors, and it is the SIDs that are used when checking accessibility to Windows objects (including files, for example).
On a machine outside the domain, the local SIDs described above are used. Accordingly, when connecting to the machine, local authentication is remotely used, so even having 2 or more machines with the same machine SID in the same network outside the domain, there will be no problems with login and operation inside the system, since SIDs in remote authentication operations are simply not used. The only case in which problems are possible is the complete coincidence of the username and password on two machines - then, for example, the RDP between them can be buggy.
When a machine is added to a domain, a new SID comes into play, which is generated at the stage of adding. Machine SID does not go anywhere, just like 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 a machine as an entity within which groups and accounts are defined (the 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 the machine SID using the PsGetSid utility by running it without parameters. The second domain-related SID can be seen by 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 the DEMOSYSTEM machine, then it does not matter that another machine on the same network has the same machine SID, since This SID is used only locally (within the DEMOSYSTEM machine). But within the BIGDOMAIN computer SID domain, both machines must be unique for correct operation in this domain.
When applied to Acronis Snap Deploy 5 (the main purpose is the massive 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, mistakenly went about an established opinion that you need to change the SID.
However, based on the foregoing, there is nothing terrible in deploying (or cloning) a machine without changing the Machine SID, if this deployment occurs before adding the machine to the domain. Otherwise - there will be problems.
There is one exception to this rule: you cannot clone a machine if you plan to further promote the role of this clone to the domain level of the controller. In this case, the Machine SID domain of the controller will be the same as the computer SID in the created domain, which will cause problems when trying to add the original machine (from which the cloning was done) to this domain. This obviously only applies to the Windows server family.
To reconsider the point of view on the functionality of the SID change pushed us to release a new version of Windows. During the first test deployment of a Windows 10 image with a SID change on the resulting machine, it was discovered that the Start button stopped pressing (and this turned out to be only 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 the SIDs of local users (since the user's SID includes the machine SID including; see more 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 completely, which led to atragic death broken copy of Windows 10.
It was decided to remove this option in case we find Windows 10 (or Windows Server 2016) in the master image. The decision was made on the basis of the theoretical calculations described above plus, naturally, it was confirmed by practice when testing the recently released Acronis Snap Deploy 5 update in a variety of combinations: with and without renaming machines after deployment, adding to the domain and working group, deploying from master images taken from different states of the master machine (it was added to the domain or working group in different tests), etc.
Starting from Windows NT, the cloning (deployment) of the OS using only NewSID was never recommended by Microsoft itself. Instead, it is recommended to use the native Sysprep utility (see KB314828 ), which, in addition to changing the SID, also introduces 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 / deploying without using Sysprep can affect (read “most likely breaks”) the functionality of Windows Update, Network Load Balancing, MSDTC, Vista and above Key Manager Activation (KMS), which is tied 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 made as follows: to prepare the image of the machine for cloning / deployment, you should use sysprep in most 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
- Myth about duplicating the SID of the computer
- Sysprep, Machine SIDs and Other Myths
- The Machine SID Duplication Myth (and Why Sysprep Matters)
- you clone virtual machines - reasserting the 'myth'
- Why Sysprep is a necessary Windows deployment tool
Thanks for attention!
- What is SID and what types it is?
- When will having two or more machines with the same Machine SID cause problems? Or, in other words, when all the same (not) need to change the 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 one company.
')
The reasoning of the reasoning was a popular article by Mark Russinovich (also available in Russian ), which is often incorrectly interpreted (judging by the comments and “answer articles”), which leads to unpleasant consequences. Welcome under cat.
TL; DR
- Changing the SID of the machine in itself is meaningless and even harmful for modern OSs (an example of the consequences of changing the SID to Windows 10 below).
- To prepare the machine for image cloning / deployment, use sysprep.
- The SID of the machine will matter only if one of the cloned machines is promoted to the domain of the controller. So do not.
- You should not clone / deploy an image of a machine that has ALREADY been added to the domain; adding to the domain needs to be done after cloning / deployment.
What is the SID, its types and how does the Machine SID differ from the Domain SID?
Likbez
“ SID (Security Identifier), or Security Identifier - This is a variable-length data structure that identifies a user account, group, domain, or computer (in Windows based on NT technology (NT4, 2000, XP, 2003, Vista, 7.8) ). SID is assigned to each account at the time of its creation. The system operates with account SIDs, not their names. Only SIDs are also involved in controlling user access to protected objects (files, registry keys, etc.). "
First of all, it is important to distinguish 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” to the base to the end. The base SID can be viewed 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 the addition of a RID 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 the SIDs (and not the names) that are stored in access tokens and security descriptors, and it is the SIDs that are used when checking accessibility to Windows objects (including files, for example).
On a machine outside the domain, the local SIDs described above are used. Accordingly, when connecting to the machine, local authentication is remotely used, so even having 2 or more machines with the same machine SID in the same network outside the domain, there will be no problems with login and operation inside the system, since SIDs in remote authentication operations are simply not used. The only case in which problems are possible is the complete coincidence of the username and password on two machines - then, for example, the RDP between them can be buggy.
When a machine is added to a domain, a new SID comes into play, which is generated at the stage of adding. Machine SID does not go anywhere, just like local groups and users. This new SID is used to represent the machine account within the domain. For example:
| Domain SID for BIGDOMAIN domain | S-1-5-21-124525095-708259637-1543119021 |
| BIGDOMAIN \ DEMOSYSTEM $ (computer account (computer account)) | S-1-5-21-124525095-708259637-1543119021-937822 |
| BIGDOMAIN \ JOHNSMITH (user account (user account)) | S-1-5-21-124525095-708259637-1543119021-20937 |
Thus, the DEMOSYSTEM machine now has two independent SIDs:
• Machine SID, which defines a machine as an entity within which groups and accounts are defined (the 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 the machine SID using the PsGetSid utility by running it without parameters. The second domain-related SID can be seen by running PsGetSid with the following parameters:
psgetsid %COMPUTERNAME%$ . Accordingly, for the example from the tables, this 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 the DEMOSYSTEM machine, then it does not matter that another machine on the same network has the same machine SID, since This SID is used only locally (within the DEMOSYSTEM machine). But within the BIGDOMAIN computer SID domain, both machines must be unique for correct operation in this domain.
SID change during cloning or deployment
When applied to Acronis Snap Deploy 5 (the main purpose is the massive 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, mistakenly went about an established opinion that you need to change the SID.
However, based on the foregoing, there is nothing terrible in deploying (or cloning) a machine without changing the Machine SID, if this deployment occurs before adding the machine to the domain. Otherwise - there will be problems.
There is one exception to this rule: you cannot clone a machine if you plan to further promote the role of this clone to the domain level of the controller. In this case, the Machine SID domain of the controller will be the same as the computer SID in the created domain, which will cause problems when trying to add the original machine (from which the cloning was done) to this domain. This obviously only applies to the Windows server family.
SID Change Issues
To reconsider the point of view on the functionality of the SID change pushed us to release a new version of Windows. During the first test deployment of a Windows 10 image with a SID change on the resulting machine, it was discovered that the Start button stopped pressing (and this turned out to be only 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 the SIDs of local users (since the user's SID includes the machine SID including; see more 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 completely, which led to a
It was decided to remove this option in case we find Windows 10 (or Windows Server 2016) in the master image. The decision was made on the basis of the theoretical calculations described above plus, naturally, it was confirmed by practice when testing the recently released Acronis Snap Deploy 5 update in a variety of combinations: with and without renaming machines after deployment, adding to the domain and working group, deploying from master images taken from different states of the master machine (it was added to the domain or working group in different tests), etc.
Using Sysprep
Starting from Windows NT, the cloning (deployment) of the OS using only NewSID was never recommended by Microsoft itself. Instead, it is recommended to use the native Sysprep utility (see KB314828 ), which, in addition to changing the SID, also introduces 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:
- Removed car name
- The machine is derived from the domain: this is necessary for the subsequent successful addition to the domain with a new name
- Removed plug-and-play drivers, which reduces the risk of compatibility problems on the new hardware
- Optionally, remove Windows Event Logs ('reseal' parameter)
- Removed restore points
- The local administrator profile is deleted and this account is disabled.
- The target machine is loaded into audit mode , allowing you to install additional applications and drivers.
- A mini-setup launch is provided at the first launch to change the name of the machine and other additional configuration.
- Windows activation period is reset (reset is possible up to 3 times)
Thus, cloning / deploying without using Sysprep can affect (read “most likely breaks”) the functionality of Windows Update, Network Load Balancing, MSDTC, Vista and above Key Manager Activation (KMS), which is tied 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 made as follows: to prepare the image of the machine for cloning / deployment, you should use sysprep in most 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
- Myth about duplicating the SID of the computer
- Sysprep, Machine SIDs and Other Myths
- The Machine SID Duplication Myth (and Why Sysprep Matters)
- you clone virtual machines - reasserting the 'myth'
- Why Sysprep is a necessary Windows deployment tool
Thanks for attention!
Source: https://habr.com/ru/post/273793/
All Articles