DsReplicaUpdateRefs after Client calls DsGetNCChanges causes last_successful and last_attempt of repsTo to stay at 0

voidswitch voidswitch at gmail.com
Thu May 12 16:13:25 UTC 2016


On 05.05.2016 21:01, Andrew Bartlett wrote:
> On Mon, 2016-04-25 at 19:34 +0200, voidswitch wrote:
>> Hi,
>>
>> After investigating a problem with samba-tool drs showrepl and dcdiag
>> on windows with DsReplInfo, where the timestamps for outbound
>> replication are 0, it seems DsReplicaUpdateRefs is called too often. 
>>
>> The Problem:
>>
>> $ samba-tool drs showrepl
>> site/dc
>> DSA Options: 0x00000001
>> DSA Object GUID: ...
>> ...
>>
>> ==== INBOUND NEIGHBORS ====
>>
>> DC=DomainDnsZones,DC=<domain>
>>     site/dc via RPC
>>     DSA object GUID: ....
>>     Last attempt @ Mon Apr 25 19:12:10 2016 CEST was successful
>>     0 consecutive failure(s).
>>     Last success @ Mon Apr 25 19:12:10 2016 CEST
>> ...
>>
>> ==== OUTBOUND NEIGHBORS ====
>>
>> DC=DomainDnsZones,DC=<domain>
>>     site/dc via RPC
>>     DSA object GUID: ....
>>     Last attempt @ NTTIME(0) was successful
>>     0 consecutive failure(s).
>>     Last success @ NTTIME(0)
>> ...
>>
>> ==== ...
>>
>> With higher loglevel DsReplicaGetInfo shows 
>>
>>   last_success             : NTTIME(0)
>>   last_attempt             : NTTIME(0)
>>
>> indicating that repsTo on the server contains 0 for these fields.
>> Using dcdiag on Windows says that the remote dc was updated 1970 (0
>> timestamp -> 1970-01-01).
>>
>> As far as I understand, the code in
>> source4/dsdb/repl/drepl_out_helpers.c applies changes it requested
>> via GetNCChanges. If I did not get it completly wrong, it means also,
>> after each change it applied, DsUpdateRefs is called, which
>> effectively resets repsTo on the server. Since no update on repsTo is
>> done afterwards, its fields last_success and last_attempt stay at 0. 
>>
>> looking through MS Documentation and GetNCChanges Code, it seems, the
>> update to repsTo could also be achieved, if the request for
>> GetNCChanges contains DRS_ADD_REF. This would not reset repsTo (as it
>> does only add), and keep repsTo fresh I guess. 
>>
>> Maybe I overlooked something, as I could not test it. Anyways, before
>> I further look into it, I thought it would be better to ask someone
>> who has more insight.
> 
> Very interesting!  A python test to confirm the GetNCChanges behaviour
> against the repsTo (fetched over LDAP) would be a good way to confirm
> it.
> 
> BTW, don't doubt yourself so much, you are already understanding this
> area much better than most, and clearly are on the right track.  
> 
> Thanks!
> 
> Andrew Bartlett
> 

Hi,

I am currently investigating replication (scheduled and eventbased) to understand most of what is going on there, and trying to understand how it should work. The issue with repsTo is only one part of this, affecting samba-tool drs showrepl, and masking a likely issue with event based replication not sending a time based notification, if no events are triggered, so repsTo info about last_attempt and last_success is getting old.

I'll work on tests first, to verify my points.

Thanks,
Dirk



More information about the samba-technical mailing list