[Samba] Samba 4.6.x as secondary DC to Windows 2008 R2

Prof. Dr. Michael Schefczyk michael at schefczyk.net
Thu May 11 16:42:44 UTC 2017

Dear All,

I am running a two location SOHO network with a Microsoft AD on a Windows 2008 R2 server. In detail, the infrastructure is as follows:

Primary location:
- 1 DC on Windows 2008 R2 hardware server
- 1 DC on Windows 2008 R2 virtual server
- 2 DC on Windows 2016 virtual servers (forest functional level 2008)
- 1 DC on Samba 4.6.2 on Debian Jessie

Secondary location:
- 1 DC on Samba 4.6.3 on Debian Jessie

My aim is to become more independent from Microsoft products. Over time, I will be unable to avoid upgrading my Windows servers to Windows 2016 - which does not mean that the DC level needs to be upgraded to Server 2016 (known to incompatible with Samba).

My problem is twofold:

1) It seems that at least joining the domain and the initial replication is possible only with Samba DC and Windows 2008 R2 DC, not with Windows 2016 DC, even if forest level is 2008. That is a problem, because once no 2008 servers will remain, the possibilities to join as a DC shrinks.

Is this correct and is there a cure?

2) While the Windows DC are very reliable and able to recover pretty much any interruption of services (except scaling back a virtual machine to a previous point in time, of course), Samba 4.6.x does seem to be pretty sensitive. It seems that the slightest interruption of service in the wrong moment kills further replications permanently. Such interruptions include a reboot at the wrong moment or minimal interruptions of connectivity (e. g., online backup of a VM or seconds of loss of VPN connectivity between locations). From such point in time, the Microsoft DCs throw an error which indicates that schemas to no longer match (original error message in German below).

So far, the only fix was to shut down the affected Samba DC, force delete it from a Windows 2008 R2 DC, delete the relevant .tdb and .ldb databases, restart samba and rejoin the domain. Since this does happen frequently (so far, my setup did not survive for any single calendar month consistently), I would very much welcome to learn if there is a better recovery technique.

Is my setup feasible at all? Should I better give up and install a Windows 2016 DC in my secondary location to achieve good reliability?

I would be very happy to find a reliable solution for two reasons: a) I do prefer open source. b) I would like to build a two node CTDB cluster. But I would feel terrible if I procured two hardware servers only to find the same reliability issues with the CTDB cluster as well.



Protokollname: Directory Service
Quelle:        Microsoft-Windows-ActiveDirectory_DomainService
Datum:         XX.XX.2017 20:55:42
Ereignis-ID:   1791
Ebene:         Fehler
Computer:      servercore.schefczyk.local
Die Replikation der Anwendungsverzeichnispartition DC=schefczyk,DC=local von Quelle 11d000d6-f318-44fa-9935-dfc82a28c282 (domainb72.schefczyk.local) wurde abgebrochen. Für die Replikation ist ein konsistentes Schema erforderlich, aber beim letzten Versuch, das Schema zu synchronisieren, ist ein Fehler aufgetreten. Ein ordnungsgemäßes Funktionieren der Schemareplikation ist äußerst wichtig. Betrachten Sie die vorangegangenen Fehler zur weiteren Analyse. Wenden Sie sich an Microsoft Support Services, falls das Problem weiterhin besteht. Fehler 8418: Der Replikationsvorgang ist fehlgeschlagen, da Schemas unter den beteiligten Servern nicht übereinstimmten..
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" />
    <EventID Qualifiers="49152">1791</EventID>
    <TimeCreated SystemTime="2017-XX-XXT19:55:42.634417100Z" />
    <Correlation />
    <Execution ProcessID="816" ThreadID="1856" />
    <Channel>Directory Service</Channel>
    <Security UserID="S-1-5-7" />
    <Data>11d000d6-f318-44fa-9935-dfc82a28c282 (domainb72.schefczyk.local)</Data>
    <Data>Der Replikationsvorgang ist fehlgeschlagen, da Schemas unter den beteiligten Servern nicht übereinstimmten.</Data>

More information about the samba mailing list