(α)- 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.

Background

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…..

Until now….

The Problem

Let’s set up a Windows network like we did in Notes 3 and 5.

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.

The key to discovering the problem was in the logs. If you visit the Security logs on Baley, you see the following error.

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.

More Problems

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.

Probably.

I mean I checked it with a couple of users, but who knows? Maybe I missed something else.

Sysprep

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.

Navigate to 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.