samba - Aug 2023 - Classic Upgrade changes domain SID

On Mon, 28 Aug 2023 11:33:04 +0200
Peter Koch via samba <samba at lists.samba.org> wrote:
> Hi Andrew, Hi Roland
> 
> Current status of my problem:
> 
> - Domain SID of my old samba 3.6.14 NT4-DC is:
> S-1-5-21-1415314133-2460755331-2761616138
> - I confirmed that this SID is contained in
>  ? secrets.tdb (by running tdbdump on the samba3 server)
> - the correct secrets.tdb file was transfered to
>  ? the new server.
> - upgrade script does open the correct secrets.tdb
>  ? file (checked with strace-output)
> - upgrade.py calls passdb.get_global_sam_sid() in
>  ? line 494 and this call returns a different SID, namely
> S-1-5-352321536-3589954388-2200284306-183212708
> - This is not a randomly generated SID as upgrade.py
>  ? uses this SID on every invocation. It must be stored
>  ? somewhere.
> - There's no LDAP involved. Our samba3 server uses
>  ? the passdb backend and the samba4-LDAP is not
>  ? yet running while upgrade.py does NT4-AD-migration.
> 
> I will debug get_global_sam_sid() ASAP to find out
> how the wrong? domain SID ist determined. So far
> I'm clueless.
> 
> I would like to try a very quick and dirty hack, namely
> replace lines 491-495 of upgrade.py:
> 
>  ??? # Get domain sid
>  ??? try:
>  ??????? domainsid = passdb.get_global_sam_sid()
>  ??? except passdb.error:
>  ??????? raise Exception("Can't find domain sid for '%s',
Exiting." %
> domainname)
> 
> by:
> 
>  ??? # Get domain sid
>  ??? try:
>  ??????? domainsid = passdb.get_global_sam_sid()
>  ??????? domainsid = "S-1-5-21-1415314133-2460755331-2761616138"
>  ??? except passdb.error:
>  ??????? raise Exception("Can't find domain sid for '%s',
Exiting." %
> domainname)
> 
> Of course this does not work as domainsid must be a
> variable of type dom_sid and the above changes domainsid
> into a string.
> 
> Unfortunately I know nothing about Phython. How would I store
> the correct SID-value in variable domainsid in Python-syntax?
> 
> Peter
> 
Hi Peter, I am trying to understand just what is going wrong here and
why you are getting the wrong SID.
It might help if I knew what OS you where running, as it looks like
some variant of red-hat but the pid seems to stored in /var/samba/run
instead of /var/run/samba.
Also the 'samba' daemon is unlikely to be running until you start it,
but the 'nmbd', 'smbd' and 'winbind' daemons could be,
depending on
whether or not your distro starts them after install.

It looks like, for what ever reason, the wrong database is being read.

Rowland

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.

Now my concern is that not only secrets.tdb contains
machine dependent data, but other tdb-files do as well.

I will fix the secrets.tdb file with a hex-editor and let
you know what happens.

Peter