[Samba] updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)

[Denis Cardon]

Hi LingPanda101,

>> the job of the samba_kcc script is to create the ntdsConnection
>> objects. Afterward the repsFrom/repsTo attribute are created in
>> accordance with the ntdsConnection objects (you can force the creation
>> using samba-tool drs replicate although). You can check that the
>> process is asynchronous when you join a new DC, the INBOUND and
>> OUTBOUND entries are coming later on after the ntdsConnection object
>> has been created.
>>
>> You can find repsFrom/repsTo attributes at on the root ldap entries of
>> each of the five AD partitions. Those entries correspond to the
>> INBOUND and OUTBOUND display in the samba-tool drs showrepl command.
>>
>> However there is currently no standard way to delete the leftover of
>> repsfrom/repsto, others than deleting the repsFrom/repsTo attribute
>> manually or through scripting (python-ldb is your friend here).
>>
>> I had a discussion with Garming a while ago about this issue, and it
>> was not clear what process was responsible to remove spurious/leftover
>> repsfrom/repsto attribute. With the old kcc, it was not such an issue
>> because it was full meshed, however with the new KCC, it would indeed
>> be good to have some more tooling for drs maintenance and monitoring.
>>
>> By the way, KCC computation algorithm specifications from Microsoft
>> are kind of mind boggling, so there might need some more tweaking, but
>> thanks to Garming it is has done the job for us since 4.3.0 for almost
>> one year.
>>
>
> Wasn't aware of this. Thank you for the info. If I was to delete the
> incorrect respsFrom/repsTo attributes, wouldn't the KCC just regenerate
> them over time once the KCC check and ISTG check kicked in?

like Garming was saying, there is a separate step from the KCC topology 
calculation to translate the ntdsConnection objects to replication 
links. That separate process create the attribute based on the 
ntdsConnection object, so if there is no spurious ntdsConnection object, 
it won't create the spurious replication links.

However there is a caveat at this time. repsFrom attributes on one DC 
are the mirror of the repsTo attribute from the remote DC. And a 
repsFrom on one DC will trigger the re-creation of the repsTo on 
corresponding remote DC... So when you want to do the cleanup, then you 
have to firewall the two DC so dreplsrv service cannot see each other, 
delete the spurious attributes and then remove the firewalling.

Yes it is not very convenient, but with a little bit of scripting, you 
can do it very fast, I did it recently on a 50 DCs network.

Cheers,

Denis


-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr