A SID is a bit identifier, unique for every workstation and user; it forms the basis of NT security. A workstation SID is created during the NT setup process; the setup program simply produces an identifier, which, due to the comparatively large number of bits, has a good statistical chance of being unique.
When a user account is added to the workstation, this is created by appending a RID relative identifier to the workstation SID; the RID is simply a number that increments by one for every user.
For example, if the workstation account SID is:. The most likely scenario in which you might want to change a SID is when a set of machines have been deployed with some sort of disk-image cloning system.
This would create a situation in which multiple workstations shared a common SID, which can be problematic as anyone with access to resources on one machine would suddenly have access to all. Even if you delete all user accounts and then create new ones, the new user SIDs will be the same on every machine. The reason for this is simple: all workstations will have the same computer SID because this is created when the OS is installed and clearly not recreated during a disk-imaging process ; as RID generation is not machine specific normal user RIDs start at and are incremented by 1 each time a new user SID is needed , users on different cloned workstations will have the same SID.
While it is certainly true that workstation security goes out the window if different users on different machines share common SIDs, the problem disappears altogether in a domain environment.
If user accounts reside on a domain controller instead of on a workstation, then they will be created from the Primary Domain Controller PDC 's SID, and the workstation becomes irrelevant. To be sure, every machine will have the same local administrator and guest SIDs, but this really should not matter a jot.
After all, if you are the administrator of a whole set of machines that share a common SID, then you want to have administrative rights on all the machines, so having the same SID on each one is perfectly sensible and logical.
As far as the local guest account on each workstation is concerned, if you are worried enough about security even to know what a SID is, then you will have disabled this account long ago! There are occasionally other situations in which changing a SID might be considered a good idea, such as a gross security breach on your network, a paranoid employer, and so forth.
The bad news is that changing a SID is far from being a trivial issue: SIDs are littered all over the registry, and they are associated with the access control lists for all files and objects. The good news is that there are programs available that will whirl through your computer, changing every occurrence of the computer SID with a brand new one.
Here we discuss only one of these programs, NewSID. As is their wont, their program is:. Running NewSID is incredibly easy. To start it in interactive mode, simply type newsid at the command prompt. A small dialog box is displayed, with four buttons labeled as follows:.
This includes scouring the Security and SAM Security Account Manager registry hives, the registry key access control lists, and the access control lists associated with all files in an NTFS filing system. Synchronize SID provides an alternative method of generating the new SID to be applied: rather than creating one randomly, synchronization allows a SID to be taken from another machine.
This would be useful if you were configuring a backup domain controller, as such a beast must have its SID provided by the Primary Controller for the domain. The cancel option is self-explanatory. As we have mentioned repeatedly throughout this book, GUIs are not very good in a scripting environment; NewSID can be run noninteractively. While we have found NewSID to be a very reliable program, we would not recommend using any such product unless absolutely necessary. There is one simple reason for this: SID changers take quite a substantial time to run several minutes ; we dread to think what might happen if, say, there was a power cut while metamorphosis was in midflow.
We suspect that the chances of being able to salvage your workstation without a total OS reinstall are virtually zero! If your network relies on the NT domain model for security, there is one final problem that may emerge in any situation involving reidentification of workstations, whether reidentification is taking place during workstation deployment or if the extent of reconfiguration is limited to a mere name change.
The problem will occur whether configuration is being carried out manually or automatically: every workstation is likely to lose access to its NT domain. When a workstation first joins a domain, a secure tunnel is created between the workstation and a Primary Domain Controller; this is an encrypted connection between the two machines over which the NetLogon service the service responsible for network logons can communicate privileged information safely.
In order to use this secure tunnel, a workstation must supply a password to the PDC, a password that is generated when the workstation first joins the domain and that is stored in an encrypted part of the registry the Local Security Authority, or LSA. This security information is specific to every workstation, identifiable by name ; therefore, changing a computer name can render it unable to log on to a domain.
If a renaming procedure is carried out manually, none of this is an issue. The facility for joining a domain thereby recreating a secure tunnel presents itself on the very same tab of the Network Control Panel as does the facility for changing the computer name in the first place.
When changing a name, it is a trivial matter for a domain administrator to recreate a domain account as part of the same procedure. Unfortunately, life is not so simple for a script: as creation of a domain account and the joining of a domain using that account involves interaction between a workstation and a PDC, no amount of registry tweaking or local configuration will allow this to be achieved.
Short of programming the API directly, the only way to automate the process of joining a domain is to use a command-line utility. When looking for a solution to a problem such as this, the first port of call is normally the extremely useful net. As has been noted previously, this program contains all sorts of features for controlling Microsoft networking. Unfortunately not. The first limitation is that this command can be run only from a server. The second is that even if a server is at hand, creating an account for the computer is not the end of the story; getting a workstation actually to join a domain i.
Thankfully, there is a solution. Although Netdom seems to be a good program, and it has a very sensibly designed command-line frontend, the requirement to use it does not please us. The reason is that it seems mildly perverse that something so central to Windows NT's network security model as the ability to join a domain cannot be scripted without the use of a utility that has to be purchased as a supplement to a server resource kit.
Having said this, the utility does exist, so we will now turn to describing how it can be put to use. A variety of tasks can be carried out with Netdom. Here we are concerned with only one of its incantations, the one that allows a workstation to join a domain. The syntax for this incantation is as follows:. The first parameters here allow specification of a domain and a set of credentials of a user running the command.
In this context, the user specified must have the rights to add computers to the domain. The declaration member specifies that the arguments that will follow relate to the part of the program that deals with altering the relationship between domain members and their controllers; this syntax is similar in style to that of net.
The final two arguments specify the name of the computer and that the action that should be performed is joining a domain.
Invoking the preceding command on a workstation will carry out the following actions:. Incorporating a call to Netdom in a configuration script will ensure that after a reboot each renamed workstation will be able to connect nonproblematically to its domain controller.
In Chapter 2 , we discussed the security implications of credential information i. Everything we noted there applies even more so when applied to scripting Netdom , as such a script will contain credentials of a user with certain domain-administrative privileges. Ensure that the script cannot be read by nonadministrative users and preferably that it deletes itself after application. Finally, do not use a domain admin account, just in case someone does find your script.
The only domain-level privilege that Netdom needs is the ability to add a computer to a domain; create a special account with only this privilege and use this in your scripts. This issue is discussed further in the next chapter. We started this chapter by explaining how to retrieve workstation identity from a lookup file based on a MAC address.
We then introduced the various parameters that need to be configured in order to change the identity of an NT workstation and explained how to change them. This was followed with a brief look at SIDs, explaining why, when, and how to change them. Finally, we discussed the issues associated with changing computer identities in a domain environment.
The chapter has shown how to automate a procedure that would take substantial administrative time to accomplish if undertaken manually. In so doing, it has brought together many of the techniques introduced in previous chapters and shown how they can be used to carry out drastic configuration tasks with relative ease.
In the process of running, the types of scripts we have discussed in both this and previous chapters may carry out all sorts of maintenance and configuration tasks, but they can also leave workstations in unstable states. For example, automatic log ins may be set, or networking may be disabled. In the next chapter, we discuss how to ensure that configuration scripts run reliably as anticipated and remove themselves gracefully from a workstation, so that when they have finished their tasks, they leave no unhappy side effects.
In Chapter 9 , A Custom Module , a much more sophisticated variation on the address. This allows a huge number of parameters to be configured on a machine-specific basis. However, Microsoft seems to have ignored this, so so do we. Skip to main content. Start your free trial. Three such situations immediately spring to mind: You are deploying a set of workstations for the first time and the operating system has been installed automatically using an unattended installation script.
As the same script has been run on all the workstations in question, all will share a common identity. A variation on this theme would be to have prepared the workstations with some sort of disk-imaging technique.
Clearly, each machine will need its own identity before it can be released onto a network. In Windows 7, the process is a bit different.
Here, you will see an overview of your network connection. This will not work on the Home, Student or Starter editions of Windows. Type in secpol. Then click on Network List Manager Policies at the left and on the right-hand side you should see a couple of items with descriptions and then something called Network , which is the current network you are connected to.
If you are connected to a WiFi network, it will be the name of your WiFi network. Double-click on it and click on the Network Location tab.
Here you can manually change the network location from Private to Public and vice versa. Founder of Online Tech Tips and managing editor. He began blogging in and quit his job in to blog full-time. He has over 15 years of industry experience in IT and holds several technical certifications. Read Aseem's Full Bio. Your email address will not be published. We hate spam too, unsubscribe at any time. Change from Public to Private Network in Windows 7, 8 and 10 Make some tweaks to ensure you are not sharing too much or too little.
HI, if I want to use this as a solution in my setup I have to run this script on every laptop that we connect to the PC? I had hoped that the PC, which is the fixed part of this setup and will never change, can send out a network identification of some sort so that it becomes a Identified network.. Because the laptop in my setup can change and we do not allways have the possibility to run a script on there. I did already find the solotion in the GroupPolicy editor to set unidentified networks to private, and your script might be a similar solution.
But i was hoping on a more permanent solution. Office Office Exchange Server. Not an IT pro? Windows Client. Sign in. United States English.
0コメント