(α)- Sysprep, Windows 2008 File Servers, & SMBClient
I have been teaching students the basics of cyber security for some time now, and have never run into a problem with sysprep- until now.
Each windows system has its own Machine SID. An SID is a Security Identifier, and Microsoft systems have them for users, groups, computers, and other security principals. You can see the SIDs for the users on a system from the command prompt with the aid of
wmic. Here is what results if you run
wmic on a domain member
C:\Users\riose>wmic useraccount get name,sid Name SID Administrator S-1-5-21-2551796448-4277757654-932718426-500 Guest S-1-5-21-2551796448-4277757654-932718426-501 seldon S-1-5-21-2551796448-4277757654-932718426-1001 Administrator S-1-5-21-3777769887-227576269-3891321149-500 Guest S-1-5-21-3777769887-227576269-3891321149-501 krbtgt S-1-5-21-3777769887-227576269-3891321149-502 seldon S-1-5-21-3777769887-227576269-3891321149-1001 Hardin S-1-5-21-3777769887-227576269-3891321149-1108 riose S-1-5-21-3777769887-227576269-3891321149-1110 sales S-1-5-21-3777769887-227576269-3891321149-1111 production S-1-5-21-3777769887-227576269-3891321149-1112 salesadmin S-1-5-21-3777769887-227576269-3891321149-1113
You can see both local accounts (Administrator, Guest, seldon), and domain accounts (Administrator, Guest, krbtgt, …) listed here. The SID is the number that begins S-1-5-21.
You can also find the SID of a computer, but in this case we need an extra tool, the PSGetSid.exe tool from the Sysinternals PSTools suite. Running it on the domain member, we find
C:\Users\riose\Desktop\PSTools>PsGetsid.exe PsGetSid v1.44 - Translates SIDs to names and vice versa Copyright (C) 1999-2008 Mark Russinovich Sysinternals - www.sysinternals.com SID for \\DANEEL: S-1-5-21-2551796448-4277757654-932718426
while if we run the same tool on the domain controller, we get
C:\Users\seldon\Desktop\PSTools>PsGetsid.exe PsGetSid v1.44 - Translates SIDs to names and vice versa Copyright (C) 1999-2008 Mark Russinovich Sysinternals - www.sysinternals.com SID for \\GISKARD: S-1-5-21-3777769887-227576269-3891321149
With this, it is easy now to interpret the results from
wmic; the SID is just the SID of the system followed by a relative ID; administrator accounts have the relative ID of 500 (which is why renaming administrator accounts provides less security than might be imagined), the guest account has relative ID 501, and subsequent accounts start at 1000 and go up from there.
Duplicate Machine SIDs?
To help the students in class, I have provided in our (isolated) lab a base VMWare image of a base install for the various systems used in the course, including the various Windows operating system. Now these are all copies of one another, which means that they have the same Machine SID. In olden days, this might have been a problem, but it should not be, at least for systems after Windows Vista.
In fact, there used to be a SysInternals tool to update a systems Machine SID, but that has long since been discontinued. The author, Mark Russinovich, back in 2009 wrote on his blog "… I became convinced that machine SID duplication – having multiple computers with the same machine SID – doesn’t pose any problem, security or otherwise."
With that as background, I have been happily using duplicate systems in our isolated labs for some time now, without problems…..
We have a domain class.tu with domain controller giskard.class.tu at 10.0.2.200 providing Active Directory and DNS.
We also set up a pair of File servers. The first, baley.class.tu is at 10.0.2.205 has the share
\\baley\CommonData and has the same Machine SID as our domain controller. The second, baley2.class.tu is at 10.0.2.206 and has the share
\\baley\CommonData. Baley and Baley2 are configured identically, other than the name, IP address, and the fact that the Machine SID for Baley2 was regenerated via Sysprep before the system was configured.
Let’s try to use the command line tool
smbclient to connect to these shares. We will make the connection from the system trantor.cosc.tu; this is a Linux system (CentOS 6.2) and is not a domain member. The trantor system is running its own DNS (BIND), but is forwarding the class.tu domain over to our friend, the domain controller giskard.class.tu.
Here is what happens if you try smbclient on the system with the same Machine SID as the domain controller:
[root@trantor ~]# smbclient \\\\baley.class.tu\\CommonData -U seldon -W class.tu Enter seldon's password: session setup failed: NT_STATUS_LOGON_FAILURE
On the other hand, if we try the system with the regenerated Machine SID:
[root@trantor ~]# smbclient \\\\baley2.class.tu\\CommonData -U seldon -W class.tu Enter seldon's password: Domain=[CLASS] OS=[Windows Server 2008 R2 Datacenter 7600] Server=[Windows Server 2008 R2 Datacenter 6.1] smb: \> ls . D 0 Sun Feb 24 13:07:30 2013 .. D 0 Sun Feb 24 13:07:30 2013 Test File.txt A 20 Sun Feb 24 13:07:36 2013 40957 blocks of size 1048576. 33109 blocks available smb: \> get "Test File.txt" getting file \Test File.txt of size 20 as Test File.txt (6.5 KiloBytes/sec) (average 6.5 KiloBytes/sec) smb: \>
For the record, don’t even ask how long it took me to figure this problem out! I spent ages trying to see what was wrong with the
smbclient request on Baley.
I was not familiar with a 4625 error, so I did some digging, and it turns out that someone on TechNet had a similar problem. They tracked the issue down to the Machine SID, so I re-set the machine SID, and found success.
I guess this means that Mark Russinovich’s comment that duplicate Machine SID’s won’t cause a problem is only 99.99% correct.
There is another place where the duplicate Machine SID causes problems. In the week 5 notes, I showed students how to set up a Windows file server.
When I did the demonstration on how to map a drive letter (Z:) to individual user’s file shares, my example proceeded without any issues. The catch though, was that I was using the "Administrator" account when I did so. If you follow the same steps with a different account- say seldon, then the process fails.
Why? Good question. Unlike the previous problem, I did not see any trace information in the security logs. However, if you run sysprep on your file server before setting it up, then there are no problems, regardless of the user that you use.
I mean I checked it with a couple of users, but who knows? Maybe I missed something else.
OK- we have seen how the solution to a couple of Windows 2008 server problems is to run Sysprep. How do we do so?
It is simple enough to do, but you must do it before you configure your system; in fact it should be the first thing that you do.
c:\Windows\System32\Sysprep and run the program
Sysprep. Be sure to check the Generalize box.
Let the program run; it will reboot the system. Once it re-boots you can begin the process of configuring your system as you see fit.