samba - Sep 2016 - updates of repsFrom/repsTo attributes (was : Re: replPropertyMetaData & KCC issues after updating to Samba 4.5.0)

On 9/24/2016 7:32 AM, Denis Cardon wrote:
>
> 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.
>
> Cheers,
>
> Denis
>
>
>>
>>
>
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?

-- 
-James

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

> 
> 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?
As long as the topology doesn't change or DCs which are not bridgeheads 
do not go offline, there should be basically zero additional reps over 
time. How often they build up over time is an open question (when DCs do 
go offline), I can't test every setup and I'm sure there are edge cases.
However if there are these additional links for when you have spuriously 
unreliable DCs, they work just as well as a fallback.

The interSiteTopologyFailover attribute seems to be on the 
NTDS-Site-Settings class. By default it probably isn't defined, but the 
internal default value in both Samba and Windows is 2 hours.

The ITSG is not the same as the bridgehead server. The ITSG is a single 
DC in the site which coordinates all the DCs and picks bridgehead 
servers in the site to talk to other sites (at some DC bridgehead 
arbitrarily chosen on the other end). The reason I ask who the ITSG was 
is because if the ITSG is dead, it is reasonable to expect that there is 
no current coordinator who is site-aware, and so no fallback has 
occurred yet.

Cheers,

Garming

I have also managed to spot a hard-coded 2 hour fallback period in our 
code (which may or may not be configurable in Windows). So this period 
of time seems to generally be the default expectation of how long you 
might expect to be able to take the DC offline without interfering with 
the topologies (which is probably what you might want in the case of 
brief service interruption and not suddenly triggering replication to 
other partners). We may want to add a configuration option to Samba 
possibly, but this requires some more thought and from some the feedback 
I already have, some are surprised we were this fault tolerant to begin 
with.

Cheers,

Garming

On 2016-09-27 22:25, garming at catalyst.net.nz wrote:
>> 
>> 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?
> 
> As long as the topology doesn't change or DCs which are not
> bridgeheads do not go offline, there should be basically zero
> additional reps over time. How often they build up over time is an
> open question (when DCs do go offline), I can't test every setup and
> I'm sure there are edge cases. However if there are these additional
> links for when you have spuriously unreliable DCs, they work just as
> well as a fallback.
> 
> The interSiteTopologyFailover attribute seems to be on the
> NTDS-Site-Settings class. By default it probably isn't defined, but
> the internal default value in both Samba and Windows is 2 hours.
> 
> The ITSG is not the same as the bridgehead server. The ITSG is a
> single DC in the site which coordinates all the DCs and picks
> bridgehead servers in the site to talk to other sites (at some DC
> bridgehead arbitrarily chosen on the other end). The reason I ask who
> the ITSG was is because if the ITSG is dead, it is reasonable to
> expect that there is no current coordinator who is site-aware, and so
> no fallback has occurred yet.
> 
> Cheers,
> 
> Garming

On 9/28/2016 1:25 AM, garming at catalyst.net.nz wrote:
>>
>> 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?
>
> As long as the topology doesn't change or DCs which are not 
> bridgeheads do not go offline, there should be basically zero 
> additional reps over time. How often they build up over time is an 
> open question (when DCs do go offline), I can't test every setup and 
> I'm sure there are edge cases. However if there are these additional 
> links for when you have spuriously unreliable DCs, they work just as 
> well as a fallback.
>
> The interSiteTopologyFailover attribute seems to be on the 
> NTDS-Site-Settings class. By default it probably isn't defined, but 
> the internal default value in both Samba and Windows is 2 hours.
>
> The ITSG is not the same as the bridgehead server. The ITSG is a 
> single DC in the site which coordinates all the DCs and picks 
> bridgehead servers in the site to talk to other sites (at some DC 
> bridgehead arbitrarily chosen on the other end). The reason I ask who 
> the ITSG was is because if the ITSG is dead, it is reasonable to 
> expect that there is no current coordinator who is site-aware, and so 
> no fallback has occurred yet.
This is what seems to be stumbling me, however I think I understand a 
bit better. Samba isn't defining a bridgehead server(which I do not 
want). I was under the impression the owner of the ISTG was in fact a 
bridgehead server. Reading this link 
https://support.microsoft.com/en-us/kb/224815 tells me 'The domain 
controller holding this role may not necessarily also be a bridgehead 
server'.  To verify I queried for the CN 'Bridgehead-Server-List-BL'
which is also not set. Is this hard coded in Samba and I'm unable to see 
it or is this not the correct attribute to confirm?

The link also references how a DC alerts other DC's that a ISTG has gone 
down in a site. This is the critical component I was worried about. Is 
this feature currently implemented in Samba? On a Microsoft DC you can 
alert how often you want to check for the ISTG in a registry setting. Do 
you have plans to add this as a option for the smb.conf?

I will also point out Samba did correctly set the ISTG for my sites to 
DC1. The first DC I joined to that site. After deleting the NTDS 
connections, I see that my second DC in a site was chosen as the ISTG. 
This tells me some sort of check may be happening to switch the ISTG?

Based on all this it appears the new KCC does in fact work correctly 
with a few minor issues relating to the replications To and From. Thanks 
for the hard work.



>
> Cheers,
>
> Garming


-- 
-James