BIND9 DLZ DNS Back End: Difference between revisions
Mmuehlfeld (talk | contribs) m (Mmuehlfeld moved page Configure BIND9 DLZ as Back End for Samba AD to Configuring BIND9 DLZ as Back End for Samba AD: Fix title) |
Mmuehlfeld (talk | contribs) (Rewrote "Configuring BIND9 DLZ as Back End for Samba AD". Clearer structure, removed unnecessary/duplicate content, moved Apparmor/SELinux content to a separate page.) |
||
Line 1: | Line 1: | ||
= Introduction = |
= Introduction = |
||
Samba provides support for the BIND DNS server as DNS back end on a Samba Active Directory (AD) domain controller (DC). The <code>BIND9_DLZ</code> back end is recommend for complex DNS setups, the Samba internal DNS server not supports. |
|||
This HowTo describes how to configure a BIND installation to be used as the Samba DC DNS backend. See [[Setup_a_basic_BIND_installation]] for the prerequisites. |
|||
{{Imbox |
|||
If you need a more complex DNS setup than is possible with the Samba 4 internal DNS, then using BIND as the DNS backend is recommended. |
|||
| type = note |
|||
| text = This documentation supports only BIND versions that are actively maintained by ISC. For details about the ISC BIND lifecycle, see https://www.isc.org/downloads/software-support-policy/ |
|||
}} |
|||
The <code>BIND9_DLZ</code> module accesses the Samba Active Directory (AD) database directly. For this reason: |
|||
As this HowTo is based around a compiled install, the PATHs refer to '/usr/local/samba' as a base. If you are using packages from your OS or Sernet, this PATH will most likely not exist, you will need to find the relevant files on your system, try starting with '/var/lib/samba'. |
|||
* BIND must be installed on the same machine as the Samba AD domain controller (DC). |
|||
* BIND must not run in a changed root environment. |
|||
* zones are stored and replicated within the directory. |
|||
Notes: |
|||
* Since the BIND DLZ module accesses the AD database directly, Bind9 '''must''' be run on the same machine as the Samba 4 AD DC. |
|||
* Because the BIND DLZ module uses the information already stored in AD, you do not need to create any extra databases. |
|||
= Configuring the BIND9_DLZ module = |
|||
= BIND 9.8 / 9.9 = |
|||
During provisioning |
During the domain provisioning, join, or classic upgrade, the <code>/usr/local/samba/private/named.conf</code> file has been created. To enable the <code>BIND9_DLZ</code> module for your BIND version: |
||
* Add the following <code>include</code> statement to your BIND <code>named.conf</code> file: |
|||
include "/usr/local/samba/private/named.conf"; |
include "/usr/local/samba/private/named.conf"; |
||
* Display the BIND version: |
|||
Depending on the BIND version you are running, you should edit '/usr/local/samba/private/named.conf' and enable the correct version of the DLZ module: |
|||
# named -v |
|||
BIND 9.9.4 |
|||
* Edit the <code>/usr/local/samba/private/named.conf</code> file and uncomment the module for your BIND version. For example: |
|||
dlz "AD DNS Zone" { |
dlz "AD DNS Zone" { |
||
# For BIND 9.8 |
# For BIND 9.8 |
||
database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so"; |
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so"; |
||
# For BIND 9.9 |
# For BIND 9.9 |
||
database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so"; |
|||
# For BIND 9.10 |
# For BIND 9.10 |
||
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so"; |
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so"; |
||
# For BIND 9.11 |
|||
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so"; |
|||
}; |
}; |
||
:The following table shows which BIND version is supported in which Samba version: |
|||
The example above enables the module for BIND 9.8.x (default). |
|||
:{| class="wikitable" |
|||
Restart BIND so the included file will be used. Check the logfiles for errors and problems. If available, you can run <code>named-checkconf</code> to help you fix any problems with your BIND configuration. |
|||
!Supported BIND Version |
|||
!Samba Version |
|||
|- |
|||
|BIND 9.11 |
|||
|Samba 4.6 and later |
|||
|- |
|||
|BIND 9.10 |
|||
|Samba 4.2 and later |
|||
|- |
|||
|BIND 9.9 |
|||
|Samba 4.0 and later |
|||
|- |
|||
|BIND 9.8 |
|||
|Samba 4.0 and later |
|||
|} |
|||
If you provisioned with the internal DNS, there are a few steps required to [[Changing_the_DNS_backend#Changing_from_Samba_Internal_DNS_to_BIND_DLZ|switch to BIND]]. |
|||
= Setting up Dynamic DNS Updates Using Kerberos = |
|||
Samba is able to automatically update the Active Directory (AD) zone managed by the <code>BIND9_DLZ</code> back end. |
|||
= BIND 9.7= |
|||
{{Imbox |
|||
Users of bind 9.7 are strongly encouraged to upgrade! If this is not possible, refer to the section [[#BIND_9.7_2|DNS dynamic updates via Kerberos for BIND 9.7]] for instructions on configuring BIND 9.7. |
|||
| type = note |
|||
| text = Dynamic DNS updates require minimum BIND version 9.8. |
|||
}} |
|||
To enable dynamic DNS updates using Kerberos: |
|||
* Add the following <code>include</code> statement to the <code>options {}</code> section of your BIND <code>named.conf</code> file. For example: |
|||
= DNS dynamic updates via Kerberos (optional, but recommended) = |
|||
Samba has the capability to automatically update the BIND zone files via Kerberos. |
|||
To setup dynamic DNS updates you need to have a recent version of BIND installed. It is highly recommended that you run at least version 9.8.0, as that version includes a set of patches from the Samba Team to make dynamic DNS updates much more robust and easier to configure. Please use 9.8 or 9.9 if possible! |
|||
To find out what version of BIND you are running, use |
|||
# named -V |
|||
If your operating system does not have BIND 9.8 or 9.9, please consider getting it from a package provided by a 3rd party (for example, on Ubuntu there is a ppa available with the newer versions of bind) or [[#Installing_BIND|compile it by yourself]]. |
|||
== Workaround: Fix keytab permissions == |
|||
This fix is only required, if joining the domain with a Samba version prior to 4.4. Wrong keytab permissions will prevent BIND updating your AD DNS zones. One of the results will be that "samba_dnsupdate" can't add important DNS entries, that clients query to locate the new Domain Controller! |
|||
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 uses, is able to access the dns.keytab file. Some package installations set too restrictive permissions on higher folders.'' |
|||
== BIND 9.8 / 9.9 == |
|||
A DNS keytab file was automatically created during provisioning/updating. Add the following' tkey-gssapi-keytab' option to the 'options' section of your named.conf: |
|||
options { |
options { |
||
Line 88: | Line 88: | ||
}; |
}; |
||
* If you provisioned or joined an AD forest or run the classic upgrade using a Samba version prior to 4.4.0, the BIND Kerberos key tab file was generated using wrong permissions. To fix, enable read access for the BIND user: |
|||
# chmod 640 /usr/local/samba/private/dns.keytab |
|||
# chown root:named /usr/local/samba/private/dns.keytab |
|||
:{{Imbox |
|||
== BIND 9.7 == |
|||
| type = note |
|||
| text = If you are installing installing Samba using packages, validate that the BIND user is able to read the <code>dns.keytab</code> file. Some package installations set to restrictive permissions on higher folders. |
|||
}} |
|||
* Verify that your <code>/etc/krb5.conf</code> Kerberos client configuration file is readable by your BIND user. For example: |
|||
If you have BIND 9.7.x (specifically 9.7.2 or later), then first determine if you can at all possibly run 9.8 or 9.9. You will have far fewer problems! Otherwise, follow these instructions: |
|||
# ls -l /etc/krb5.conf |
|||
The Samba provision will have created a custom '/usr/local/samba/private/named.conf.update' configuration file. You need to include this file in your 'named.conf' to allow Samba/Kerberos DNS updates to automatically take place. |
|||
-rw-r--r--. 1 root named 99 2. Sep 2014 /etc/krb5.conf |
|||
* Verify that the <code>nsupdate</code> utility exists on your domain controller (DC): |
|||
include "/usr/local/samba/private/named.conf.update"; |
|||
# which nsupdate |
|||
Be advised that if you include this file in BIND versions that don't support it, BIND will fail to start! |
|||
/usr/bin/nsupdate |
|||
:The <code>nsupdate</code> command is used to update the DNS. If the utility is missing, see you distribution's documentation how to identify the package containing the command and how to install. |
|||
You additionally need to set two environment variables when using 9.7: |
|||
KEYTAB_FILE="/usr/local/samba/private/dns.keytab" |
|||
KRB5_KTNAME="/usr/local/samba/private/dns.keytab" |
|||
export KEYTAB_FILE |
|||
export KRB5_KTNAME |
|||
These should be put in your settings file for BIND. On Debian based systems (including Ubuntu) this is in '/etc/default/bind9'. On RedHat and SuSE derived systems it is in '/etc/sysconfig/named'. Please refer to your distribution documentation for the correct location to set these environment variables. Strictly speaking, you only either need KEYTAB_FILE or KRB5_KTNAME, but which you need depends on your distribution, so it's easier to just set both. |
|||
The 'dns.keytab' must be readable by the bind server process: |
|||
# chown named:named /usr/local/samba/private/dns.keytab |
|||
= Starting the BIND Service = |
|||
Normally, the provision/update should have setup these permissions for you automatically. |
|||
* Before you start the service, verify the BIND configuration: |
|||
# named-checkconf |
|||
options { |
|||
[...] |
|||
tkey-gssapi-credential "DNS/server.samdom.example.com"; |
|||
tkey-domain "SAMDOM.EXAMPLE.COM"; |
|||
[...] |
|||
}; |
|||
: If no output is shown, the BIND configuration is valid. |
|||
The last part of the credential in the first line must match the dns name of the server you have set up. |
|||
* Start the BIND service. |
|||
== Testing/Debugging dynamic DNS updates == |
|||
The way the automatic DNS update in Samba works, is that the provision will create a file '/usr/local/samba/private/dns_update_list', which contains a list of DNS entries that Samba will try to dynamically update at startup and every 10 minutes thereafter using the 'samba_dnsupdate' utility. Updates will only happen if the DNS entries do not already exist. Remember that you need the 'nsupdate' utility from BIND the distribution for all these to work. |
|||
If you want to test or debug this process, then please run as root: |
|||
= Testing Dynamic DNS Updates = |
|||
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names |
|||
To test the dynamic DNS updates, run as user <code>root</code> on your Samba domain controller (DC): |
|||
The command line options specified will force an update of all records in the 'dns_update_list', as well as output detailed information on what is being done. |
|||
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names |
|||
This commands forces an update of all records specified in the <code>/usr/local/samba/private/dns_update_list</code> file. |
|||
The <code>samba_dnsupdate</code> utility updates the DNS. It automatically checks for missing DNS records specified in the <code>dns_update_list</code> file when the <code>samba</code> daemon starts and after every 10 minutes. |
|||
= Interaction with AppArmor or SELinux = |
|||
If you are getting an error from samba_dnsupdate and nsupdate '''return dns_tkey_negotiategss: TKEY is unacceptable''' try the following: |
|||
If you are using AppArmor or SELinux, you have to ensure that the BIND process has read access to the following files: |
|||
* /usr/local/samba/private/dns.keytab |
|||
* /usr/local/samba/private/named.conf |
|||
as well read-write access to the |
|||
* /usr/local/samba/private/dns/ |
|||
directory and it's own zone file(s). |
|||
The Samba provision tries to setup the permissions correctly for these files, but you may find you need to make changes in your AppArmor or SELinux configuration if you are running either of those. If you are using AppArmor, then the 'aa-logprof' command may help you add any missing permissions you need to add after you start Samba and BIND for the first time after configuring them. |
|||
Permissions, SELinux Labeling and Policy |
|||
= Troubleshooting = |
|||
These instructions are intended for RHEL6, but may serve as a guide for other distributions/versions. |
|||
== Debugging the BIND9_DLZ Module == |
|||
There is still more work to be done in regards of creating a Samba 4 specific SELinux policy but for now you should be able to have everything working without disabling SELinux. |
|||
To set a log level for the <code>BIND9_DLZ</code> module: |
|||
For all the commands below, make sure you have set the following environment variable: |
|||
MYREALM="samdom.example.com" |
|||
* Append the <code>-d</code> parameter and log level to the module in the <code>/usr/local/samba/private/named.conf</code> file. For example: |
|||
Set Permissions (SELinux): |
|||
database "dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3"; |
|||
chown named:named /usr/local/samba/private/dns |
|||
chgrp named /usr/local/samba/private/dns.keytab |
|||
chmod g+r /usr/local/samba/private/dns.keytab |
|||
chmod 775 /usr/local/samba/private/dns |
|||
* Stop the BIND service. |
|||
Label files (SELinux): |
|||
* Start BIND manually to display the debug out put and to capture the log output in the <code>/tmp/named.log</code> file: |
|||
chcon -t named_conf_t /usr/local/samba/private/dns.keytab |
|||
chcon -t named_conf_t /usr/local/samba/private/named.conf.update |
|||
chcon -t named_var_run_t /usr/local/samba/private/dns |
|||
chcon -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone |
|||
# named -u named -f -g 2>&1 | tee /etc/named.log |
|||
Set Label Persistence (SELinux): |
|||
: See the <code>named (8)<code> man page for details about the used parameters. |
|||
semanage fcontext -a -t named_conf_t /usr/local/samba/private/dns.keytab |
|||
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf |
|||
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf.update |
|||
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns |
|||
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone |
|||
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone.jnl |
|||
AppArmor Configuration : |
|||
Add the following to the end of /etc/apparmor.d/local/usr.sbin.named (create it if it doesn't already exist). |
|||
== New DNS Entries Are Not Resolvable == |
|||
# Samba4 DLZ and Active Directory Zones (default source installation) |
|||
/usr/local/samba/lib/** rm, |
|||
/usr/local/samba/private/dns.keytab r, |
|||
/usr/local/samba/private/named.conf r, |
|||
/usr/local/samba/private/dns/** rwk, |
|||
If you create new DNS records in the directory and are not able to resolve them using the <code>nslookup</code>, <code>host</code> or other DNS lookup tools, the database hard links can got lost. This happens, for example, if you move the databases across mount points. |
|||
Additionally, it was found that on some distributions, additional paths may be required; consult your AppArmor logs for more information. |
|||
To verify that the domain and forest partition as well as the <code>metadata.tdb</code> database are hard linked in both directories, run |
|||
Examples: |
|||
# ls -lai /usr/local/samba/private/sam.ldb.d/ |
|||
It was found that on Ubuntu 14.04.1 LTS, BIND was trying to create files such as /var/tmp/DNS_110, and so a further entry was required: |
|||
/var/tmp/** rwmk, |
|||
It has also been found on Ubuntu 14.04.3 LTS using Samba: Version 4.1.17 (built from source) and BIND 9.9.5-3ubuntu0.5-Ubuntu you need to add the line: |
|||
/usr/local/samba/etc/smb.conf r, |
|||
= Debugging BIND as Samba AD backend = |
|||
For enabling debugging on the BIND DLZ module, change the following line in '/usr/local/samba/private/named.conf' from |
|||
database "dlopen .../bin/modules/bind9/dlz_bind9.so"; |
|||
to |
|||
database "dlopen .../bin/modules/bind9/dlz_bind9.so -d 3"; |
|||
If you are running BIND 9.9, then add the '-d 3' to the corresponding line. |
|||
Stop BIND and run the service manually to capture logs: |
|||
# /usr/sbin/named -u named -f -g 2>&1 | tee named.log |
|||
= Known issues and ways to fix/workaround = |
|||
== Chroot BIND == |
|||
If you use BIND as Backend for your Samba AD, it must not run chroot, because it must be able to live access files and databases from your Samba installation. |
|||
To disable chroot for BIND, see the documentation for your distribution. In some, you can set |
|||
NAMED_RUN_CHROOTED="no" |
|||
in "/etc/sysconfig/named" and restart the service. |
|||
== Debian: BIND is listening on wrong IP address == |
|||
On Debian systems, the AD zone auto-generation might detect and use '127.0.1.1' as the domain controller's IP address. This will cause problems when trying to connect to the server from client machines. To fix this, you will need to adjust '/usr/local/samba/private/named.conf' by changing '127.0.1.1' to reflect the actual IP address of the server you're setting up. |
|||
== Debian Sid: Named does not start == |
|||
On Debian Sid (BIND 9 package), '/etc/bind/named.conf.options' is missing and this will cause the named daemon to fail to start. To fix this either create an empty file, or comment out corresponding line in '/etc/bind/named.conf'. See your syslog messages for more information. |
|||
== New added DNS entries are not resolvable == |
|||
If you have problems with resolving new added DNS entries using the BIND9 DLZ interface, you maybe want to check the following: |
|||
The DNS zones and the metadata.ldb file in 'samba/private/dns/sam.ldb.d/' are hardlinks to 'samba/private/sam.ldb.d/'. |
|||
Maybe you've copied/moved it across filesystems and the hardlinking got lost |
|||
and you're now running with two different copies of the databases at the moment |
|||
(You can test this by adding a new DNS entry, e. g. by 'samba-tool'. If you can't |
|||
resolve it, check if the inodes differ). |
|||
If you 'ls -i' on the two folders, you should see, that the following files |
|||
have the same inodes (what indicates, that they are hard-linked): |
|||
# ls -lai .../samba/private/sam.ldb.d/ |
|||
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
||
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
||
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb |
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb |
||
# ls -lai |
# ls -lai /usr/local/samba/private/dns/sam.ldb.d/ |
||
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
||
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb |
||
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb |
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb |
||
The same files must have the same inode number in the first column of the output in the both directories. If they differ, the hard link got lost and Samba and BIND use separate database files and thus DNS updates in the directory are not resolveable through the BIND DNS server. |
|||
If the files in the two folders have different inode numbers, then they |
|||
aren't hard-links. To fix this, run |
|||
To auto-repair the hard linking: |
|||
# samba_upgradedns --dns-backend=BIND9_DLZ |
|||
* Rerun the back end configuration: |
|||
This will recreate the DNS files with correct hard links and permissions. |
|||
# samba_upgradedns --dns-backend=BIND9_DLZ |
|||
Then restart BIND. |
|||
== DDNS updates not working == |
|||
* Check that the file '/etc/krb5.conf' is readable by BIND. |
|||
bind DLZ lookup for default_realm , realm , domain_realm and appdefaults at /etc/krb5.conf |
|||
* Restart the BIND service to take effect. |
|||
* Check that the configured samba4 dns.keytab been accessible by BIND and samba4 |
|||
* Check that deployed dns resolver been correctly set to samba4 AD server |
|||
* Check at named.conf that the samba DLZ settings been correct at least for |
|||
tkey-gssapi-keytab |
|||
tkey-domain |
|||
* Check common settings for samba4 smb.conf: |
|||
kerberos method = system keytab |
|||
client ldap sasl wrapping = sign |
|||
allow dns updates = nonsecure and secure |
|||
nsupdate command = /usr/bin/nsupdate -g |
|||
* Check out if SPNEGO been not disabled while use samba4.1 and up the deployed ISC BIND package (see [[DNS#using_ISC_BIND_backend_with_secured_.2F_signed_dns_updates]]) |
|||
* Check that TLS/SSL are correctly deployed |
|||
* Check that filesystems support acl |
Revision as of 00:27, 10 October 2016
Introduction
Samba provides support for the BIND DNS server as DNS back end on a Samba Active Directory (AD) domain controller (DC). The BIND9_DLZ
back end is recommend for complex DNS setups, the Samba internal DNS server not supports.
This documentation supports only BIND versions that are actively maintained by ISC. For details about the ISC BIND lifecycle, see https://www.isc.org/downloads/software-support-policy/ |
The BIND9_DLZ
module accesses the Samba Active Directory (AD) database directly. For this reason:
- BIND must be installed on the same machine as the Samba AD domain controller (DC).
- BIND must not run in a changed root environment.
- zones are stored and replicated within the directory.
Configuring the BIND9_DLZ module
During the domain provisioning, join, or classic upgrade, the /usr/local/samba/private/named.conf
file has been created. To enable the BIND9_DLZ
module for your BIND version:
- Add the following
include
statement to your BINDnamed.conf
file:
include "/usr/local/samba/private/named.conf";
- Display the BIND version:
# named -v BIND 9.9.4
- Edit the
/usr/local/samba/private/named.conf
file and uncomment the module for your BIND version. For example:
dlz "AD DNS Zone" { # For BIND 9.8 # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so"; # For BIND 9.9 database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so"; # For BIND 9.10 # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so"; # For BIND 9.11 # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so"; };
- The following table shows which BIND version is supported in which Samba version:
Supported BIND Version Samba Version BIND 9.11 Samba 4.6 and later BIND 9.10 Samba 4.2 and later BIND 9.9 Samba 4.0 and later BIND 9.8 Samba 4.0 and later
Setting up Dynamic DNS Updates Using Kerberos
Samba is able to automatically update the Active Directory (AD) zone managed by the BIND9_DLZ
back end.
Dynamic DNS updates require minimum BIND version 9.8. |
To enable dynamic DNS updates using Kerberos:
- Add the following
include
statement to theoptions {}
section of your BINDnamed.conf
file. For example:
options { [...] tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab"; [...] };
- If you provisioned or joined an AD forest or run the classic upgrade using a Samba version prior to 4.4.0, the BIND Kerberos key tab file was generated using wrong permissions. To fix, enable read access for the BIND user:
# chmod 640 /usr/local/samba/private/dns.keytab # chown root:named /usr/local/samba/private/dns.keytab
If you are installing installing Samba using packages, validate that the BIND user is able to read the dns.keytab
file. Some package installations set to restrictive permissions on higher folders.
- Verify that your
/etc/krb5.conf
Kerberos client configuration file is readable by your BIND user. For example:
# ls -l /etc/krb5.conf -rw-r--r--. 1 root named 99 2. Sep 2014 /etc/krb5.conf
- Verify that the
nsupdate
utility exists on your domain controller (DC):
# which nsupdate /usr/bin/nsupdate
- The
nsupdate
command is used to update the DNS. If the utility is missing, see you distribution's documentation how to identify the package containing the command and how to install.
Starting the BIND Service
- Before you start the service, verify the BIND configuration:
# named-checkconf
- If no output is shown, the BIND configuration is valid.
- Start the BIND service.
Testing Dynamic DNS Updates
To test the dynamic DNS updates, run as user root
on your Samba domain controller (DC):
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names
This commands forces an update of all records specified in the /usr/local/samba/private/dns_update_list
file.
The samba_dnsupdate
utility updates the DNS. It automatically checks for missing DNS records specified in the dns_update_list
file when the samba
daemon starts and after every 10 minutes.
Troubleshooting
Debugging the BIND9_DLZ Module
To set a log level for the BIND9_DLZ
module:
- Append the
-d
parameter and log level to the module in the/usr/local/samba/private/named.conf
file. For example:
database "dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3";
- Stop the BIND service.
- Start BIND manually to display the debug out put and to capture the log output in the
/tmp/named.log
file:
# named -u named -f -g 2>&1 | tee /etc/named.log
- See the
named (8)
man page for details about the used parameters.
New DNS Entries Are Not Resolvable
If you create new DNS records in the directory and are not able to resolve them using the nslookup
, host
or other DNS lookup tools, the database hard links can got lost. This happens, for example, if you move the databases across mount points.
To verify that the domain and forest partition as well as the metadata.tdb
database are hard linked in both directories, run
# ls -lai /usr/local/samba/private/sam.ldb.d/
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb
# ls -lai /usr/local/samba/private/dns/sam.ldb.d/
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb
The same files must have the same inode number in the first column of the output in the both directories. If they differ, the hard link got lost and Samba and BIND use separate database files and thus DNS updates in the directory are not resolveable through the BIND DNS server.
To auto-repair the hard linking:
- Rerun the back end configuration:
# samba_upgradedns --dns-backend=BIND9_DLZ
- Restart the BIND service to take effect.