[Samba] ODP: ODP: ODP: Demoting AD DC failed, now it won't start up after ldb and tdb files removed

Krzysztof Kucybała krzysieq at hotmail.com
Sat Apr 2 18:36:17 UTC 2022


Ah sorry, fiddled with some args from the samba wiki, I got this in the end (off the physical DC):

root at meraki:~# samba-tool ldapcmp ldap://primarydc ldap://meraki -UAdministrator domain
Password for [KUCYBALA\Administrator]:

* Comparing [DOMAIN] context...

* Objects to be compared: 302

* Result for [DOMAIN]: SUCCESS
________________________________
Od: Krzysztof Kucybała <krzysieq at hotmail.com>
Wysłane: sobota, 2 kwietnia 2022 20:32
Do: samba at lists.samba.org <samba at lists.samba.org>
DW: Rowland Penny <rpenny at samba.org>
Temat: ODP: [Samba] ODP: ODP: Demoting AD DC failed, now it won't start up after ldb and tdb files removed

So the dbcheck command comes up clean on the original, VM-based DC, but spits out a whole lot of errors (307 to be exact) on the physical one (the one that's been acting up, whose db should now be a pristine replica I would've thought). These are errors that look like this:

RROR: wrong instanceType 4 on CN=9738c400-7795-4d6e-b19d-c16cd6486166,CN=Operations,CN=DomainUpdates,CN=System,DC=***,DC=com, should be 0
Not changing instanceType from 4 to 0 on CN=9738c400-7795-4d6e-b19d-c16cd6486166,CN=Operations,CN=DomainUpdates,CN=System,DC=***,DC=com

but they concern many different db objects - user accounts, groups, computers...

I did not manage to get the other command to work on either DC, error is the same:
root at meraki:~# samba-tool ldapcmp primarydc meraki domain
ERROR(ldb): uncaught exception - LDAP error 1 LDAP_OPERATIONS_ERROR -  <00002020: Operation unavailable without authentication> <>
  File "/usr/lib/python3/dist-packages/samba/netcmd/__init__.py", line 186, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/samba/netcmd/ldapcmp.py", line 933, in run
    con1 = LDAPBase(URL1, creds, lp,
  File "/usr/lib/python3/dist-packages/samba/netcmd/ldapcmp.py", line 79, in __init__
    self.domain_netbios = self.find_netbios()
  File "/usr/lib/python3/dist-packages/samba/netcmd/ldapcmp.py", line 111, in find_netbios
    res = self.ldb.search(base="CN=Partitions,%s" % self.config_dn,

Thoughts?
Cheers,
Chris
________________________________
Od: samba <samba-bounces at lists.samba.org> w imieniu użytkownika Rowland Penny via samba <samba at lists.samba.org>
Wysłane: sobota, 2 kwietnia 2022 18:18
Do: samba at lists.samba.org <samba at lists.samba.org>
DW: Rowland Penny <rpenny at samba.org>
Temat: Re: [Samba] ODP: ODP: Demoting AD DC failed, now it won't start up after ldb and tdb files removed

On Sat, 2022-04-02 at 15:55 +0000, Krzysztof Kucybała via samba wrote:
> Thanks Rowland,
> Yea, I tried 'net cache flush' command now, and I tried that before I
> started fiddling with removing the tdb and ldb database files,
> doesn't seem to do much of anything, but maybe I need to do more than
> that? Tried stopping samba before that and restarting after, but no
> joy here either.

Stopping and restarting Samba will do what 'net cache flush = yes'
does.

>
> Btw the things You suggested I remove from my config files is not
> stuff I invented myself

I never said you did :-)

>  - I mostly followed the  https://wiki.samba.org/ pages which might
> mean some of them are out of date.

No, most of those lines should not be in a DC or are the defaults on a
Unix domain member and a Unix domain server can never be a 'standalone
server', that is a totally different beast.

>  Could those lines be responsible for this weird DC behavior, or is
> just stuff that's surplus to requirements of any kind?

They are just surplus to requirements and shouldn't have any affect on
the IDs.

>  If I remember correctly, some of those things came about when I
> introduced the physical DC next to the one I've always had on a VM to
> prioritise the physical one. That was my idea of some weird clock
> sync problems I've been observing which I though might be down to the
> DC being run off a VM which can sometimes have clock problems, having
> no hardware clock of their own.

AD is very time critical, so if the time is out by about 5 minutes,
replication might not be working. I suggest you run:

'samba-tool dbcheck' on both DCs
'samba-tool ldapcmp' from one of the DCs

See if that throws up any errors.

Rowland



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba


More information about the samba mailing list