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

From SambaWiki
m (Fix link)
(Major rewrite of the "Join an additional DC to an existing AD")
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
   
  +
The minimum number of Domain Controllers in an Active Directory forest is naturally one. However in an enterprise environment, it is always recommended, to add further DCs, to provide failure safety, high availibilty and load balancing. For failover reasons, at least two DCs are recommended. Depending on your network, there are different aspects, how many DCs are reasonable. A common scenario is, that one 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. So password changes, user creation, domain joins, etc. are still possible, even if other DCs are temporary not available due to e. g. network outtakes and users on each site can continue to authenticate and work with local servers without problems.
As well as the ability to join an Active Directory as a [[Setup_a_Samba_AD_Member_Server|Member Server]], it is also possible to join as a Domain Controller.
 
   
  +
In the times of NT4, a domain was hold by one Primary Domain Controller (PDC) and maybe additional Backup Domain Controllers (BDC). In an AD forest there's no such difference any more, what already indicates the name of the "master servers": They're simply called "Domain Controllers" (DC) and are equal. Please use only this term, when talking about an Active Directory, to avoid confusing, especially when asking for help.
The process of joining a Samba server to an existing domain is a bit different to [[Setup_a_Samba_Active_Directory_Domain_Controller|provisioning a new domain]]. This process is the equivalent of the 'dcpromo' command on Windows servers.
 
   
  +
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 st eps 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. we don't repeat here.
Please note that the following steps are the same - regardless of whether you are joining Samba to an existing Windows based domain or an existing Samba based domain.
 
   
  +
'''See the [[Server_information_used_in_documentation|server information used in documentation]] page for used pathes, hostnames, etc.'''
   
   
== Server information ==
 
   
This documentation uses the following configuration/settings:
 
   
'''Existing DC in the domain:'''
 
Hostname: DC1
 
IP: 10.99.0.1
 
DC is also a DNS server: yes
 
 
'''Domain information:'''
 
DNS Domain Name: samdom.example.com
 
NT4 Domain Name (NETBIOS): SAMDOM
 
Kerberos Realm: SAMDOM.EXAMPLE.COM
 
Domain Administrator: Administrator
 
Domain Administrator Password: passw0rd
 
 
'''DC additionally joined to the domain:'''
 
Hostname: DC2
 
IP Address: 10.99.0.2
 
Installation Directory: /usr/local/samba/
 
   
  +
= Preconditions =
   
  +
* Make sure, that your future DC uses a static IP address. DHCP can cause trouble, if the address changes.
   
  +
* Check your /etc/hosts for a correct resolution of the hostname to its IP:
== Versions ==
 
  +
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 a previous installation of Samba, if existing on that host.
This documentation is frequently updated to reflect the latest changes. Please see the [[Samba_Release_Planning|Samba Release Planning]] for more specifics.
 
   
  +
* If you AD forest is Windows driven, you need some further checks. The subsequent commands can be run from any Windows computer, that is part of the domain.
Please review the release notes for the version you have installed. It may contain important information, not yet reflected in this documentation.
 
   
  +
:* Forest functional level must be at least "2003 native" (Level 2 or higher):
   
  +
> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
  +
msDS-Behavior-Version
  +
2
   
  +
:* Forests schema must be maximum at version 47 (Server 2008 R2):
   
  +
> dsquery * "CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com" -Scope Base -attr objectVersion
 
  +
objectVersion
== Prerequisites ==
 
  +
47
 
* The domain must be at least at forest functional level „2003 native“ (not interim!), to join a Samba DC.
 
 
* The forests schema must be maximum at version 47 (Server 2008 R2). Later schemas are not supported at the moment and cause Samba to fail during the join. If your forest is Samba driven, the schema version is 47. Only if you have Windows DCs, this has to be checked, by running on a Windows DC:
 
 
> dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Base -attr objectVersion
 
   
   
Line 56: Line 44:
 
= Installation =
 
= Installation =
   
  +
Before you start, check the [[Operating system requirements|Operating System requirements]] for dependencies.
== Different ways to install ==
 
 
'''Always check the [[Operating system requirements|OS Requirements]] for dependencies and recommendations.'''
 
   
You have a few options to install Samba:
+
You have the following options to install Samba:
   
* [[Build_Samba_from_source|Build Samba]] yourself.
+
* [[Build_Samba_from_source|Build Samba]] yourself
   
  +
* Install [http://www.enterprisesamba.com/samba/ SerNet Enterprise Samba] packages
* Install [[Distribution_specific_package_installation|binary distribution packages]]. Make sure, that you use a recent Samba installation with Active Directory Domain Controller capabilities!
 
   
  +
* Install [[Distribution_specific_package_installation|distribution specific packages]]
:* Install from [http://www.enterprisesamba.com/samba/ SerNet Enterprise Samba] package.
 
  +
: Make sure, that you use a recent Samba and note, that not all distributions currently ship Samba packages, with Active Directory Domain Controller capabilities. One of the reasons 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.
   
   
Line 72: Line 59:
 
== Paths ==
 
== Paths ==
   
Take care when running Samba commands, if you also have a previous version of Samba installed! To avoid inadvertently running the wrong version of a program, you should consider putting the /usr/local/samba/bin/ and /usr/local/samba/sbin/“ directories at the <u>beginning of your $PATH variable</u>.
+
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
You can see what version of Samba and client tools, if any, is in your „$PATH“ variable by running:
 
  +
  +
To permanently add this to your system or user configuration, see your distributions documentation.
   
# '''samba -V'''
 
# '''smbclient -V'''
 
   
   
Line 86: Line 73:
 
== 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.
+
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 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 decited to run the internal or no DNS server on this host, no further steps are required.
   
If you plan to join the additional Domain Controller with BIND as the DNS backend, you have to [[Configure_BIND_as_backend_for_Samba_AD|setup BIND as AD backend]] first. If you use the internal or use no local DNS, no further steps are required.
 
   
   
  +
== 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.
== Verify /etc/hosts ==
 
   
Verify that the local hostname isn't resolved to 127.0.0.1 in /etc/hosts:
+
On Linux and Unixes, you usually configure DNS settings in /etc/resolv.conf:
   
  +
nameserver 10.99.0.1
127.0.0.1 localhost.localdomain localhost <strike>DC2.samdom.example.com DC2</strike>
 
10.99.0.2 DC2.samdom.example.com DC2
 
 
If the local hostname is resolved to 127.0.0.1, Samba would use this IP for the various DC DNS entries. This would prevent clients from reaching this Domain Controller!
 
 
 
 
== DNS resolving ==
 
 
Configure the host, you want to join as an additional Domain Controller, to use a DNS server that is able to resolve zones from the Active Directory. On Linux and Unixes, this is typically done by adding a „nameserver“ and „search domain“ entry to to /etc/resolv.conf:
 
 
nameserver <u>10.99.0.1</u>
 
 
search samdom.example.com
 
search samdom.example.com
   
Consult your distributions documentation for configuring the usage of a DNS server.
+
Some tools like NetworkManager may overwrite manual changes in that file. Please consult your distributions documentation for configuring name resolution.
   
 
To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:
 
To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:
   
# '''host -t A <u>DC1</u>.samdom.example.com'''
+
# host -t A DC1.samdom.example.com
 
DC1.samdom.example.com has address 10.99.0.1
 
DC1.samdom.example.com has address 10.99.0.1
   
Line 121: Line 97:
 
== Kerberos ==
 
== Kerberos ==
   
* Add the following content to /etc/krb5.conf:
+
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 128: Line 104:
 
default_realm = SAMDOM.EXAMPLE.COM
 
default_realm = SAMDOM.EXAMPLE.COM
   
* Verify the correct Kerberos setup by obtaining a ticket:
+
To verify the correct setup, use "kinit" to obtain a Kerberos ticket:
   
# '''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:
# '''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
 
 
 
Valid starting Expires Service principal
 
Valid starting Expires Service principal
09.11.2014 17:34:09 10.11.2014 03:34:09 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM
+
24.09.2015 19:56:55 25.09.2015 05:56:55 krbtgt/SAMDOM.EXAMPLE.COM@SAMDOM.EXAMPLE.COM
renew until 10.11.2014 17:34:07
+
renew until 25.09.2015 19:56:53
  +
  +
  +
  +
   
 
= Join the existing domain as a Domain Controller =
 
= Join the existing domain as a Domain Controller =
   
Before you start the joining, make yourself familiar with the parameters and options of „samba-tool domain join“:
+
Before you start, make yourself familiar with the possible parameters and options of the join process:
  +
  +
# samba-tool domain join --help
  +
   
  +
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.
# '''samba-tool domain join --help '''
 
   
  +
# samba-tool domain provision ..... --option="interfaces=lo eth0" --option="bind interfaces only=yes"
Expecially the following two options are required, if your future Domain Controllers have multiple NICs. Because „samba-tool“ would auto-choose one of the IPv4/IPv6 addresses, if multiple where found, it might be necessary to bind Samba to the desired interfaces using
 
   
--option="interfaces=lo eth0" --option="bind interfaces only=yes"
 
   
 
Join the existing domain (parameter explanation below):
 
Join the existing domain (parameter explanation below):
   
# '''samba-tool domain join samdom.example.com DC -Uadministrator --realm=samdom.example.com --dns-backend=BIND9_DLZ'''
+
# 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]: passw0rd
+
Password for [WORKGROUP\administrator]:
 
workgroup is SAMDOM
 
workgroup is SAMDOM
 
realm is samdom.example.com
 
realm is samdom.example.com
Line 166: Line 149:
 
Setting account password for DC2$
 
Setting account password for DC2$
 
Enabling account
 
Enabling account
Adding DNS account CN=dns-DC2,CN=Users,DC=samdom,DC=example,DC=com with dns/ SPN
 
Setting account password for dns-DC2
 
 
Calling bare provision
 
Calling bare provision
  +
Looking up IPv4 addresses
  +
Looking up IPv6 addresses
 
No IPv6 address will be assigned
 
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
 
Provision OK for domain DN DC=samdom,DC=example,DC=com
 
Starting replication
 
Starting replication
Line 181: Line 174:
 
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[28/0]
+
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[38/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[98/98] 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[395/297] linked_values[23/0]
+
Partition[DC=samdom,DC=example,DC=com] objects[387/287] 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
Line 190: Line 183:
 
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]
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[38/19] linked_values[0/0]
 
 
Committing SAM database
 
Committing SAM database
Sending DsReplicateUpdateRefs for all the replicated partitions
+
Sending DsReplicaUpdateRefs for all the replicated partitions
 
Setting isSynchronized and dsServiceName
 
Setting isSynchronized and dsServiceName
 
Setting up secrets database
 
Setting up secrets database
 
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
  +
  +
   
 
<u>Parameter explanations:</u>
 
<u>Parameter explanations:</u>
   
* Domain: AD Domain Name
+
* <u>Domain:</u> AD Domain Name
   
* Server Role: „DC“ for Domain Controller
+
* <u>Server Role:</u> "DC" for Domain Controller
   
* Username: Account that is allowed to join new Domain Controllers. Typically it is the Domain Administrator.
+
* <u>Username:</u> Account that is allowed to join new Domain Controllers. Typically it is at least the Domain Administrator.
   
* Realm: Kerberos Realm
+
* <u>Realm:</u> Kerberos Realm written in upper case.
   
* DNS backend: You have to choose whether to use the Internal DNS server (SAMBA_INTERNAL), BIND9 (BIND9_DLZ) or no DNS backend (NONE). The Internal DNS is the default and the best choice for simple DNS requirements. It doesn't need any further action. For complex DNS requirements, BIND9_DLZ is recommended. Don't use BIND9_FLATFILE! It's not documented or supported! See [[Configure_BIND_as_backend_for_Samba_AD|Configure BIND as backend for Samba AD]] for further information about using BIND. The DNS backend choice made during the provisioning isn't permanent. [[Changing_the_DNS_backend|It can be changed afterwards]].
+
* <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.
   
* Site: If you have setup Active Directory Sites, it's possible, to directly join a new DC into a specified AD site.
+
* <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.
   
   
Line 217: Line 211:
 
= Check DNS entries =
 
= Check DNS entries =
   
  +
'''This is an very important step, so don't skip it!'''
For a successful setup and failover purposes, it is required, that all important DNS records are added to the DNS zones. [[Check_and_fix_DNS_entries_on_DC_joins|Check, if the important DNS records are existing]] and if not (see [https://bugzilla.samba.org/show_bug.cgi?id=10928 Bug #10928]), [[Check_and_fix_DNS_entries_on_DC_joins|add them manually]]. '''Don't skip this step!'''
 
  +
  +
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]].
   
   
Line 225: Line 221:
 
= Adaptations for the BIND DNS backend =
 
= Adaptations for the BIND DNS backend =
   
This step can be skipped if the DC was joined with SAMBA_INTERNAL or without DNS backend.
+
Skip this step, if you're not using BIND as DNS backend
   
   
Line 231: Line 227:
 
== Workaround: Fix keytab permissions ==
 
== Workaround: Fix keytab permissions ==
   
This workaround is required, until [https://bugzilla.samba.org/show_bug.cgi?id=10881 Bug #10881] is solved for the version of Samba you're running!
+
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.
   
  +
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!
Fix permissions on the 'dns.keytab' file, to allow BIND to read this file:
 
   
  +
Fix permissions on the "dns.keytab" file, to allow BIND to read this file:
# '''chmod 640 /usr/local/samba/private/dns.keytab'''
 
# '''chgrp named /usr/local/samba/private/dns.keytab'''
 
   
  +
# chmod 640 /usr/local/samba/private/dns.keytab
''Note: If you use Samba packages (Distro or from other sources), make sure that the account BIND uses, is able to reach the dns.keytab file. Some package installations set too restrictive permissions on the folders.''
 
  +
# 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.''
Otherwise, BIND will not able to update your zone(s)! One of the results is, that 'samba_dnsupdate' can't add e. g. the important DNS entries, that clients use, to locate the new DC. In case of an failure of your other DC, domain logons using your new DC wouldn't be possible!
 
   
   
   
== Enable the BIND9_DLZ module, suitable to the BIND version==
+
== Enable the correct BIND9_DLZ module ==
   
Make sure, that the correct BIND9_DLZ module for your BIND version is enabled in /usr/local/samba/private/named.conf. Uncomment the module for your BIND version and comment the other:
+
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" {
 
dlz "AD DNS Zone" {
Line 254: Line 250:
 
# For BIND 9.9.0
 
# For BIND 9.9.0
 
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";
 
# 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";
 
};
 
};
   
Line 264: Line 263:
 
= GID mappings of built-in groups =
 
= GID mappings of built-in groups =
   
There are current issues with GID mappings of built-in groups. The GIDs of groups owning files and directories on in the sysvol folder may differ between Domain Controllers. Currently Samba doesn't provide a replication of these GIDs.
+
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, if you encounter any problems:
+
Use the following workaround:
   
  +
* Create a hot-backup of "idmap.ldb" on one of your other Samba Domain Controllers:
* Shutdown Samba on the new joined Domain Controller.
 
   
  +
# tdbbackup -s .bak /usr/local/samba/private/idmap.ldb
* Create a hot-backup of idmap.ldb on the first Domain Controller:
 
   
  +
* 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.
# '''tdbbackup -s .bak /usr/local/samba/private/idmap.ldb'''
 
   
* Move the backup file „/usr/local/samba/private/idmap.ldb.bak“ to "/usr/local/samba/private" on the newly joined Domain Controller and remove the .bak suffix, this will replace the original file.
+
* Reset the ACLs on the local SYSVOL folder of the new joined Domain Controller:
   
  +
# samba-tool ntacl sysvolreset
* Start Samba on the new joined Domain Controller again.
 
 
* Reset the ACLs on the local sysvol folder of the new joined Domain Controller:
 
 
# '''samba-tool ntacl sysvolreset'''
 
   
   
Line 288: Line 283:
 
= 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 Active Directory Domain Controller in "standard" mode, which is suitable for production use, run
   
# '''samba'''
+
# samba
   
 
Samba doesn't yet have init scripts included. You can find examples on the [[Samba4/InitScript|Samba Init-Script]] page.
 
Samba doesn't yet have init scripts included. You can find examples on the [[Samba4/InitScript|Samba Init-Script]] page.
 
   
   
Line 301: Line 295:
 
= Directory replication =
 
= Directory replication =
   
A few minutes after you have started Samba, connections with other DC will be established automatically.
+
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
 
Default-First-Site-Name\DC2
 
DSA Options: 0x00000001
 
DSA Options: 0x00000001
DSA object GUID: df4bdd8c-abc7-4779-b01e-4dd4553ca3e9
+
DSA object GUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48
DSA invocationId: 8e30d69f-c20f-4744-9833-5b050e611375
+
DSA invocationId: 7bdb135c-6868-4dd9-9460-33dea4b6b87b
 
 
 
==== INBOUND NEIGHBORS ====
 
==== INBOUND NEIGHBORS ====
 
 
 
CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
 
CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful
+
Last attempt @ Thu Sep 24 20:08:46 2015 CEST was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ Sun Nov 9 19:56:07 2014 CET
+
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
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sun Nov 9 19:56:06 2014 CET was successful
+
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ Sun Nov 9 19:56:06 2014 CET
+
Last success @ Thu Sep 24 20:08:45 2015 CEST
 
 
 
CN=Configuration,DC=samdom,DC=example,DC=com
 
CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful
+
Last attempt @ Thu Sep 24 20:08:46 2015 CEST was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ Sun Nov 9 19:56:07 2014 CET
+
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
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sun Nov 9 19:56:07 2014 CET was successful
+
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ Sun Nov 9 19:56:07 2014 CET
+
Last success @ Thu Sep 24 20:08:45 2015 CEST
 
 
 
DC=samdom,DC=example,DC=com
 
DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sun Nov 9 19:56:13 2014 CET was successful
+
Last attempt @ Thu Sep 24 20:08:45 2015 CEST was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ Sun Nov 9 19:56:13 2014 CET
+
Last success @ Thu Sep 24 20:08:45 2015 CEST
 
 
 
==== OUTBOUND NEIGHBORS ====
 
==== OUTBOUND NEIGHBORS ====
 
 
 
CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
 
CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
+
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ NTTIME(0)
+
Last success @ NTTIME(0)
 
 
 
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
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
+
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ NTTIME(0)
+
Last success @ NTTIME(0)
 
 
 
CN=Configuration,DC=samdom,DC=example,DC=com
 
CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
+
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ NTTIME(0)
+
Last success @ NTTIME(0)
 
 
 
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
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
+
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ NTTIME(0)
+
Last success @ NTTIME(0)
 
 
 
DC=samdom,DC=example,DC=com
 
DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
+
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
+
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
+
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
+
0 consecutive failure(s).
Last success @ NTTIME(0)
+
Last success @ NTTIME(0)
 
 
 
==== KCC CONNECTION OBJECTS ====
 
==== KCC CONNECTION OBJECTS ====
 
 
 
Connection --
 
Connection --
Connection name: 5745d481-1d26-48f4-ab65-273263e28a45
+
Connection name: fb03f58b-1654-4a02-8e11-f0ea120b60cc
Enabled : TRUE
+
Enabled : TRUE
Server DNS name : DC1.samdom.example.com
+
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
+
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
+
TransportType: RPC
options: 0x00000001
+
options: 0x00000001
 
Warning: No NC replicated for Connection!
 
Warning: No NC replicated for Connection!
   
'''Depending on your replication settings - if defined - 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]].
+
'''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]].
   
''Note about the„Warning: No NC replicated for Connection!“ line: It can be safely ignored. See [[FAQ#Message:_Warning:_No_NC_replicated_for_Connection.21|FAQ: Message: Warning: No NC replicated for Connection!]]''
+
''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!]]''
   
   
Line 402: Line 396:
   
   
  +
= Start BIND =
   
  +
Skip this step if not using BIND9_DLZ as DNS backend.
   
  +
Check that the DNS partitions are already replicated:
= Start BIND =
 
   
  +
# samba-tool drs showrepl
Please check (samba-tool drs showrepl), that the DC=ForestDnsZones,DC=samdom,DC=example,DC=com and DC=DomainDnsZones,DC=samdom,DC=example,DC=com partitions are already replicated!
 
  +
...
  +
==== 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 so, it's time to start BIND now, if you have a BIND9_DLZ backend.
+
If replication is working, start BIND.
   
   
Line 414: Line 426:
   
   
  +
= Testing the local DNS =
= Follow-Up on /etc/resolv.conf =
 
   
  +
Skip this step, if you have choosen "NONE" as DNS backend during the join.
Now the DNS on your new Domain Controller is working, it is recommended to add it to /etc/resolv.conf.
 
   
  +
To test that the local DNS is working properly, run the following commands on the new DC, to query the local DNS
It is best practice to have more than one nameserver entry in the Domain Controllers /etc/resolv.conf! This is in case of a dns failure where the DC cannot resolve the AD zones, this would cause several other services that rely on DNS to fail e.g. directory replication.
 
   
  +
$ host -t A dc1.samdom.example.com localhost
So you should always rely on at least two DNS servers, that are both able to resolve the AD DNS zones.
 
  +
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.
'''/etc/resolv.conf on DC2'''
 
nameserver 10.99.0.1
 
nameserver 127.0.0.1
 
search samdom.example.com
 
 
'''/etc/resolv.conf on DC1'''
 
nameserver 10.99.0.2
 
nameserver 127.0.0.1
 
search samdom.example.com
 
   
If you have more than two Domain Controllers, then you should think in a circle. The following example supposes an additional Domain Controller DC3 to have the IP 10.99.0.3:
 
   
  +
'''/etc/resolv.conf on DC1'''
 
  +
nameserver 10.99.0.2
 
  +
nameserver 10.99.0.3
 
  +
= Best practice: DNS configuration on DCs =
  +
  +
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!
  +
  +
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].
  +
  +
Example configuration:
  +
  +
<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
 
search samdom.example.com
  +
 
'''/etc/resolv.conf on DC2'''
+
<u>/etc/resolv.conf on DC2:</u>
nameserver 10.99.0.3
+
nameserver 10.99.0.1 # IP of the other DC as first entry
nameserver 10.99.0.1
+
nameserver 10.99.0.2 # IP of this DC as second entry
search samdom.example.com
 
 
'''/etc/resolv.conf on DC3'''
 
nameserver 10.99.0.1
 
nameserver 10.99.0.2
 
 
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!
This will prevent the DC's suffering [http://retrohack.com/a-word-or-two-about-dns-islanding/ DNS islanding].
 
  +
  +
  +
  +
  +
  +
= 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.
= SysVol replication =
 
   
  +
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!'''
Currently replication of the SysVol share isn't implemented. 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 automatically, is provided in the [[Rsync_based_SysVol_replication_workaround|SysVol Replication]] documentation.
 
   
   
Line 462: Line 482:
 
= Testing directory replication =
 
= Testing directory replication =
   
To check that replication is working correctly between your two domain controllers, try adding/modifying e. g. a user on one DC using either the Samba command line tools or the Windows GUI admin tools. Then check that the changes shows up within a few seconds on the other Domain Controller.
+
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.
   
   
Line 468: Line 488:
 
== ldapcmp ==
 
== ldapcmp ==
   
You may wish to use [[Samba-tool_ldapcmp|samba-tool ldapcmp]] to verify that the same data
+
An alternative to compare two directories is [[Samba-tool_ldapcmp|samba-tool ldapcmp]].
is being served from all Domain Controllers.
 
   
   
Line 477: Line 496:
 
= Troubleshooting =
 
= Troubleshooting =
   
If you encounter any problems when using the documentation, see the [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]] page.
+
If you encounter any problems when using this documentation, see the [[Samba_AD_DC_Troubleshooting|Samba AD DC Troubleshooting]] page.

Revision as of 18:13, 24 September 2015

Introduction

The minimum number of Domain Controllers in an Active Directory forest is naturally one. However in an enterprise environment, it is always recommended, to add further DCs, to provide failure safety, high availibilty and load balancing. For failover reasons, at least two DCs are recommended. Depending on your network, there are different aspects, how many DCs are reasonable. A common scenario is, that one 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. So password changes, user creation, domain joins, etc. are still possible, even if other DCs are temporary not available due to e. g. network outtakes and users on each site can continue to authenticate and work with local servers without problems.

In the times of NT4, a domain was hold by one Primary Domain Controller (PDC) and maybe additional Backup Domain Controllers (BDC). In an AD forest there's no such difference any more, what already indicates the name of the "master servers": They're simply called "Domain Controllers" (DC) and are equal. Please use only this term, when talking about an Active Directory, to avoid confusing, especially when asking for help.

The process of joining a new Samba DC to an existing AD differs in some points to provisioning a new domain. The following st eps 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 documentation before you continue. It contains some basic information about the environment, command explanation, etc. we don't repeat here.

See the server information used in documentation page for used pathes, hostnames, etc.



Preconditions

  • Make sure, that your future DC uses a static IP address. 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 a previous installation of Samba, if existing on that host.
  • If you AD forest is Windows driven, you need some further checks. The subsequent commands can be run from any Windows computer, that is part of the domain.
  • Forest functional level must be at least "2003 native" (Level 2 or higher):
> dsquery * "CN=Partitions,CN=Configuration,DC=samdom,DC=example,DC=com" -scope base -attr msDS-Behavior-Version
  msDS-Behavior-Version
  2
  • Forests schema must be maximum at 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 for dependencies.

You have the following options to install Samba:

Make sure, that you use a recent Samba and note, that not all distributions currently ship Samba packages, with Active Directory Domain Controller capabilities. One of the reasons 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

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

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 DNS backend on the new Domain Controller, you have to 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 decited to run the internal or no DNS server on this host, no further steps are required.


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.

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.

To verify a correct name resolution, try resolving the hostname of one of your existing Domain Controllers:

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


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:

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

To verify the correct setup, use "kinit" to obtain a Kerberos ticket:

# kinit administrator
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:

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



Join the existing domain 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


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.

# samba-tool domain provision ..... --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'
Found DC dc1.samdom.example.com
Password for [WORKGROUP\administrator]:
workgroup is SAMDOM
realm is samdom.example.com
checking sAMAccountName
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[38/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[387/287] 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[41/41] 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


Parameter explanations:

  • Domain: AD Domain Name
  • Server Role: "DC" for Domain Controller
  • Username: Account that is allowed to join new Domain Controllers. Typically it is at least the Domain Administrator.
  • Realm: Kerberos Realm written in upper case.
  • DNS backend: Supported DNS backends are the Samba internal DNS server and 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 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 for further setup information. If you later find out that your DNS backend choice doesn't fit your needs, you can 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.
  • Site: If you have setup Active Directory Sites, it's possible, to join a new DC directly into a specified AD site by using the "--site=SITE" parameter.



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, if they are existing and if not (Bug #10928), add them manually.



Adaptations for the BIND DNS backend

Skip this step, if you're not using BIND as DNS backend


Workaround: Fix keytab permissions

This workaround is required, until Bug #10881 is solved for the version of Samba you had used for the join.

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!

Fix permissions on the "dns.keytab" file, to allow BIND to read this file:

# 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 runs under, is able to access the dns.keytab file. Some package installations set to 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

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.
  • Reset the ACLs on the local SYSVOL folder of the new joined Domain Controller:
# samba-tool ntacl sysvolreset



Start Samba

To start the Samba Active Directory Domain Controller in "standard" mode, which is suitable for production use, run

# samba

Samba doesn't yet have init scripts included. You can find examples on the 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
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!

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.

Note: The message "Warning: No NC replicated for Connection!" can be safely ignored. See FAQ: Message: Warning: No NC replicated for Connection!



Start BIND

Skip this step if not using BIND9_DLZ as DNS backend.

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

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
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.



Best practice: DNS configuration on DCs

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!

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 DNS islanding.

Example configuration:

/etc/resolv.conf on DC1:

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

/etc/resolv.conf on DC2:

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!



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 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, that is not compatible with the Samba Active Directory Domain Controller!



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.


ldapcmp

An alternative to compare two directories is samba-tool ldapcmp.



Troubleshooting

If you encounter any problems when using this documentation, see the Samba AD DC Troubleshooting page.