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

m (Local DNS server: grammar & typo)
m (/* added warning about dns server)
 
(75 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
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.
+
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|Setting up Samba as an Active Directory Domain Controller]].
  
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.
+
{{Imbox
 +
| type = warning
 +
| text = Do not provision a Computer as a Samba AD DC, then try to join it to an existing AD domain. This will not work, you only need to run the <code>samba-tool domain join</code> command to join a Computer to the existing AD domain.  
 +
}}
  
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.
+
{{Imbox
 +
| type = warning
 +
| text = If you are joining a Samba as a DC to an existing Windows AD domain that was provisioned as a Windows 2003 (or earlier) DC, you must ensure that it is running a domain integrated DNS server. This dns server must be configured with 2008 behaviour.  
 +
}}
  
'''See the [[Server_information_used_in_documentation|server information used in documentation]] page for paths used, hostnames, etc.'''
+
{{Imbox
 +
| 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 difference 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.
 +
}}
  
= Preconditions =
 
  
* Make sure that your future DC uses a static IP address. Using one set by DHCP can cause trouble, if the address changes.
 
  
* Check your /etc/hosts for a correct resolution of the hostname to its IP:
 
127.0.0.1    localhost.localdomain      localhost
 
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!
 
  
* Remove any previous existing installation of Samba on the host.
 
  
* If your AD forest is Windows driven, further checks are required. The following commands can be run from any Windows domain computer.
+
= Preparing the Installation =
  
:* Forest functional level must be at least "2003 native" (Level 2 or higher):
+
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Preparing_the_Installation|Preparing the Installation]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.
  
> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
 
  msDS-Behavior-Version
 
  2
 
  
:* The maximum Forest schema is version 47 (Server 2008 R2):
 
  
> dsquery * "CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com" -Scope Base -attr objectVersion
 
  objectVersion
 
  47
 
  
= Installation =
 
  
Before you start, check the [[Operating system requirements|Operating System requirements]] for dependencies.
+
= Installing Samba =
  
You have the following options to install Samba:
+
For details, see [[Installing_Samba|Installing Samba]].
  
* [[Build_Samba_from_source|Build Samba]] yourself
+
{{Imbox
 +
| type = note
 +
| text = Install a maintained Samba version. For details, see [[Samba_Release_Planning|Samba Release Planning]].
 +
}}
  
* Install [http://www.enterprisesamba.com/samba/ SerNet Enterprise Samba] packages
 
  
* 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.
 
  
  
  
== Paths ==
+
= Preparing the Host for Joining the Domain =
 
 
You should consider putting the directories "/usr/local/samba/bin/" and "/usr/local/samba/sbin/" at the beginning of your $PATH variable:
 
 
 
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.
 
 
 
= Preparing the host for the domain join =
 
  
 
== 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:
 
 
== DNS resolving ==
 
  
Many things in an Active Directory, not only the join process, rely on DNS. Therefore it is necessary, that the new host is able to resolve AD DNS zones. To accomplish, we use a DNS server on one of your existing Domain Controllers.
+
* For the <code>BIND9_DLZ</code> back end, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]]. Finish this task before you start the Samba DC service.
 +
* For the internal DNS no further actions are required.
  
On Linux and Unixes, you usually configure DNS settings in /etc/resolv.conf:
 
  
nameserver 10.99.0.1
 
search samdom.example.com
 
  
Some tools like NetworkManager may overwrite manual changes in that file. Please consult your distributions documentation for configuring name resolution.
+
== Configuring DNS ==
  
To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:
+
For details, see [[Linux_and_Unix_DNS_Configuration|Linux and Unix DNS Configuration]].
  
# host -t A DC1.samdom.example.com
+
{{Imbox
DC1.samdom.example.com has address 10.99.0.1
+
| type = note
 +
| text = The 'nameserver' you set in '/etc/resolv.conf' must be an AD DC, otherwise the join will not be able to find the KDC.  
 +
}}
  
  
Line 83: Line 67:
 
== Kerberos ==
 
== Kerberos ==
  
Kerberos, which is also a very important part in an AD, needs to be configured next. Add the following content to /etc/krb5.conf:
+
Set the following settings in your Kerberos client configuration file <code>/etc/krb5.conf</code>:
  
 
  [libdefaults]
 
  [libdefaults]
Line 90: Line 74:
 
     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:
  
Depending on your distribution, "kinit" may just return you to a prompt when successful. To verify that you had received a Kerberos ticket, run:
+
To list Kerberos tickets:
  
 +
# 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 108: Line 93:
  
  
= Join the existing domain as a Domain Controller =
+
= Joining the Active Directory as a Domain Controller =
 
 
Before you start, make yourself familiar with the possible parameters and options of the join process:
 
  
# samba-tool domain join --help
+
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:
  
 +
There are three authentication methods you can use, Username & Password or two kerberos methods (the kerberos methods depend on running <code>kinit</code> as an admin user).
  
If your new Domain Controller has multiple network interfaces, the following two "samba-tool" options are required, to prevent that tool to auto-choose one of the IPv4/IPv6 addresses of the interfaces. Furthermore it is necessary to bind Samba to the desired interface.  
+
Username & Password:
 +
# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator"
  
  # samba-tool domain provision ..... --option="interfaces=lo eth0" --option="bind interfaces only=yes"
+
Or:
 +
  # samba-tool domain join samdom.example.com DC -k yes
  
 +
Or:
 +
# samba-tool domain join samdom.example.com DC --krb5-ccache=/tmp/krb5cc_0
  
Join the existing domain (parameter explanation below):
+
Using any of the above, should result in output similar to this:
  
# 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 160: Line 146:
 
  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 175: Line 161:
 
  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 parameters frequently used with the <code>samba-tool domain join</code> command:
  
<u>Parameter explanations:</u>
+
* <code>--dns-backend=NAMESERVER-BACKEND</code>: Use the supplied DNS server backend. Valid options are <code>SAMBA_INTERNAL</code> or <code>BIND9_DLZ</code>, unless you want to use Bind9, there is no need to supply this option.
 +
:: If you use the internal DNS server, you will not be asked for a forwarder and the one in /etc/resolv.conf will not be obtained automatically. You must supply one with <code>--option="dns forwarder=forwarder_ipaddress"</code>.
 +
 +
* <code>--site=SITE</code>: Directly join the host as DC to a specific [[Active_Directory_Sites|Active Directory Site]].
  
* <u>Domain:</u> AD Domain Name
+
* <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 the <code>samba-tool</code> command to register the correct LAN IP address in the directory during the join.
  
* <u>Server Role:</u> "DC" for Domain Controller
+
{{Imbox
 +
| type = note
 +
| text = If the other DCs are Samba DCs and were provisioned with <code>--use-rfc2307</code>, you Should add <code>--option='idmap_ldb:use rfc2307 = yes'</code> to the join command
 +
}}
  
* <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 if it's default, we used this parameter, to show users taking a different decission, how to set. The internal DNS is the best choice if you're not having 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 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]]. Don't use BIND9_FLATFILE as DNS backend. It isn't documented and 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.
 
  
* <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.
 
  
 +
= Verifying the DNS Entries =
  
 +
If you join a Samba DC that runs Samba 4.7 and later, <code>samba-tool</code> created all required DNS entries automatically. To manually create the records on an earlier version, see [[Verifying_and_Creating_a_DC_DNS_Record|Verifying and Creating a DC DNS Record]].
  
  
  
= Check DNS entries =
 
  
'''This is an very important step, so don't skip it!'''
 
  
For a working replication, it is required, that all DC related DNS records were added to the DNS zones during the join. [[Check_and_fix_DNS_entries_on_DC_joins|Check, if they are existing]] and if not ([https://bugzilla.samba.org/show_bug.cgi?id=10928 Bug #10928]), [[Check_and_fix_DNS_entries_on_DC_joins|add them manually]].
+
= Configuring the BIND9_DLZ DNS Back End =
  
 +
If you selected the <code>BIND9_DLZ</code> DNS back end during the domain join, set up the BIND configuration. For details, see [[BIND9_DLZ_DNS_Back_End|BIND9_DLZ DNS Back End]].
  
  
  
  
= Adaptations for the BIND DNS backend =
 
  
Skip this step, if you're not using BIND as DNS backend
+
= Built-in User & Group ID Mappings =
 +
{{:SysVol replication (DFS-R)}}
  
  
 +
To use a Sysvol Replication workaround, all domain controllers (DC) must use the same ID mappings for built-in users and groups.
  
== Workaround: Fix keytab permissions ==
+
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:  
  
This workaround is required, until [https://bugzilla.samba.org/show_bug.cgi?id=10881 Bug #10881] is solved for the version of Samba you had used for the join.
+
* Create a hot-backup of the <code>/usr/local/samba/private/idmap.ldb</code> file on the existing DC:
  
Wrong keytab permissions will prevent BIND to update 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!
+
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb
  
Fix permissions on the "dns.keytab" file, to allow BIND to read this file:
+
: This creates a backup file <code>/usr/local/samba/private/idmap.ldb.bak</code>.
  
# chmod 640 /usr/local/samba/private/dns.keytab
+
* 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.
# chgrp named /usr/local/samba/private/dns.keytab
 
  
''Note: If you use Samba packages, make sure that the account BIND runs under, is able to access the dns.keytab file. Some package installations set to restrictive permissions on higher folders.''
+
* Run <code>net cache flush</code> on the new DC.
  
 +
* You will now need to sync Sysvol to the new DC.
  
 +
* Reset the Sysvol folder's file system access control lists (ACL) on the new DC:
  
== Enable the correct BIND9_DLZ module ==
+
# samba-tool ntacl sysvolreset
  
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).
 
  
  
 +
= Starting the Samba Service =
  
 +
To start the <code>samba</code> Samba Active Directory (AD) domain controller (DC) service manually, enter:
  
 +
# samba
  
= GID mappings of built-in groups =
+
Samba does not provide System V init scripts, <code>systemd</code>, <code>upstart</code>, or other services configuration files.
 +
* If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.
 +
* If you built Samba, see [[Managing_the_Samba_AD_DC_Service|Managing the Samba AD DC Service]].
  
There are current 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. Currently Samba doesn't provide a replication of these GIDs!
 
  
Use the following workaround:
 
  
* 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.
+
= Verifying Directory Replication =
  
* Reset the ACLs on the local SYSVOL folder of the new joined Domain Controller:
+
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.
  
# samba-tool ntacl sysvolreset
+
For details about how to verify that the directory replication works correctly, see [[Verifying the Directory Replication Statuses]].
  
 +
{{Imbox
 +
| type = note
 +
| text = To optimize replication latency and cost, the KCC in Samba 4.5 and later no longer creates a fully-meshed replication topology between all DCs. For further details, see [[The Samba KCC]].
 +
}}
  
  
  
  
= Start Samba =
 
  
To start the Samba Active Directory Domain Controller in "standard" mode, which is suitable for production use, run
+
= Starting BIND =
  
# samba
+
Before you start the BIND daemon, verify that the DNS directory partitions have been successfully replicated:
 
 
Samba doesn't yet have init scripts included. You can find examples on the [[Samba4/InitScript|Samba Init-Script]] page.
 
 
 
 
 
 
 
 
 
 
 
= Directory replication =
 
 
 
A few minutes after you have started Samba, connections with other DCs will be established automatically.
 
  
 
  # samba-tool drs showrepl
 
  # 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 ====
 
  ==== 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
 
  DC=DomainDnsZones,DC=samdom,DC=example,DC=com
 
  Default-First-Site-Name\DC1 via RPC
 
  Default-First-Site-Name\DC1 via RPC
Line 304: Line 268:
 
  0 consecutive failure(s).
 
  0 consecutive failure(s).
 
  Last success @ Thu Sep 24 20:08:45 2015 CEST
 
  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
 
  DC=ForestDnsZones,DC=samdom,DC=example,DC=com
 
  Default-First-Site-Name\DC1 via RPC
 
  Default-First-Site-Name\DC1 via RPC
Line 318: Line 275:
 
  0 consecutive failure(s).
 
  0 consecutive failure(s).
 
  Last success @ Thu Sep 24 20:08:45 2015 CEST
 
  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!
 
  
'''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 - even not after several minutes - you can force the replication (generally not necessary!). See [[Samba-tool_drs_replicate|samba-tool drs replicate]].
+
If the replication works correctly, start the BIND service. See your distribution's documentation for information how to start a service.
  
''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!]]''
 
  
  
  
  
 +
= Testing your Samba AD DC =
  
= Start BIND =
+
== Verifying the File Server ==
  
Skip this step if not using BIND9_DLZ as DNS backend.
+
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_the_File_Server|Verifying the File Server]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.
  
Check that the DNS partitions are already 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 replication is working, start BIND.
+
== Testing the Local DNS Server ==
  
 +
Skip this step if you selected <code>--dns-backend=NONE</code> during the join.
  
 +
Query the local DNS server to resolve the domain name <code>samdom.example.com</code>:
  
 +
# 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 resolves the domain name to the IP addresses of all domain controllers (DC).
  
= Testing the local DNS =
+
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.
  
Skip this step, if you have choosen "NONE" as DNS backend 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
 
  
$ host -t A dc1.samdom.example.com localhost
+
== Verifying Kerberos ==
Using domain server:
 
Name: localhost
 
Address: 127.0.0.1#53
 
Aliases:
 
 
dc1.samdom.example.com has address 10.99.0.1
 
  
If you receive any errors, check your system logs to locate the problem.
+
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_Kerberos|Verifying Kerberos]] in the [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller|Setting up Samba as an Active Directory Domain Controller]] documentation.
  
  
Line 432: Line 322:
  
  
= Best practice: DNS configuration on DCs =
+
= DNS Configuration on Domain Controllers =
  
Not just on Workstations 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, like 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.
  
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 the DC as the primary name server. For example:
  
Example configuration:
+
On the new joined DC, use the local <code>10.99.0.2</code> IP as primary <code>nameserver</code> entry:
  
<u>/etc/resolv.conf on DC1:</u>
+
  nameserver 10.99.0.2
  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
 
  search samdom.example.com
  
<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 this DC as second entry
 
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!
 
  
  
  
 +
= Configuring Time Synchronisation =
 +
 +
Kerberos requires a synchronised time on all domain members. For further details and how to set up the <code>ntpd</code> service, see [[Time_Synchronisation|Time Synchronisation]].
 +
 +
 +
 +
 +
 +
= Configuring Winbindd on a Samba AD DC =
 +
 +
''Optional''. For details, see [[Configuring_Winbindd_on_a_Samba_AD_DC|Configuring Winbindd on a Samba AD DC]].
 +
 +
 +
 +
 +
 +
= Using the Domain Controller as a File Server =
 +
 +
For details, see [[Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Using_the_Domain_Controller_as_a_File_Server|Using the Domain Controller as a File Server]].
  
  
= SYSVOL replication =
 
  
At the current stage of Samba, SYSVOL replication isn't implemented. Until that, if you make any changes on that share, you have to keep them in sync on all your Domain Controllers. An example, how to achieve this on an easy and automated way, you find in the [[Rsync_based_SysVol_replication_workaround|Rsync based SYSVOL replication workaround ]] documentation.
 
  
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 advices not to do, 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 automatically replicate Sysvol, you must use some other form of replication. For community supported workarounds, see [[SysVol_replication_(DFS-R)|Sysvol Replication]].
  
 +
{{Imbox
 +
| type = note
 +
| text = If there are more than the default GPOs in Sysvol on the other DC(s), you must sync Sysvol to the new DC, <code>samba-tool ntacl sysvolreset</code> will throw an error if you do not.
 +
}}
  
  
= 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 =
  
== ldapcmp ==
+
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 newly joined DC.
  
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 482: Line 386:
 
= Troubleshooting =
 
= Troubleshooting =
  
If you encounter any problems when using this documentation, see the [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]] page.
+
For further details, see [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]].
 +
 
 +
 
 +
 
 +
 
 +
 
 +
----
 +
[[Category:Active Directory]]
 +
[[Category:Domain Control]]

Latest revision as of 09:35, 8 September 2019

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.



Preparing the Installation

For details, see Preparing the Installation in the Setting up Samba as an Active Directory Domain Controller documentation.



Installing Samba

For details, see 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.
  • For the internal DNS no further actions are required.


Configuring DNS

For details, see Linux and Unix DNS Configuration.


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:

There are three authentication methods you can use, Username & Password or two kerberos methods (the kerberos methods depend on running kinit as an admin user).

Username & Password:

# samba-tool domain join samdom.example.com DC -U"SAMDOM\administrator"

Or:

# samba-tool domain join samdom.example.com DC -k yes

Or:

# samba-tool domain join samdom.example.com DC --krb5-ccache=/tmp/krb5cc_0

Using any of the above, should result in output similar to this:

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 parameters frequently used with the samba-tool domain join command:

  • --dns-backend=NAMESERVER-BACKEND: Use the supplied DNS server backend. Valid options are SAMBA_INTERNAL or BIND9_DLZ, unless you want to use Bind9, there is no need to supply this option.
If you use the internal DNS server, you will not be asked for a forwarder and the one in /etc/resolv.conf will not be obtained automatically. You must supply one with --option="dns forwarder=forwarder_ipaddress".
  • --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.



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

Samba in its current state doesn't support SysVol replication via DFS-R (Distributed File System Replication) or the older FRS (File Replication Service) used in Windows Server 2000/2003 for Sysvol replication.

We Currently advise administrators to use one of the following workarounds:


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.
  • Run net cache flush on the new DC.
  • You will now need to sync Sysvol to the new DC.
  • Reset the Sysvol folder's file system access control lists (ACL) on the new DC:
# samba-tool ntacl sysvolreset



Starting the Samba Service

To start the samba Samba Active Directory (AD) domain controller (DC) service manually, enter:

# samba

Samba does not provide System V init scripts, systemd, upstart, or other services configuration files.

  • If you installed Samba using packages, use the script or service configuration file included in the package to start Samba.
  • If you built Samba, see Managing the Samba AD DC Service.



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.

For details about how to verify that the directory replication works correctly, see Verifying the Directory Replication Statuses.



Starting BIND

Before you start the BIND daemon, verify that the DNS directory partitions have been successfully 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 works correctly, start the BIND service. See your distribution's documentation for information how to start a service.



Testing your Samba AD DC

Verifying the File Server

For details, see Verifying the File Server in the Setting up Samba as an Active Directory Domain Controller documentation.


Testing the Local DNS Server

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 resolves the domain name to 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.


Verifying Kerberos

For details, see Verifying Kerberos in the Setting up Samba as an Active Directory Domain Controller documentation.



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.

Set the local IP of the DC as the primary name server. For example:

On the new joined DC, use the local 10.99.0.2 IP as primary nameserver entry:

nameserver 10.99.0.2
search samdom.example.com



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.



Configuring Winbindd on a Samba AD DC

Optional. For details, see Configuring Winbindd on a Samba AD DC.



Using the Domain Controller as a File Server

For details, see Using the Domain Controller as a File Server.



Sysvol Replication

Samba currently does not automatically replicate Sysvol, you must use some other form of replication. For community supported 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 newly joined DC.

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



Troubleshooting

For further details, see Samba AD DC Troubleshooting.