[Samba] Classic Upgrade changes domain SID - solved

[Peter Koch]

Hi everybody,

this is just to inform anybody who tries to migrate a
samba3 NT4-DC on a server with some endianness
to a samba4 AD-DC on a different machine with
different endianness: Everything works well if
one reverses the byte ordering of the domain SID
in secrets.tdb before starting the classic upgrade.

I did this with the following php one-liner

php -r 
'file_put_contents("secrets.tdb",hex2bin(str_replace("00000015545bfad592ac2583a49aeb0a","15000000d5fa5b548325ac920aeb9aa4",bin2hex(file_get_contents("secrets.tdb")))));'

because I'm doing the complete migration with one
shell-script. You may use a hexeditor as well.

Changing the domain SID after having done the classic
upgrade with  net setdomainsid  did not work.

The informations in all other tdb-files are not
influenced by the endianness of the server.

Thanks very much to Andrew and Rowland. You are doing
a great job on this mailing list.

Kind regards

Peter

On 29.08.2023 at 02:31 Andrew Bartlett wrote:
> On Mon, 2023-08-28 at 23:46 +0200, Peter Koch via samba wrote:
>> Hi Andrew and Roland, I spent some hours today to debug the problem 
>> by adding lots of printf-statements into the samba4 source. Here are 
>> my findings: - upgrade.py calls passdb.get_global_sam_sid() - 
>> get_global_sam_sid() calls pdb_generate_sam_sid() - 
>> pdb_generate_sam_sid() calls secrets_fetch_domain_sid() - 
>> secrets_fetch_domain_sid() calls secrets_fetch() - secrets_fetch() 
>> calls dbwrap_fetch() - dbwrap_fetch() reads the correct file and 
>> returns exactly the binary string that tdbdump displays At this point 
>> I was really astonished: Everything works as expected but the 
>> resulting domain SID nevertheless is wrong. And then I realized the 
>> reason: My old secrets.tdb file contains the following SID-data: 
>> 01040000:00000005:00000015:545BFAD5:92AC2583:A49AEB0A 0x00000015=21, 
>> 0x545BFAD5=1415314133 0x15000000=352321536, 0xD5FA5B54=3589954388 My 
>> old samba3-server is a Sun Sparc machine with MSB byte order while my 
>> new samba4-server is an Intel machine with LSB byte order. 
>> S-1-5-21-1415314133-2460755331-2761616138 and 
>> S-1-5-352321536-3589954388-2200284306-183212708 are the same SIDs, 
>> just the byte ordering of the last 4 numbers was reversed. 
> Interesting. I had assumed (not reading closely enough) that you were 
> running the commands on the same server. Presumably the 'wrong' side 
> was what did 'net getdomainsid' showed when run on the new server?
>> Now my concern is that not only secrets.tdb contains machine 
>> dependent data, but other tdb-files do as well. 
> The main passdb.tdb is packed with tdb_pack(), so should be safer. The 
> upgrade also upgrades the group mapping, but that is the same. 
> Thankfully most of the rest of secrets.tdb we just ignore, as there is 
> a lot of direct memory copies in that handler.
>> I will fix the secrets.tdb file with a hex-editor and let you know 
>> what happens. 
> You can also force the SID on the new server with 'net setdomainsid'. 
> All the best with the upgrade! Andrew Bartlett