On Wed, 17 Jul 2024 21:46:35 +0200
Heiko Robert via samba <samba at lists.samba.org> wrote:
> >> The only additional output I get from running with debug
> >>
> >> samba-tool dbcheck --cross-ncs --fix -d 10
> >>
> >> is
> >>
> >> ndr_pull_dom_sid: ndr_pull_error(Range Error): value out of range
> >> at ../../librpc/ndr/ndr_sec_helper.c:329
>
> OK I think I'm at least a small step further.
>
> I realized that tdbbackup failed on
> 'DC=DOMAINDNSZONES,DC=COMPANY,DC=INTRA.ldb'
>
> trying to restore a tdbdump failed due to a duplicate key error. I
> removed that dup key row and finally was able to tdbrestore and then
> tdbbackup all databases.
>
> I created an domain offline backup via samba-tool and restored the
> domain to a new system.
>
> Trying to join a dc the restored domain now fails with
>
> DSDB Transaction [rollback] at [Wed, 17 Jul 2024 19:14:50.831149 UTC]
> duration [21734458]
> {"timestamp": "2024-07-17T19:14:50.831313+0000",
"type":
> "dsdbTransaction", "dsdbTransaction":
{"version": {"major": 1,
> "minor": 0}, "action": "rollback",
"transactionId":
> "cc9ca6f6-d507-42bb-bd21-b8b24ac4c3e2", "duration":
21734458}}
> Join failed - cleaning up
> ldb_wrap open of secrets.ldb
> Could not find machine account in secrets database: Failed to fetch
> machine account password for COMPANY from both secrets.ldb (Could not
> find entry to match filter:
> '(&(flatname=COMPANY)(objectclass=primaryDomain))' base:
'cn=Primary
> Domains': No such object: dsdb_search at
> source4/dsdb/common/util.c:5435) and from
> /var/lib/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
>
> dumping the secrets.tdp I can find
> key(30) = "SECRETS/MACHINE_PASSWORD/COMPANY"
>
> any hint is highly welcome
>
Anything after the 'Join failed' can be ignored, it is just an
artefact of the cleanup.
I posted this:
Do not remove the existing database, well not unless you want to
recreate your domain.
I will amend it:
Do not touch 'DC=DOMAINDNSZONES,DC=COMPANY,DC=INTRA.ldb' (or any of the
other files in the same directory) directly, do all changes through
sam.ldb, otherwise you have a very good risk of further damaging your
database.
Rowland