View Full Version : SID in XP
Esbat
08-26-2004, 05:23 PM
Anyone know of a utility that can change the SID in XP? I used to use GetSid and a change SID utility under NT to ghost machines without making the SMS group unhappy, and I'd like to continue that trend.
Dartaignon
08-27-2004, 10:12 AM
You should use sysprep on the computers before you send the image to where you are going to be distributing it from. We use RIS to launch a bootp file that loads Powerquest delta deply. Every time I make a new image for our PC's, I use the tool available here.
http://www.microsoft.com/windows2000/downloads/tools/sysprep/default.asp
After you sysprep, it will let you name the machine, and then join it into your Domain if you have one.
Palimax Sceleris
08-27-2004, 04:37 PM
Well, there's some reasons to use Sysprep, and there's some reasons not to, but lets pretend, for some reason you don't want to. Your answer, as always, is from our good friend Mark Russinovich over at Sysinternals:
http://www.sysinternals.com/ntw2k/source/newsid.shtml
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 Windows NT 4, Windows 2000, Windows XP and Windows .NET Server.
Changing SIDs is only *somewhat* productive. You could have 10,000 machines with the same SID and probably never notice. The most interesting consequences of duplicate SIDs only pretty much happen when you have machines in workgroup settings where they have local accounts, and have the potential for overlap, as <yourmachine>\%first_account% has the same RID/SID combo as <mymachine>\%first_account% [as long as we share the same SID]. This, in and of itself isn't much of a problem unless, say, you have removable NTFS media with permissions that prohibit me from seeing it. In a domain environment, where with the exception of the local administrative account (and a smattering of service accounts) there aren't many (any) local accounts to worry about the possiblity for overlap. And since you'd have to do something like that a removable hard-drive from a duplicate SID machine to another machine to see the problem actually have an impact.
From the Sysinternals site:
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.
Anyway, unique SIDs is good form. I recommend them, but you'll probably never see the consequences of not having them.
If you haven't used NewSID in a while, give it another look. At the 4.x version level it got much nicer looking and "wizard" driven -- as well as still working from a command-line.
[And you wonder why I avoid the RAM debate threads...]
Esbat
08-30-2004, 04:27 PM
Thanks, I'll check it out.
vBulletin® v3.8.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.