Joining a Samba DC to an Existing Active Directory: Difference between revisions

From SambaWiki
m (Mmuehlfeld moved page Join an additional Samba DC to an existing Active Directory to Joining a Samba DC to an Existing Active Directory: Change title to TitleCase and make it more suitable)
(Rewrote "Joining a Samba DC to an Existing Active Directory" documentation. More precise text, removed unneccesary/duplicated content, clearer examples, etc.)
Line 1: Line 1:
= Introduction =
= 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 [[Setup_a_Samba_Active_Directory_Domain_Controller|Set up a Samba Active Directory Domain Controller]].
The minimum number of Domain Controllers in an Active Directory forest is one. However, in an enterprise environment, it is always recommended to add further DCs, to provide failure safety, high availability and load balancing. For fail-over reasons, at least two DCs are recommended. Depending on your network, there can be many different reasons in deciding just how many DCs are required. A common scenario is, an AD forest is spread across multiple locations, connected via VPN or the like, here it is reasonable to have at least one DC at each site. This keeps AD services available everywhere, even if the branch office is temporary not connected to the central office. Unless you're running a RODC, each Domain Controller has a write-enabled database, this allows changes inside the AD to be done on every DC. Password changes, user creation, domain joins, etc. will still possible, even if other DCs are temporary not available due to e. g. network outages and users on each site can continue to authenticate and work with local servers without problems.


{{Imbox
An NT4 domain has only one Primary Domain Controller (PDC) and possibly additional Backup Domain Controllers (BDC). In an AD forest there's no such difference any more, there is no such thing as a "master server" , They are all simply called "Domain Controller" (DC) and are equal. Please use only this term, when talking about an Active Directory, to avoid confusion, especially when asking for help.
| type = note

| text = An NT4 domain uses only one Primary Domain Controller (PDC) and optionally additional Backup Domain Controllers (BDC). In an AD forest, there is no differences between DCs, beside the [[Flexible_Single-Master_Operations_(FSMO)_Roles|FSMO roles]]. Use only the term "domain controller" or "DC" when you talk about AD to avoid any possibility of confusion.
The process of joining a new Samba DC to an existing AD differs in some points to [[Setup_a_Samba_Active_Directory_Domain_Controller|provisioning a new domain]]. The following steps for joining a Samba DC to an existing domain are the same - regardless if the existing AD is based on Windows or Samba DCs. However, if you're joining the first Samba DC into a Windows based AD, you should read the [[Setup_a_Samba_Active_Directory_Domain_Controller|Setup a Samba Active Directory Domain Controller]] documentation before you continue. It contains some basic information about the environment, command explanation, etc. not repeated here.
}}

'''See the [[Host_information_used_in_documentation|host information used in documentation]] page for used paths, hostnames, etc.'''




Line 15: Line 14:
= Preconditions =
= Preconditions =


* Use a static IP address.
* Make sure that your future DC uses a static IP address. Using one set by DHCP can cause trouble, if the address changes.


* Verify that the host name in <code>/etc/resolv.conf</code> resolves to the network IP and not to <code>127.0.0.1</code> (localhost).
* Check your /etc/hosts for a correct resolution of the hostname to its IP:

127.0.0.1 localhost.localdomain localhost
127.0.0.1 localhost.localdomain localhost <s>DC2.samdom.example.com</s> <s>DC2</s>
10.99.0.2 DC2.samdom.example.com DC2
10.99.0.2 DC2.samdom.example.com DC2
: Ensure that your DC hostname resolves to its LAN IP and not to 127.0.0.1!


* If Samba was already configured on this host, remove any existing configuration and databases.
* Remove any previous existing installation of Samba on the host.


* When joining a Windows Active Directory (AD), run the following tests on a Windows computer in the domain:
* If your AD forest is Windows driven, further checks are required:
:The following commands can be run from any Windows domain computer.


:* Check the Forest functional level:
:* Verify that the forest functional level meets the Samba requirements:


> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
Line 35: Line 33:
:: Minimum suported level: 2003 native (level 2)
:: Minimum suported level: 2003 native (level 2)
:: Maximum suported level: 2008 R2 (level 4)
:: Maximum suported level: 2008 R2 (level 4)
::* Downgrade the functional level to 2008 R2, if you are joining an AD with a higher level.


::* Downgrade the forest functional level to 2008 R2, if you are joining an AD with a higher level.
:* Check the directory schema version:

:* Verify that the directory schema meets the Samba requirements:


> dsquery * "CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com" -Scope Base -attr objectVersion
> dsquery * "CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com" -Scope Base -attr objectVersion
Line 43: Line 42:
69
69


::Samba <= 4.4.x: The maximum Forest schema supported is: 47 (Server 2008 R2)
::Samba <= 4.4: Maximum supported forest schema: 47 (Server 2008 R2)
::Samba >= 4.5.x: The maximum Forest schema supported is: 69 (Server 2012 R2)
::Samba >= 4.5: Maximum supported forest schema: 69 (Server 2012 R2)




Line 52: Line 51:
= Installation =
= Installation =


To install Samba:
Before you start, check the [[Operating system requirements|Operating System requirements]] for dependencies.


* [[Build_Samba_from_Source|Build Samba From Source]]
You have the following options to install Samba:


* [[Distribution-specific_Package_Installation|Distribution-specific Package Installation]]
* [[Build_Samba_from_Source|Build Samba]] yourself


:Not all distributions currently provide packages with Active Directory (AD) domain controller (DC) support. For example, some distributions, such as Red Hat Enterprise Linux and Fedora, are based on MIT Kerberos, which is currently not supported by Samba. In this situation, compile Samba yourself or use packages with AD DC support.
* Install [[Distribution-specific_Package_Installation|distribution specific packages]]
: Make sure that you use a recent version of Samba, noting that not all distributions currently ship Samba packages with Active Directory Domain Controller capabilities. One reason is that some distributions are based on MIT Kerberos, while Samba (currently) only supports Heimdal Kerberos. E. g. Red Hat operating systems (RHEL, CentOS, Fedora, etc.) are affected. In this case, choose one of the other install options.


* Install SerNet [http://www.samba.plus Samba+]/[http://www.samba.plus/older-packages/ Enterprise] packages
* SerNet [http://www.samba.plus Samba+] or [http://www.samba.plus/older-packages/ Enterprise] packages




Line 67: Line 65:
== Paths ==
== Paths ==


You should consider putting the directories "/usr/local/samba/bin/" and "/usr/local/samba/sbin/" at the beginning of your $PATH variable:
If you built Samba yourself using the default directories, add the directories at the beginning of your <code>$PATH</code> variable:


export PATH=/usr/local/samba/bin/:/usr/local/samba/sbin/:$PATH
export PATH=/usr/local/samba/bin/:/usr/local/samba/sbin/:$PATH


To permanently add this to your system or user configuration, see your distributions documentation.
For information how to set the path variable permanently, see your distribution's documentation.




Line 77: Line 75:




= Preparing the host for the domain join =
= Preparing the Host for Joining the Domain =


== Local DNS server ==
== Local DNS server ==


By default, the first Domain Controller in a domain automatically acts as a DNS server for AD based zones. For failover reasons, it is recommended to have at least two DC's providing AD DNS services. If you plan to use BIND as the DNS backend on the new Domain Controller, you have to [[Configure_BIND_as_backend_for_Samba_AD|configure BIND as backend for Samba AD]] before you start your DC the first time. It's a good idea to finish this task now. If you decided to run the internal or no DNS server on this host, no further steps are required.
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 <code>BIND9_DLZ</code> back end, see [[Configure_BIND_as_backend_for_Samba_AD|Configure BIND as Back End for Samba AD]]. Finish this task before you start the Samba DC service.
* For the internal DNS no further actions are required.




== DNS resolving ==


== DNS Resolving ==
Many things in an Active Directory, not only the join process, rely on DNS. Therefore it is required that the new host is able to resolve AD DNS zones. To accomplish this, we use a DNS server on one of your existing Domain Controllers.


AD uses DNS in the background, such as locating other DCs and services. Thus configure your host to use a DNS server that is able to resolve the AD DNS zones.
On Linux and Unixes, you usually configure DNS settings in /etc/resolv.conf:

Set the DNS server IP and AD DNS domain in your <code>/etc/resolv.conf</code>. For example:


nameserver 10.99.0.1
nameserver 10.99.0.1
search samdom.example.com
search samdom.example.com


Some tools like NetworkManager may overwrite manual changes in that file. Please consult your distributions documentation for configuring name resolution.
Some utilities, such as NetworkManager can overwrite manual changes in that file. Consult your distribution's documentation for information about how to configure name resolution permanently.


To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:
To verify the DNS settings, try resolving the host name of one of your existing Domain Controllers. For example:


# host -t A DC1.samdom.example.com
# host -t A DC1.samdom.example.com
Line 105: Line 106:
== Kerberos ==
== Kerberos ==


Set the following settings in your Kerberos client configuration file <code>/etc/krb5.conf</code>:
Kerberos, which is also a very important part in an AD, needs to be configured next. Add the following content to /etc/krb5.conf:


[libdefaults]
[libdefaults]
Line 112: Line 113:
default_realm = SAMDOM.EXAMPLE.COM
default_realm = SAMDOM.EXAMPLE.COM


To verify the correct setup, use "kinit" to obtain a Kerberos ticket:
To verify the settings use the <code>kinit</code> command to request a Kerberos ticket for the domain administrator:


# kinit administrator
# kinit administrator
Password for administrator@SAMDOM.EXAMPLE.COM:
Password for administrator@SAMDOM.EXAMPLE.COM:


To list Kerberos tickets:
Depending on your distribution, "kinit" may just return you to a prompt when successful. To verify that you had received a Kerberos ticket, run: "klist -e"


# klist
Ticket cache: FILE:/tmp/krb5cc_0
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@SAMDOM.EXAMPLE.COM
Default principal: administrator@SAMDOM.EXAMPLE.COM
Line 130: Line 132:




= Join the existing domain as a Domain Controller =
= Joining the Active Directory as a Domain Controller =


To join the domain <code>samdom.example.com</code> as a domain controller (DC) that additionally acts as a DNS server using the Samba internal DNS:
Before you start, make yourself familiar with the possible parameters and options of the join process:


# samba-tool domain join --help
# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator" --dns-backend=SAMBA_INTERNAL


If your new Domain Controller has multiple network interfaces, the following two "samba-tool" options are required to prevent it auto-choosing one of the IPv4/IPv6 addresses of the interfaces. Furthermore it is necessary to bind Samba to the desired interface.

# samba-tool domain join ..... --option="interfaces=lo eth0" --option="bind interfaces only=yes"


Join the existing domain (parameter explanation below):

# samba-tool domain join samdom.example.com DC -Uadministrator --realm=SAMDOM.EXAMPLE.COM --dns-backend=SAMBA_INTERNAL
Finding a writeable DC for domain 'samdom.example.com'
Finding a writeable DC for domain 'samdom.example.com'
Found DC dc1.samdom.example.com
Found DC dc1.samdom.example.com
Password for [WORKGROUP\administrator]:
Password for [SAMDOM\administrator]:
workgroup is SAMDOM
workgroup is SAMDOM
realm is samdom.example.com
realm is samdom.example.com
checking sAMAccountName
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Line 182: Line 173:
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[38/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]
Replicating critical objects from the base DN of the domain
Replicating critical objects from the base DN of the domain
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]
Partition[DC=samdom,DC=example,DC=com] objects[387/287] linked_values[23/0]
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]
Done with always replicated NC (base, config, schema)
Done with always replicated NC (base, config, schema)
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[41/41] linked_values[0/0]
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]
Line 197: Line 188:
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC


See the <code>samba-tool domain join --help</code> command's output for further information.


Other frequently used parameters for the <code>samba-tool domain join</code> command:


* <code>--site=SITE</code>: Directly join the host as DC to a specific [[Active_Directory_Sites|Active Directory Sites]].
<u>Parameter explanations:</u>


* <code>--option="interfaces=lo eth0" --option="bind interfaces only=yes"</code>: If your server has multiple network interfaces, use these options to bind Samba to the specified interfaces. This enables <code>samba-tool</code> to register the correct LAN IP address in the directory during the join.
* <u>Domain:</u> AD Domain Name


* <u>Server Role:</u> "DC" for Domain Controller


* <u>Username:</u> Account that is allowed to join new Domain Controllers. Typically it is at least the Domain Administrator.


* <u>Realm:</u> Kerberos Realm written in upper case.


* <u>DNS backend:</u> Supported DNS backends are the [[Samba_Internal_DNS|Samba internal DNS server]] and [[Configure_BIND_as_backend_for_Samba_AD|BIND9_DLZ]]. We used the default - the internal DNS - in our above example. Even though it's the default, we used this parameter to show users how to set a different DNS backend. The internal DNS is the best choice if you do not have complex DNS requirements. See [[DNS#Which_DNS_backend_should_I_choose.3F|Which DNS backend should I choose?]] for a comparison and suggestions. If you choose BIND9_DLZ as the backend, you must setup and configure BIND before first starting your Domain Controller. See [[Configure_BIND_as_backend_for_Samba_AD|Configure BIND as backend for Samba AD]] for further setup information. If you later find out that your DNS backend choice doesn't fit your needs, you can [[Changing_the_DNS_backend|change it afterwards]]. Do not use BIND9_FLATFILE as the DNS backend. It isn't documented and is not supported! Given that this is at least your second DC in your AD forest, you can also choose NONE here. However, for failover reasons it is recommended to have at least two AD DNS servers in your network.


= Verify the DNS Entries =
* <u>Site:</u> If you have setup [[Active_Directory_Sites|Active Directory Sites]], it's possible to join a new DC directly into a specified AD site by using the "--site=SITE" parameter.


See [[Verifying_and_Creating_a_DC_DNS_Record|Verifying and Creating a DC DNS Record]].


{{Imbox
| type = warning
| text = Do not skip this step. If the DNS entries are missing, the directory replication fails.
}}






= Check DNS entries =


'''This is a very important step, so don't skip it!'''


= BIND9_DLZ DNS Back End =
For a working replication, it is required that all DC related DNS records were added to the DNS zones during the join. [[Verifying and Creating a DC DNS Record|Verify, if they are existing]] and if not ([https://bugzilla.samba.org/show_bug.cgi?id=10928 Bug #10928]), [[Verifying and Creating a DC DNS Record|add them manually]].


If you selected the <code>BIND9_DLZ</code> DNS back end during the domain join, set up the BIND configuration. For details, see [[Configure_BIND_as_backend_for_Samba_AD|Configure BIND as Back End for Samba AD]].








= Adaptations for the BIND DNS backend =


= Built-in Groups GID Mappings =
Skip this step, if you're not using BIND as DNS backend


Samba currently does not support Sysvol replication. If you plan to use a [[SysVol_replication_(DFS-R)|Sysvol Replication]] workaround, you have to ensure that all domain controllers (DC) use the same GID mappings for built-in groups:


* Create a hot-backup of the <code>/usr/local/samba/private/idmap.ldb</code> file a existing DC:


# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb
== Workaround: Fix keytab permissions ==


: This creates a backup file <code>/usr/local/samba/private/idmap.ldb.bak</code>.
This fix is only required, if joining the domain with a Samba version prior to 4.4. Wrong keytab permissions will prevent BIND updating your AD DNS zones. One of the results will be that "samba_dnsupdate" can't add important DNS entries, that clients query to locate the new Domain Controller!


* Move the backup file to the <code>/usr/local/samba/private/</code> folder on the new joined DC and remove the <code>.bak</code> suffix to replace the existing file.
Fix permissions on the "dns.keytab" file, to allow BIND to read this file:


* Reset the Sysvol folder's file system access control lists (ACL) on the new DC:
# chmod 640 /usr/local/samba/private/dns.keytab
# chgrp named /usr/local/samba/private/dns.keytab

''Note: If you use Samba packages, make sure that the account BIND uses, is able to access the dns.keytab file. Some package installations set too restrictive permissions on higher folders.''



== Enable the correct BIND9_DLZ module ==

Samba is shipped with BIND9_DLZ modules for different BIND versions. You have to enable the right one in /usr/local/samba/private/named.conf (uncomment the right one and comment the others):

dlz "AD DNS Zone" {
# For BIND 9.8.0
database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";
# For BIND 9.9.0
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";
# For BIND 9.10.0
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";
};

The example above enables the module for BIND 9.8.x (default).





= GID mappings of built-in groups =

If you are using a version of Samba before 4.2.0, or are using the builtin winbind instead of the separate winbindd, there are issues with GID mappings of built-in groups. The GIDs of groups owning files and directories in the SYSVOL folder may differ between Domain Controllers, as Samba doesn't replicate these GIDs!
From Samba version 4.2.0, the separate winbindd daemon is used instead of the built-in winbind and this is able to display the built-in group names instead of just the GID number.

If you are using a Samba version before 4.2.0 or are using the built-in winbind, you will need to use the following workaround:

'''NOTE: Only do this if you are running a version of Samba before 4.2.0 or are using the built-in winbind.'''

* Create a hot-backup of "idmap.ldb" on one of your other Samba Domain Controllers:

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

* Move the created backup file "/usr/local/samba/private/idmap.ldb.bak" to "/usr/local/samba/private/" on the new joined Domain Controller and remove the .bak suffix, to replace the existing file.

* Reset the ACLs on the local SYSVOL folder of the new joined Domain Controller:


# samba-tool ntacl sysvolreset
# samba-tool ntacl sysvolreset
Line 292: Line 243:
= Start Samba =
= Start Samba =


To start the Samba Active Directory Domain Controller in "standard" mode, which is suitable for production use, run
To start the Samba domain controller (DC), run:


# samba
# samba


Samba doesn't yet have init scripts included. You can find examples on the [[Samba4/InitScript|Samba Init-Script]] page.
Samba does not include start scripts. For examples, see [[Samba4/InitScript|Samba Init-Script]].









= Directory Replication =


A few minutes after the domain controller (DC) started, the connections with all other DCs are automatically established and the replication begins.
= Directory replication =


To verify the directory replication, run on a Samba DC:
A few minutes after you have started Samba, connections with other DCs will be established automatically.


# samba-tool drs showrepl
# samba-tool drs showrepl
Line 397: Line 350:
Warning: No NC replicated for Connection!
Warning: No NC replicated for Connection!


'''Depending on your replication settings it may take a few minutes until all connections are established. So please be patient!''' On the long shot that the outbound connections aren't established automatically - not even after several minutes - you can force the replication (generally not necessary!). See [[Samba-tool_drs_replicate|samba-tool drs replicate]].
It can take several minutes until all connections are established. If the connections on existing Samba DCs to the Windows DC are not established within 15 minutes, start the replication manually. For details, see [[Samba-tool_drs_replicate|samba-tool drs replicate]].


''Note: The message "Warning: No NC replicated for Connection!" can be safely ignored. See [[FAQ#Message:_Warning:_No_NC_replicated_for_Connection.21|FAQ: Message: Warning: No NC replicated for Connection!]]''
If you are seeing the warning "No NC replicated for Connection!", see [[FAQ#Message:_Warning:_No_NC_replicated_for_Connection.21|FAQ: Warning: No NC replicated for Connection!]].




Line 405: Line 358:




= Start BIND =
= Starting the BIND daemon =


Before you start the BIND daemon, verify that the DNS directory partitions have been replicated:
Skip this step if not using BIND9_DLZ as DNS backend.

Check that the DNS partitions are already replicated:


# samba-tool drs showrepl
# samba-tool drs showrepl
Line 429: Line 380:
Last success @ Thu Sep 24 20:08:45 2015 CEST
Last success @ Thu Sep 24 20:08:45 2015 CEST


If replication is working, start BIND.
If the replication is working, start the BIND daemon. See your distribution's documentation for information how to start a service.




Line 435: Line 386:




= Testing the local DNS =
= Testing the Local DNS =


Skip this step, if you have choosen "NONE" as DNS backend during the join.
Skip this step if you selected <code>--dns-backend=NONE</code> during the join.


To test that the local DNS is working properly, run the following commands on the new DC, to query the local DNS
Query the local DNS server to resolve the domain name <code>samdom.example.com</code>:


$ host -t A dc1.samdom.example.com localhost
# host -t A samdom.example.com localhost
Using domain server:
Using domain server:
Name: localhost
Name: localhost
Line 447: Line 398:
Aliases:
Aliases:
dc1.samdom.example.com has address 10.99.0.1
samdom.example.com has address 10.99.0.1
samdom.example.com has address 10.99.0.2


The local DNS must answer with the IP addresses of all domain controllers (DC).
If you receive any errors, check your system logs to locate the problem.


In case you receive no or a different result, review this documentation and check:
* the system log files,
* the Samba log files,
* the BIND log files, if the <code>BIND9_DLZ</code> is used.








= Best practice: DNS configuration on DCs =


= DNS Configuration on Domain Controllers =
It is not just on Workstations that you should configure at least two AD DNS servers. On Domain Controllers it is even more important, because if just one DNS is configured and that one fails, services relying on DNS, such as directory replication, will also fail!


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):
A best practice for DNS configuration on DCs is, that you don't define the IP of the local DNS as the first nameserver. This could lead into problems like [http://retrohack.com/a-word-or-two-about-dns-islanding DNS islanding].


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


On the new joined DC, use the <code>10.99.0.1</code> IP of the existing DC as primary and the local <code>10.99.0.2</code> IP as secondary <code>nameserver</code> entry:
<u>/etc/resolv.conf on DC1:</u>
nameserver 10.99.0.2 # IP of the other DC as first entry
nameserver 10.99.0.1 # IP of this DC as second entry
search samdom.example.com


nameserver 10.99.0.1
<u>/etc/resolv.conf on DC2:</u>
nameserver 10.99.0.1 # IP of the other DC as first entry
nameserver 10.99.0.2 # IP of the new joined DC as secondary entry
nameserver 10.99.0.2 # IP of this DC as second entry
search samdom.example.com
search samdom.example.com


If you have more than two DCs, you can configure the nameserver IPs in crosswise direction. However you shouldn't set the local DNS as first entry!
If you are running more than two DCs, you can configure the IPs in crosswise direction.






= SYSVOL replication =


At the current stage of Samba, SYSVOL replication isn't implemented. Until it is, if you make any changes on that share, you will have to keep them in sync on all your Domain Controllers. An example of how to achieve this in an easy and automated way between Samba DCs, can be found in the [[Rsync_based_SysVol_replication_workaround|Rsync based SYSVOL replication workaround ]] documentation. For a workaround with a Windows DC, see [[Robocopy_based_SysVol_replication_workaround|Robocopy based SysVol replication workaround]].


Some pages on the internet recommend using a distributed filesystem like GlusterFS, Lustre, etc. to automatically mirror the content of the SYSVOL share. '''The Samba team strongly advises not to do this, because a cluster file system, used with Samba, requires a [[CTDB_Setup|CTDB setup]], that is <u>not compatible</u> with the Samba Active Directory Domain Controller!'''




= Sysvol Replication =


Samba currently does not support Sysvol replication. For unsupported workarounds, see [[SysVol_replication_(DFS-R)|Sysvol Replication]].




= Testing directory replication =


To check that replication is working correctly between your Domain Controllers, try adding/modifying e. g. a user on one DC using either the Samba command line tools (samba-tool, ldbedit) or the Windows GUI admin tools. Then check that the changes shows up within a few seconds on the new Domain Controller.




= Testing the Directory Replication =


To test that the directory replication works correctly, add for example a user on an existing DC and verify that it shows up automatically on the new joined DC.
== ldapcmp ==


An alternative to compare two directories is [[Samba-tool_ldapcmp|samba-tool ldapcmp]].
Optionally use the <code>ldapcmp</code> utility to compare two directories. For details, see [[Samba-tool_ldapcmp|samba-tool ldapcmp]].




Line 505: Line 450:
= Troubleshooting =
= Troubleshooting =


If you encounter any problems when using this documentation, see the [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]] page.
For troubleshooting, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].

Revision as of 16:19, 9 October 2016

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 Set up a Samba Active Directory Domain Controller.



Preconditions

  • Use a static IP address.
  • Verify that the host name in /etc/resolv.conf resolves to the network IP and not to 127.0.0.1 (localhost).
127.0.0.1     localhost.localdomain      localhost     DC2.samdom.example.com     DC2
10.99.0.2     DC2.samdom.example.com     DC2
  • If Samba was already configured on this host, remove any existing configuration and databases.
  • When joining a Windows Active Directory (AD), run the following tests on a Windows computer in the domain:
  • Verify that the forest functional level meets the Samba requirements:
> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
  msDS-Behavior-Version
  4
Minimum suported level: 2003 native (level 2)
Maximum suported level: 2008 R2 (level 4)
  • Downgrade the forest functional level to 2008 R2, if you are joining an AD with a higher level.
  • Verify that the directory schema meets the Samba requirements:
> dsquery * "CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com" -Scope Base -attr objectVersion
  objectVersion
  69
Samba <= 4.4: Maximum supported forest schema: 47 (Server 2008 R2)
Samba >= 4.5: Maximum supported forest schema: 69 (Server 2012 R2)



Installation

To install Samba:

Not all distributions currently provide packages with Active Directory (AD) domain controller (DC) support. For example, some distributions, such as Red Hat Enterprise Linux and Fedora, are based on MIT Kerberos, which is currently not supported by Samba. In this situation, compile Samba yourself or use packages with AD DC support.


Paths

If you built Samba yourself using the default directories, add the directories at the beginning of your $PATH variable: 

export PATH=/usr/local/samba/bin/:/usr/local/samba/sbin/:$PATH

For information how to set the path variable permanently, see your distribution's documentation.



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:


DNS Resolving

AD uses DNS in the background, such as locating other DCs and services. Thus configure your host to use a DNS server that is able to resolve the AD DNS zones.

Set the DNS server IP and AD DNS domain in your /etc/resolv.conf. For example: 

nameserver 10.99.0.1
search samdom.example.com

Some utilities, such as NetworkManager can overwrite manual changes in that file. Consult your distribution's documentation for information about how to configure name resolution permanently.

To verify the DNS settings, try resolving the host name of one of your existing Domain Controllers. For example: 

# host -t A DC1.samdom.example.com
DC1.samdom.example.com has address 10.99.0.1


Kerberos

Set the following settings in your Kerberos client configuration file /etc/krb5.conf: 

[libdefaults]
    dns_lookup_realm = false
    dns_lookup_kdc = true
    default_realm = SAMDOM.EXAMPLE.COM

To verify the settings use the kinit command to request a Kerberos ticket for the domain administrator: 

# kinit administrator
Password for administrator@SAMDOM.EXAMPLE.COM:

To list Kerberos tickets: 

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@SAMDOM.EXAMPLE.COM

Valid starting       Expires              Service principal
24.09.2015 19:56:55  25.09.2015 05:56:55  krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM
	renew until 25.09.2015 19:56:53



Joining the Active Directory as a Domain Controller

To join the domain samdom.example.com as a domain controller (DC) that additionally acts as a DNS server using the Samba internal DNS: 

# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator" --dns-backend=SAMBA_INTERNAL
Finding a writeable DC for domain 'samdom.example.com'
Found DC dc1.samdom.example.com
Password for [SAMDOM\administrator]:
workgroup is SAMDOM
realm is samdom.example.com
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Setting account password for DC2$
Enabling account
Calling bare provision
Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf
Provision OK for domain DN DC=samdom,DC=example,DC=com
Starting replication
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0]
Analyze and apply schema objects
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]
Replicating critical objects from the base DN of the domain
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]
Done with always replicated NC (base, config, schema)
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]
Committing SAM database
Sending DsReplicaUpdateRefs for all the replicated partitions
Setting isSynchronized and dsServiceName
Setting up secrets database
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC

See the samba-tool domain join --help command's output for further information.

Other frequently used parameters for the samba-tool domain join command:

  • --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 samba-tool to register the correct LAN IP address in the directory during the join.



Verify the DNS Entries

See Verifying and Creating a DC DNS Record.



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 Configure BIND as Back End for Samba AD.



Built-in Groups GID Mappings

Samba currently does not support Sysvol replication. If you plan to use a Sysvol Replication workaround, you have to ensure that all domain controllers (DC) use the same GID mappings for built-in groups:

  • Create a hot-backup of the /usr/local/samba/private/idmap.ldb file a 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:
# samba-tool ntacl sysvolreset



Start Samba

To start the Samba domain controller (DC), run: 

# samba

Samba does not include start scripts. For examples, see Samba Init-Script.



Directory Replication

A few minutes after the domain controller (DC) started, the connections with all other DCs are automatically established and the replication begins.

To verify the directory replication, run on a Samba DC: 

# samba-tool drs showrepl
Default-First-Site-Name\DC2
DSA Options: 0x00000001
DSA object GUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48
DSA invocationId: 7bdb135c-6868-4dd9-9460-33dea4b6b87b

==== INBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:46 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:46 2015 CEST

DC=DomainDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:45 2015 CEST

CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:46 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:46 2015 CEST

DC=ForestDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:45 2015 CEST

DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:45 2015 CEST

==== OUTBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=DomainDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

CN=Configuration,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=ForestDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection --
	Connection name: fb03f58b-1654-4a02-8e11-f0ea120b60cc
	Enabled        : TRUE
	Server DNS name : DC1.samdom.example.com
	Server DN name  : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
		TransportType: RPC
		options: 0x00000001
Warning: No NC replicated for Connection!

It can take several minutes until all connections are established. If the connections on existing Samba DCs to the Windows DC are not established within 15 minutes, start the replication manually. For details, see samba-tool drs replicate.

If you are seeing the warning "No NC replicated for Connection!", see FAQ: Warning: No NC replicated for Connection!.



Starting the BIND daemon

Before you start the BIND daemon, verify that the DNS directory partitions have been replicated: 

# samba-tool drs showrepl
...
==== INBOUND NEIGHBORS ====
...
DC=DomainDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:45 2015 CEST
...
DC=ForestDnsZones,DC=samdom,DC=example,DC=com
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
		Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
		0 consecutive failure(s).
		Last success @ Thu Sep 24 20:08:45 2015 CEST

If the replication is working, start the BIND daemon. See your distribution's documentation for information how to start a service.



Testing the Local DNS

Skip this step if you selected --dns-backend=NONE during the join.

Query the local DNS server to resolve the domain name samdom.example.com: 

# host -t A samdom.example.com localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:

samdom.example.com has address 10.99.0.1
samdom.example.com has address 10.99.0.2

The local DNS must answer with the IP addresses of all domain controllers (DC).

In case you receive no or a different result, review this documentation and check:

  • the system log files,
  • the Samba log files,
  • the BIND log files, if the BIND9_DLZ is used.



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.



Sysvol Replication

Samba currently does not support Sysvol replication. For unsupported workarounds, see Sysvol Replication.



Testing the Directory Replication

To test that the directory replication works correctly, add for example a user on an existing DC and verify that it shows up automatically on the new joined DC.

Optionally use the ldapcmp utility to compare two directories. For details, see samba-tool ldapcmp.



Troubleshooting

For troubleshooting, see Samba AD DC Troubleshooting.

Retrieved from "https://wiki.samba.org/index.php?title=Joining_a_Samba_DC_to_an_Existing_Active_Directory&oldid=12113"