Introduction

Running one domain controller (DC) is sufficient for a working Active Directory (AD) forest. However, for failover and load balancing reasons, you should add further DCs to your AD forest. Joining an additional Samba DC to an existing AD differs from provisioning the first DC in a forest. If you set up a new AD forest, see Setting up Samba as an Active Directory Domain Controller.

An NT4 domain uses only one Primary Domain Controller (PDC) and optionally additional Backup Domain Controllers (BDC). In an AD forest, there is no difference between DCs, beside the FSMO roles. Use only the term "domain controller" or "DC" when you talk about AD to avoid any possibility of confusion.

Installing Samba

Preparing the Host for Joining the Domain

Local DNS server

By default, the first Domain Controller (DC) in a forest runs a DNS server for Active Directory (AD)-based zones. For failover reasons it is recommended to run multiple DCs acting as a DNS server in a network. If you consider providing a DNS service on the new DC:

For the BIND9_DLZ back end, see BIND9_DLZ DNS Back End. Finish this task before you start the Samba DC service.

--option="interfaces=lo eth0" --option="bind interfaces only=yes": If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables the samba-tool command to register the correct LAN IP address in the directory during the join.

If the other DCs are Samba DCs and were provisioned with --use-rfc2307, you Should add --option='idmap_ldb:use rfc2307 = yes' to the join command

Verifying the DNS Entries

If you join a Samba DC that runs Samba 4.7 and later, samba-tool created all required DNS entries automatically. To manually create the records on an earlier version, see Verifying and Creating a DC DNS Record.

Configuring the BIND9_DLZ DNS Back End

If you selected the BIND9_DLZ DNS back end during the domain join, set up the BIND configuration. For details, see BIND9_DLZ DNS Back End.

Built-in User & Group ID Mappings

Sysvol replication is currently not supported on Samba. To use a Sysvol Replication workaround, all domain controllers (DC) must use the same ID mappings for built-in users and groups.

By default, a Samba DC stores the user & group IDs in 'xidNumber' attributes in 'idmap.ldb'. Because of the way 'idmap.ldb' works, you cannot guarantee that each DC will use the same ID for a given user or group. To ensure that you do use the same IDs, you must:

Create a hot-backup of the /usr/local/samba/private/idmap.ldb file on the existing DC:

# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb

This creates a backup file /usr/local/samba/private/idmap.ldb.bak.

Move the backup file to the /usr/local/samba/private/ folder on the new joined DC and remove the .bak suffix to replace the existing file.

Reset the Sysvol folder's file system access control lists (ACL) on the new DC:

Verifying Directory Replication

After the domain controller (DC) has been started, the knowledge consistency checker (KCC) on the Samba DC creates replication agreements to other DCs in the Active Directory (AD) forest. It can take up to 15 minutes until the KCC creates the auto-generated replication connections.

Verifying Kerberos

DNS Configuration on Domain Controllers

The DNS configuration on domain controllers (DC) is important, because if it is unable to locate other DCs the replication will fail. The following is a best practice for DNS configuration on domain controllers (DC):

Set the local IP of a DC as secondary or tertiary nameserver entry in its /etc/resolv.conf file and use a different Active Directory (AD) DNS server IP from the forest as primary name server. For example:

On the new joined DC, use the 10.99.0.1 IP of the existing DC as primary and the local 10.99.0.2 IP as secondary nameserver entry:

nameserver 10.99.0.1
nameserver 10.99.0.2 # IP of the new joined DC as secondary entry
search samdom.example.com

If you are running more than two DCs, you can configure the IPs in crosswise direction.

Configuring Time Synchronisation

Kerberos requires a synchronised time on all domain members. For further details and how to set up the ntpd service, see Time Synchronisation.