Note: Cool Solutions are articles documenting additional functionality based on Univention products. Not all of the shown steps in the article are covered by Univention Support. For questions about your support coverage contact your contact person at Univention before you want to implement one of the shown steps.
The Directory Replication Service (DRS) in large Samba Active Directory domains spread over several physical locations tends to get slow and unreliable with the default installation settings of Samba AD. This article covers the causes and possible solutions to improve poor replication performance, e.g. in environments with high latency network segments connected over WAN connections.
Active Directory and thus Samba implements a series of concepts and object types to enable administrators and system engineers to define a replication topology according to the physical network layout. The most relevant object types in this context are sites and their corresponding subnets. The network connections between sites are represented by site links with site link bridges or bridgehead servers which (among others) form connection objects which logically represent a replication link. It is quite important to note that site links can be attributed with a cost setting to prioritize certain network paths over others or even disable certain replication paths completely in order to shape the traffic efficiently and reduce possible “replication noise” over network-expensive and limited WAN connections.
The purpose of modeling the physical network topology is to allow a built-in process running on all domain controllers, the KCC (Knowledge Consistency Checker) to dynamically generate a replication topology model that automatically controls the usage of available network resources for the replication traffic. As is to be expected, the default network topology assumed by all Samba or Windows Domain Controllers is a flat, evenly meshed network of all hosts that need to be replicated. While this might fairly represent the physical network topology in smaller networks that do not span over several remote locations, it makes replication traffic rather inefficient in larger multi-site installations. Because all network cost is regarded as equally “cheap” a full mesh, random choice of replication partners and links will occur with foreseeable consequences for the replication performance.
It is thus important in larger multi-site networks to make the Domain Controllers (DC) and their KCCs aware of this situation by defining sites in the Active Directory replication model. This allows Domain Controllers to make smarter choices concerning the replication links it selects, e.g. avoiding redundant multiple replication runs over Inter-Site-Transports and using bridgehead servers instead which are the only local DCs that replicate to a partner on a different site (being the bridgehead for that site). So the key to good replication performance is proper modeling of the physical network topology in the Active Directory tree and defining a well chosen network cost for each Inter-Site-Transport which indirectly shapes the replication path preferences and network usage for the Domain Controllers and their respective KCCs.
To get a quick overview of the Directory Replication Service (DRS) status on the console of a Samba AD DC the Samba suite provides the samba-tool that can be invoked as an “Administrator” or as root for this task with
samba-tool drs showrepl
This will output a list of all inbound and outbound replication neighbors as well as KCC connection objects with other useful configuration information and replication statistics, which is the primary resource for verifying or troubleshooting your AD replication configuration directly on the console of a Samba AD DC. An excerpt from the output in a demonstration domain univention.xmpl could look like this:
DC=DomainDnsZones,DC=univention,DC=xmpl Master-Standort\DC-M1 via RPC DSA object GUID: e0362a92-30e4-4869-acdc-e0bf3ff44a16 Last attempt @ NTTIME(0) was successful 0 consecutive failure(s). Last success @ NTTIME(0) ==== KCC CONNECTION OBJECTS ==== Connection -- Connection name: cc1e8a22-f1b2-4aba-b3fc-60235ab3b355 Enabled : TRUE Server DNS name : dc-m0.univention.xmpl Server DN name : CN=NTDS Settings,CN=DC-M0,CN=Servers,CN=Master-Standort,CN=Sites,CN=Configuration,DC=univention,DC=xmpl TransportType: RPC options: 0x00000001
The particularly interesting aspect for the scope of this article is that each host (only one of many shown here) is prefixed with a site name. For UCS the samba4/join/site key in the Univention Configuration Registry can be set to assign a host to a specific site, preferably even before installing Samba in the AD DC role and joining a domain. This will save you some manual configuration work afterwards, since a new AD site and subnet is automatically created and configured when a host with a previously unknown site attribute joins the domain.
1. Set the site attribute:
To set the Samba AD site attribute on a newly installed system and assign the host to “Site 2” we set the samba4/join/site key (even before having the Samba AD App installed)
ucr set samba4/join/site=”Site 2”
ucr get samba4/join/site
3. Enable the new Samba KCC:
Starting with Samba 4.5 a new implementation of the Samba KCC has been introduced that better utilizes the AD network model to optimize the replication traffic especially in large networks. Since this new and improved KCC mainly shows its benefits in large and complex networks it was not enabled by default on UCS Samba/AD installations to avoid potential backward-compatibility problems with existing systems. It is however advisable in new installations that relate to the discussed scenario to utilize the newer Samba KCC. This is controlled by setting the samba4/kccsrv/samba_kcc ucr key on every UCS Samba AD DC to True.
ucr set samba4/kccsrv/samba_kcc=yes
4. Install Samba:
After this preparation we can finally install the Samba AD package, join the domain and take advantage of the automatic site and subnet creation
univention-app install samba4 univention-join
This can of course also be done via the web interface from the UCS App Center/Management Console if you prefer the graphical method.
To manage the AD network model from a machine with a GUI, Microsoft provides the Active Directory Sites and Services snap-in for the MMC management console which can be used on a Windows server or client in the domain to view and edit the AD topology properties. Please note that in many cases Enterprise Admin group privileges are required to edit the settings and the standard UCS “Administrator” account is not a member of this group by default. So to effectively use this tool with the standard UCS Administrator account it should be considered to make it a member of the Enterprise Admin group.
This view of an example Samba AD Domain shows a setup with 3 sites, one being the “Master” with both a Master- and a Backup-DC while there are 2 hypothetical remote sites having another Backup-DC and a Slave-DC respectively. It is interesting to note that the sites and subnets shown on the left pane were not added manually but automatically configured after the “remote” DCs joined the Domian with a preconfigured ucr samba4j/oin/site attribute. What is left to be done is renaming the site links with a meaningful and descriptive name and dealing with the Inter-Site Transports to set the physical topology and define network costs for the replication traffic (as shown in the open detailed properties dialog on the right). For a more in-depth explanation of the art of successful AD topology planning and modeling the Microsoft documentation as mentioned below is certainly worth a look.
The Univention Samba Troubleshooting guide: Samba 4 Troubleshooting
The Samba wiki on AD sites: Active Directory Sites - SambaWiki
Related Microsoft documentation on Active Directory Replication:
Setting up AD Sites, Subnets & Site-Links on Windows: