While this method saves hours of work and hassle over other NT rollout approaches, it has the major problem that every cloned system has an identical Computer Security Identifier (SID). This fact compromises security in Windows NT Workgroup environments, and removable media security can also be compromised in networks with multiple identical computer SIDs.
Demand from the NT community has lead PowerQuest, Ghost Software and KeyLabs to develop programs that can change a computer's SID after a system has been cloned. However, PowerQuest's SID Changer and Ghost Software's Ghost Walker are only sold as part of each company's high-end product. Further, they both run from a DOS command prompt (KeyLab's changer is similar to NewSID).
NewSID is a program we developed that changes a computer's SID. It is free, comes with full source, and is a Win32 program, meaning that it can easily be run on systems that have been previously cloned. NewSID works on all versions of NT 4.0, including Service Pack 4. Please read this entire article before you use this program.
Version Information: Version 3.02 corrects a bug where NewSid would not correctly copy default values with invalid value types when renaming a key with an old SID to a new SID. NT actually makes use of such invalid values at certain times in the SAM. The symptom of this bug was error messages reporting access denied when account information was updated by an authorized user. Version 3.01 adds a work-around for an inaccessible Registry key that is created by Microsoft Transaction Server. Without the work-around NewSID would quit prematurely. Version 3.0 introduces a SID-sync feature that directs NewSID to obtain a SID to apply from another computer. Version 2.0 has an automated-mode option, and let's you change the computer name as well. Version 1.2 fixes a bug in that was introduced in 1.1 where some file system security descriptors were not updated. Version 1.1 corrects a relatively minor bug that affected only certain installations. It also has been updated to change SIDs associated with the permission settings of file and printer shares.
Another popular way of rolling out NT is by using the Microsoft sysdiff utility (part of the Windows NT Resource Kit). This tool requires that the system administrator perform a full NT install (usually a scripted unattended installation) on each computer, and then sysdiff automates the application of add-on software install images.
Because the NT-installation is skipped, and because disk sector copying is more efficient than file copying, a cloned-based rollout can save dozens of hours over a comparable sysdiff install. In addition, the system administrator does not have to learn how to use unattended NT install or sysdiff, or create and debug install scripts. This alone saves hours of work.
To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer's SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID.
Duplicate SIDs aren't an issue in a Domain-based NT environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.
Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs.
An article Mark has written, entitled "NT Rollout Options", was published in the June issue of Windows NT Magazine. It discusses the duplicate SID issue in more detail, and presents Microsoft's official stance on cloning.
To use NewSID's auto-run option, specify "/a" on the command line. You can also direct it to automatically change the computer's name by including the new name after the "/a" switch. For example:
newsid /a newname
Would have NewSID run without prompting, change the computer name to "newname" and have it reboot the computer if everything goes okay.
Version 3.0 introduces a SID-synchronizing feature that allows you to specify that, instead of randomly generating one, the new SID should be obtained from a different computer. This functionality makes it possible to move a Backup Domain Controller (BDC) to a new Domain, since a BDC's relationship to a Domain is identified by it having the same computer SID as the other Domain Controllers (DCs). Simply choose the "Synchronize SID" button and enter the target computer's name. You must have permissions to change the security settings of the target computer's Registry keys, which typically means that you must be logged in as a domain administrator to use this feature.
Note that when you run NewSID that the size of the Registry will grow, so make sure that the maximum Registry size will accomodate growth. We have found that this growth has no perceptible impact on system performace. The reason the Registry grows is that it becomes fragmented as temporary security settings are applied by NewSID. When the settings are removed the Registry is not compacted.
Note that while we have thoroughly tested NewSID, you must use it at your own risk. As with any software that changes file and Registry settings, it is highly recommended that you completely back-up your computer before running NewSID.
- Boot up the BDC you want to move and log in. Use NewSID to synchronize the SID of the BDC with the PDC of the domain to which you wish to move the BDC.
- Reboot the system for which you changed the SID (the BDC). Since the domain the BDC is now associated with already has an active PDC, it will boot as a BDC in its new domain.
- The BDC will show up as a workstation in Server Manager, so use the "Add to Domain" button to add the BDC to its new domain. Be sure to specify the BDC radio button when adding.
Next, NewSID generates a new random SID for the computer. NewSID's generation takes great pains to create a truly random 96-bit value, which replaces the 96-bits of the 3 subauthority values that make up a computer SID.
Three phases to the computer SID replacement follow. In the first phase, the SECURITY and SAM Registry hives are scanned for occurrences of the old computer SID in key values, as well as the names of the keys. When the SID is found in a value it is replaced with the new computer SID, and when the SID is found in a name, the key and its subkeys are copied to a new subkey that has the same name except with the new SID replacing the old.
The final two phases involve updating security descriptors. Registry keys and NTFS files have security associated with them. Security descriptors consist of an entry that identifies which account owns the resource, which group is the primary group owner, an optional list of entries that specify actions permitted by users or groups (known as the Discretionary Access Control List - DACL), and an optional list of entries that specify which actions performed by certain users or groups will generate entries in the system Event Log (System Access Control List - SACL). A user or a group is identified in these security descriptors with their SIDs, and as I stated earlier, local user accounts (other than the built-in accounts such as Administrator, Guest, and so on) have their SIDs made up of the computer SID plus a RID.
The first part of security descriptor updates occurs on all NTFS file system files on the computer. Every security descriptor is scanned for occurrences of the computer SID. When NewSID finds one, it replaces it with the new computer SID.
The second part of security descriptor updates is performed on the Registry. First, NewSID must make sure that it scans all hives, not just those that are loaded. Every user account has a Registry hive that is loaded as HKEY_CURRENT_USER when the user is logged in, but remains on disk in the user's profile directory when they are not. NewSID identifies the locations of all user hive locations by enumerating the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList key, which points at the directories in which they are stored. It then loads them into the Registry using RegLoadKey under HKEY_LOCAL_MACHINE and scans the entire Registry, examining each security descriptor in search of the old computer SID. Updates are performed the same as for files, and when its done NewSID unloads the user hives it loaded. As a final step NewSID scans the HKEY_USERS key, which contains the hive of the currently logged-in user as well as the .Default hive. This is necessary because a hive can't be loaded twice, so the logged-in user hive won't be loaded into HKEY_LOCAL_MACHINE when NewSID is loading other user hives.
Finally, NewSID must update the ProfileList subkeys to refer to the new account SIDs. This step is necessary to have Windows NT correctly associate profiles with the user accounts after the account SIDs are changed to reflect the new computer SID.
NewSID ensures that it can access and modify every file and Registry key in the system by giving itself the following privileges: System, Backup, Restore and Take Ownership.
Download NewSID (Intel -
28KB)
Download NewSID (Alpha -
59KB)
Download NewSID Plus Source
(131KB)
