Need urgent help with samba4 DC re-join

Andreas Oster aoster at
Tue Jul 17 11:31:24 MDT 2012


Am 17.07.2012 08:09, schrieb Andrew Bartlett: 

> On Tue, 2012-07-17
at 11:17 +1000, Andrew Bartlett wrote:
>> On Sat, 2012-07-14 at 08:07
+0200, Andreas Oster wrote: 
>>> Am 14.07.2012 04:29, schrieb Andrew
>>>> On Fri, 2012-07-13 at 08:09 +0200, Andreas Oster
>>>>> Am 03.07.2012 00:32, schrieb Andrew Bartlett: 

>>>>>> On Mon, 2012-07-02 at 20:00 +0200, Andreas Oster wrote: 

>>>>>>> Hello Andrew, as I have written, I have managed to restore the
system to the state before my disastrous attempt to demote my BDC
(novadc02). Currently both servers operate normal but still the problems
with objectClass and objectCategory of the DomainDnsZones and
ForestDnsZones exists. Would it make sense to, after taking a proper
backup, demote the second DC again or should the faulty DB entries be
fixed first ?
>>>>>> I've been thinking over this, and the reason for
the slow replies is that the situation isn't easy to fix. Somehow (and I
would like to understand how), the instanceType in your DNS partition on
the master is set not to include the WRITE bit. This causes the
repl_meta_data message you see. However, I'm pretty sure 'fixing' the
instanceType bit would be prohibited by the objectclass module,
enforcing the broken schema. Given all that, it seems the 'safe' way to
fix it is to correct the instanceType based on the msDS-hasMasterNCs
attribute in a dbcheck routine, setting various flags to bypass checking
for this specific change, but I've not written that yet. Sorry, Andrew
>>>>> Hello Andrew, did you have a chance to do something
regarding the dbcheck enhancement to fix the broken schema of my samba4
installation ? Thank you for your kind help
>>>> Not yet, sorry. Please
keep reminding me. If someone else wants to take on the task, the changes needed are: - for every haveMasterNCs in an ntDsa
object - confirm that the instanceType attribute on the pointed-at
schema have the writable flag set. If not, set it. While doing that, an
additional task will be to fill out the msDS-HasInstantiatedNCs
attributes so the 'binary' part of the BINARY+DN matches the (perhaps
newly revised) instanceType. eg msDS-HasInstantiatedNCs:
B:8:0000000D:${CONFIGDN} Thanks, Andrew Bartlett
>>> Hello Andrew, thank
you for the update.
>> Attached is a patch for the first part of this.
KEEP GOOD BACKUPS (and run this on a backup). I'll get to the second
part of this soon, but if you can let me know if this lets you fix
things, it would be most helpful.
> I've pushed corrected patches
> In particular, I think I've found how we get your DB corrupted
in the
> first place, and one of the patches there should prevent this
> again in the future. 
> I'll keep updating that branch as
I keep testing, but please let me know
> how it works. 
> Unless
things are worse than we expect, dbcheck (run as dbcheck -H
> sam.ldb
--cross-ncs) should only need to correct the instanceType on
> objects
in your DNS partitions. When you are comfortable with the
> proposed
changes, use --fix. 
> Thanks,
> Andrew Bartlett

Hello Andrew,

I have copied the servers to a different VMware server and fetched the
latest sources from git.
Then I have applied your patches and compiled
everything. After the installation and startup 
of the samba4 service I
did the "samba-tool dbcheck -H sam.ldb --cross-ncs" but resceived
frightening error messages ( about 1000 ) 

all look quite the same,
here one example: 

ERROR: Normalisation error for attribute whenCreated
'19700101000000.0Z' should be '16010101000000.0Z'
Not fixing attribute

This repeates many times for different CNs. 

Is this
something to be concerned about ? 

At the end there is also some output
regarding the wrong instanceType for DomainDnsZones and

Thank you for your kind help 




More information about the samba-technical mailing list