From SambaWiki
Revision as of 17:44, 25 August 2015 by Mmuehlfeld (talk | contribs) (Removed the "compiling bind" part form this page (was placed on a new page))


This HowTo describes how to configure a BIND installation, that can be used as Samba DC DNS backend. See Setup_a_basic_BIND_installation for the prerequisites.

If you need to setup a more complex DNS setup than what is possible with the Samba 4 internal DNS, then using BIND as the DNS backend is recommended.

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

Note: BIND must be installed on the same machine as Samba AD DC. Since BIND DLZ module accesses AD database directly, BIND for AD zones must be on the same machine.

BIND 9.8 / 9.9

During provisioning/upgrading, a file ('/usr/local/samba/private/named.conf') was created, that must be included in your BIND named.conf:

include "/usr/local/samba/private/named.conf";

If you had provisioned with the internal DNS, there are some few steps required first to switch to BIND.

Depending on the BIND version you are running, you should edit '/usr/local/samba/private/named.conf' and enable the right version of the DLZ module.

Restart BIND to have the included file being used. Check the logfiles for errors and problems. If available, you can run named-checkconf to help you fix any problems with your BIND configuration.

BIND 9.7

Users of bind 9.7 are strongly encouraged to upgrade! If this is not possible, refer to the section DNS dynamic updates via Kerberos for BIND 9.7 for instructions on configuring BIND 9.7.

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 compile it by yourself.

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 {
     tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";

BIND 9.7

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:

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.

include "/usr/local/samba/private/named.conf.update";

Be advised that if you include this file in BIND versions that don't support it, BIND will fail to start!

You additionally need to set two environment variables when using 9.7:

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

Normally, the provision/update should have setup these permissions for you automatically.

Finally, you need to add the following to the options section of your named.conf:

options {
     tkey-gssapi-credential "DNS/";
     tkey-domain "SAMDOM.EXAMPLE.COM";

The last part of the credential in the first line must match the dns name of the server you have set up.

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:

# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names

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.

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

These instructions are intended for RHEL6, but may serve as a guide for other distributions/versions.

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.

For all the commands below, make sure you have set the following environment variable:


Set Permissions (SELinux):

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

Label files (SELinux):

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

Set Label Persistence (SELinux):

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

# 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,

Additionally, it was found that on some distributions, additional paths may be required; consult your AppArmor logs for more information. For example, 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,

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/";


database "dlopen .../bin/modules/bind9/ -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


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

If the files in the two folders have different inode numbers, then they aren't hard-links. To fix this, run

# samba_upgradedns --dns-backend=BIND9_DLZ

This will recreate the DNS files with correct hard links and permissions.

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