[Samba] Unable to "rejoin" existing DC after upgrade (infamous WERR_FILE_NOT_FOUND)

[Rowland Penny]

On 08/03/2023 11:07, Lorenzo Milesi via samba wrote:
> Hi.
> As happened some weeks ago, here I am again updating an old Samba 4.14.x network to a current version. The server hosting the FSMO roles is a Debian10 with 4.14.14, while the third node is a Ubuntu 18 running LinuxSchools build 4.14.8.
> 
> We started from a Ubuntu 20.04 server running Louis builds. We demoted the node and joined it back to the domain with 4.17.5 from Michael. Although on the node itself everything seemed ok, the DC didn't appear in DNS, while visible in Sites and ADUC.
> Replication is reported as ALL GOOD on the upgraded node, but the remote ones are in error with WERR_FILE_NOT_FOUND.
> 
> We enabled drs_repl log on the 4.14.8, pasting below.
> It seems failing because it cannot find the DNS records, which it cannot have because replication is not working. If I run
> dig 3fa4ff9a-7fdc-4912-ad73-08b98f6bf347._msdcs.domain.lan @zimbraip
> it returns the correct value, while the same command against any of the two other DCs fails. But maybe this is not the root cause of the problem.
> 
> samba_dnsupdate ran without errors on the 4.17 node, but the other DCs never received those DNS records.
> 
> What else can we check?
> thanks
> 
> 
> # conf on 4.14.8
> [global]
>          netbios name = ZIMBRA
>          realm = DOMAIN.LAN
>          server role = active directory domain controller
>          workgroup = DOM
>          server services = -dns
>          allow dns updates = disabled
>          interfaces = tun0 lo
>          log level = 1 drs_repl:10
> 
> [sysvol]
>          path = /var/lib/samba/sysvol
>          read only = No
> 
> [netlogon]
>          path = /var/lib/samba/sysvol/domain.lan/scripts
>          read only = No
> 
> # conf on newly upgraded 4.17.5
> [global]
>          interfaces = tun0 lo
>          netbios name = NEXTCLOUD
>          realm = DOMAIN.LAN
>          server role = active directory domain controller
>          workgroup = DOM
> 
>          log level = 1 drs_repl:10
> [sysvol]
>          path = /var/lib/samba/sysvol
>          read only = No
> 
> [netlogon]
>          path = /var/lib/samba/sysvol/domain.lan/scripts
>          read only = No
> 
> # log excerpt from 4.14.8 - zimbra node
> [2023/03/08 11:53:48.764405, 10, pid=4709, effective(0, 0), real(0, 0), class=drs_repl] ../../source4/dsdb/repl/drepl_notify.c:391(dreplsrv_notify_check)
>    dreplsrv_notify_check: queued DsReplicaSync for DC=domain,DC=lan to 3fa4ff9a-7fdc-4912-ad73-08b98f6bf347._msdcs.domain.lan (urgent=true) uSN=0:27662

It looks like it is trying to replicate to the GUID representation of a 
DC, if you check the DC objects you should find SPN's like this:

servicePrincipalName: 
ldap/3fa4ff9a-7fdc-4912-ad73-08b98f6bf347._msdcs.domain.lan

Each DC should have a similar SPN, but with a different GUID and the 
GUID will probably be a part of other SPN's in each DC object.

Do any of your current DC's use that GUID 
(3fa4ff9a-7fdc-4912-ad73-08b98f6bf347) ?

Rowland