[NTSID Logo] Copyright © 1997 Mark Russinovich and Bryce Cogswell Last Updated November 24, 1997 NTSID 1.0 Introduction Many organizations use disk image cloning to perform mass rollouts of Windows NT. This technique involves copying the disks of a fully installed and configured Windows NT computer onto the disk drives of other computers. These other computers effectively appear to have been through the same install process, and are immediately available for use. 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 Microsoft has stated that Windows NT 5.0 Active Directory security will also be compromised in networks with multiple identical computer SIDs. Demand from the NT community has lead PowerQuest and Ghost Software 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. NTSID is a program we developed that changes a computer's SID. It is a free, comes with full source, and is a Win32 program, meaning that it can easily be run on systems that have been previously cloned. Please read this entire article before you use this program. Cloning and One of the most popular ways of performing mass Alternate Windows NT rollouts (typically hundreds of computers) Rollout Methods in corporate environments is based on the technique of disk cloning. A system administrator installs the base operating system and add-on software used in the company on a template computer. After configuring the machine for operation in the company network, automated disk or system duplication tools (such as NetVersant's ImageCast, Ghost Software's Ghost, or PowerQuest's Image Drive) are used to copy the template computer's drives onto tens or hundreds of computers. These clones are then given final tweaks, such as the assignment of unique names, and then used by company employees. 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. The SID The problem with cloning is that it is only supported Duplication by Microsoft in a very limited sense. Microsoft has Problem stated that cloning systems is only supported if it is done before the GUI portion of Windows NT Setup has been reached. When the NT install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. To understand the problem that this 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. Microsoft has also stated that NT 5.0's Active Directory, which replaces NT 4.0 Domains, will rely on computer SIDs for its security. Microsoft has not made clear exactly what the dependence will be, but its clear that cloned NT 4.0 computers that are upgraded to NT 5.0 will almost certainly cause security problems if they share SIDs with other computers in the Active Directory. NTSID NTSID is a program we developed to change a computer's SID. It first generates a random SID for the computer, and proceeds to update instances of the existing computer SID it finds in the Registry and in file security descriptors, replacing occurrences with the new SID. NTSID works on NT 4.0, (it should work on NT 3.51 as well, but has not been tested on it) and requires administrative privileges to run. Note that while we have thoroughly tested NTSID, 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 NTSID. It is not anticipated that changing a computer SID will cause problems when upgrading to NT 5.0's Active Directory, but we take no responsibility if it does. How it Works NTSID starts by reading the existing computer SID. A computer's SID is stored in the Registry's SECURITY hive under SECURITY\SAM\Domains\Account. This key has a value named F and a value named V. The V value is a binary value that has the computer SID embedded within it at the end of its data. NTSID ensures that this SID is in a standard NT 4.0 format (3 32-bit subauthorities preceded by three 32-bit authority fields). Next, NTSID generates a new random SID for the computer. NTSID'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 NTSID finds one, it replaces it with the new computer SID. The second part of security descriptor updates is performed on the Registry. First, NTSID 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. NTSID 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 NTSID unloads the user hives it loaded. As a final step NTSID 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 NTSID is loading other user hives. Finally, NTSID 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. NTSID 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. Using the Source Full source code to NTSID has been provided for educational purposes. You may not use this code in a commercial SID-changing product, but you may use its techniques in other programs for private or commercial use. ------------------------------------------------------------------------ Download NTSID (28KB) Download NTSID Plus Source (78KB)