http:///https:///api.php?action=feedcontributions&user=Mogga&feedformat=atomSambaWiki - User contributions [en]2024-03-29T08:06:42ZUser contributionsMediaWiki 1.39.5https://wiki.samba.org/index.php?title=Samba_AD_schema_extensions&diff=9325Samba AD schema extensions2014-10-07T09:44:08Z<p>Mogga: /* Schema extension in Samba 4 */</p>
<hr />
<div>= Schema extension in Samba 4 =<br />
<br />
Samba 4 supports the same kind of schema extensions as Microsoft Active Directory. Schema updates in AD are a sensitive action and you must be prepared to do a full restore of the DC holding the role of schema master if something goes wrong.<br />
<br />
This is even more true in Samba 4 given it does not always generate some critical attributes that are generated on Microsoft AD and this lack of attributes can lead to a un-start-able samba provision.<br />
This is why schema updates in Samba 4 are currently disabled by default.<br />
<br />
In order to allow them, the option ''dsdb:schema update allowed'' must be set to true in the ''smb.conf'' or passed on the command line.<br />
<br />
== Tested Schema extensions ==<br />
As getting an LDIF that won't ruin the provision can be hard, this page will list LDIFs that are known not to break the database.<br />
<br />
Perform these updates only if you need them and if '''you know how to restore the provision on the schema master'''.<br />
<br />
=== Automounter ===<br />
<br />
This extension allow you to store automount information in LDAP. In order to add this extension, follow these steps:<br />
<br />
* Download [[File:Automount_template.ldif.txt|automount_template.ldif.txt]], this is a template that will be transformed in the next steps<br />
* Locate the rootDN of your provision: ''ldbsearch -H ldap://ip_of_server -U administrator -s base dn<br />
* Run ''cat automount_template.ldif | sed 's/DOMAIN_TOP_DN/value_of_rootDN_obtained_in_previous_step/' > automount.ldif ''<br />
* Stop Samba4 on the schema master<br />
* Copy ''automount.ldif'' to the schema master server (if you were working on a different server)<br />
* Apply the ldif with a command similar to: ''ldbmodify -H path_to_sam_ldb automount.ldif --option="dsdb:schema update allowed"=true</div>Moggahttps://wiki.samba.org/index.php?title=Time_Synchronisation&diff=9324Time Synchronisation2014-10-07T04:10:13Z<p>Mogga: /* Check Samba AD DC socket permissions */</p>
<hr />
<div>= Introducion =<br />
<br />
In an Active Directory, an accurate time synchronisation is required and critical like DNS E. g. Kerberos relies on correct timestamps to prevent replay attacks and AD needs them for resolving replication conflicts.<br />
<br />
The maximum time tolerance in an Active Directory is 5 minutes per default. If e. g. your clients clock differs more than that to your servers clock, accessing the server is denied.<br />
<br />
In an Active Directory, the Domain Controller with the PDC Emulator role is considered as the default time source in a forest. See http://technet.microsoft.com/en-us/library/cc773013%28v=ws.10%29.aspx#w2k3tr_times_how_izcr for information about time synchronisation in an AD DS hierarchy.<br />
<br />
<br />
<br />
= General information =<br />
<br />
== Server information used in this HowTo ==<br />
<br />
Inside this HowTo, we will be using the following configuration/settings:<br />
<br />
Installation Directory: /usr/local/samba/<br />
Domain Controller (owner of PDC role): DC1.samdom.example.com<br />
Domain Controller (not owner of PDC role): DC2.samdom.example.com<br />
<br />
<br />
<br />
== Limitations of ntpd with old clients ==<br />
<br />
Please note that [http://www.ntp.org/ ntpd from ntp.org] Samba interface with, does not support authenticated time to Windows 2000 clients! This is due to these clients not behaving as the ntpd server expects. As these clients are now very old and unsupported, you may need to find another way to keep these clocks in sync. <br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on a DC =<br />
<br />
== Requirements ==<br />
<br />
* [http://www.ntp.org/ ntpd] >= 4.2.6 with enabled signed ntp support<br />
<br />
<br />
<br />
== Installation ==<br />
<br />
* Install ntpd from your distributions repository. Make sure, that it was compiled using the „--enable-ntp-signd“ option!<br />
<br />
* Compile by yourself (Add „--enable-ntp-signd“ to the „configure“ options!).<br />
<br />
<br />
<br />
== Check Samba AD DC socket permissions ==<br />
<br />
Check that the socket permissions are set correct. It must be <u>readable</u> by the account your ntpd uses and should not be accessable by other:<br />
<br />
# chown root:ntp /usr/local/samba/var/lib/ntp_signd/<br />
# chmod 750 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
# ls -ld /usr/local/samba/var/lib/ntp_signd/<br />
drwxr-x--- 2 root ntp 4096 1. May 09:30 /usr/local/samba/var/lib/ntp_signd/<br />
<br />
== Setup ntpd.conf ==<br />
<br />
# Local clock (this is not the localhost address!)<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
<br />
# The source, where we are receiving the time from<br />
server 0.pool.ntp.org iburst prefer<br />
<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/<br />
<br />
<br />
# Access control<br />
# Default restriction: Only allow querying time (incl. ms-sntp) from this machine<br />
restrict default kod nomodify notrap nopeer mssntp<br />
<br />
# Allow everything from localhost<br />
restrict 127.0.0.1<br />
<br />
# Allow that our time source can only provide time and do nothing else<br />
restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
For further information about ntpd access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions<br />
<br />
<br />
<br />
== SELinux Labeling and Policy (optional) ==<br />
<br />
Set policy for Windows client time sync:<br />
# chcon -u system_u -t ntpd_t /usr/local/samba/var/lib/ntp_signd<br />
<br />
Make the policy permanent<br />
# semanage -a -t ntpd_t "/usr/local/samba/var/lib/ntp_signd"<br />
<br />
Verify the change<br />
# cat /etc/selinux/targeted/contexts/files/file_contexts.local<br />
<br />
You should see a line like:<br />
/usr/local/samba/var/lib/ntp_signd system_u:object_r:ntpd_t:s0<br />
<br />
The below policy file is based on 4.1.6 on RHEL 6.5 and should be for reference only. Always run the below egrep command, after you have a base policy file created. Then stop / start ntpd and Samba AD services on your system and add to the base policy until competed.<br />
<br />
egrep "samba|ntpd" /var/log/audit/audit.log | audit2allow<br />
<br />
If all is fine, you'll see this for each "allow" line below in the policy file.<br />
#!!! This avc is allowed in the current policy<br />
allow ntpd_t self:capability sys_admin;<br />
etc.<br />
<br />
<tt>samba4.te</tt> policy: <br />
module samba4 1.0;<br />
<br />
require {<br />
type ntpd_t;<br />
type usr_t;<br />
type initrc_t;<br />
type fs_t;<br />
type setfiles_t;<br />
type lib_t;<br />
type unconfined_t;<br />
type locate_t;<br />
class dir write;<br />
class dir search;<br />
class dir open;<br />
class dir read;<br />
class dir getattr;<br />
class dir remove_name;<br />
class dir add_name;<br />
class dir relabelto;<br />
class unix_stream_socket connectto;<br />
class sock_file write;<br />
class sock_file create;<br />
class sock_file unlink;<br />
class filesystem associate;<br />
class capability sys_admin;<br />
}<br />
<br />
#============= initrc_t ==============<br />
allow initrc_t ntpd_t:dir { write remove_name add_name };<br />
allow initrc_t ntpd_t:sock_file create;<br />
allow initrc_t ntpd_t:sock_file unlink;<br />
<br />
#============= ntpd_t ==============<br />
allow ntpd_t usr_t:sock_file write;<br />
allow ntpd_t initrc_t:unix_stream_socket connectto;<br />
allow ntpd_t fs_t:filesystem associate;<br />
allow ntpd_t lib_t:sock_file write;<br />
allow ntpd_t unconfined_t:unix_stream_socket connectto;<br />
allow ntpd_t self:sock_file write;<br />
allow ntpd_t self:capability sys_admin;<br />
<br />
#============= locate_t ==============<br />
allow locate_t ntpd_t:dir { read getattr open search };<br />
<br />
#============= setfiles_t ==============<br />
allow setfiles_t ntpd_t:dir relabelto; <br />
<br />
<br />
Check and load policy:<br />
$ checkmodule -M -m -o samba4.mod samba4.te <br />
$ semodule_package -o samba4.pp -m samba4.mod<br />
$ semodule -i samba4.pp<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on Samba Member Servers =<br />
<br />
== Requirements ==<br />
<br />
* [http://www.ntp.org/ ntpd]<br />
<br />
<br />
<br />
== Installation ==<br />
<br />
* Install ntpd from your distributions repository.<br />
<br />
* Compile it by yourself.<br />
<br />
<br />
<br />
== Setup ntpd.conf ==<br />
<br />
# Local clock (this is not the localhost address!)<br />
server 127.127.1.0<br />
fudge 127.127.1.0 stratum 10<br />
<br />
# The source, where we are receiving the time from (PDC)<br />
server DC1.samdom.example.com iburst prefer<br />
<br />
driftfile /var/lib/ntp/ntp.drift<br />
logfile /var/log/ntp<br />
<br />
# Access control<br />
# Default restriction<br />
restrict default ignore<br />
<br />
# Allow everything from localhost<br />
restrict 127.0.0.1<br />
<br />
# Allow that our time source can only provide time and do nothing else<br />
restrict DC1.samdom.example.com mask 255.255.255.255 nomodify notrap nopeer noquery<br />
<br />
For further information about ntpd access control, see http://support.ntp.org/bin/view/Support/AccessRestrictions<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on Windows Clients =<br />
<br />
== Default behaviour ==<br />
<br />
Per default, Windows clients in an Active Directory, automatically synchronize their time with the DC, owning the „PDC“ role. If you don't want to use a different source, configure fallback time server, etc. you don't have to take action.<br />
<br />
<br />
<br />
== Setting user defined time source(s) and options ==<br />
<br />
If you require your Windows clients to synchronize time with a different server than your DC owning the PDC role, you can configure this via Group Policies. Using the following way, you can define multiple time servers and adjust time sycronisation related options:<br />
<br />
* Create a new Group Policy Object in the Group Policy Management Console and edit it.<br />
<br />
* In the Group Policy Management Editor, go to „Computer Configuration“ / „Administrative Templates“ / „System“ / „Windows Time Service“ / „Time Providers“.<br />
<br />
* Edit the „Configure Windows NTP Client“ policy:<br />
<br />
:[[Image:GPO_Windows_NTP_Client_Options.png]]<br />
<br />
:This example changes the NTP server setting to a different DC, that provides time, but is not owner of the PDC role. For further explanations on the possible options, see the description in the policy and, visit http://technet.microsoft.com/de-de/library/cc779145%28v=ws.10%29.aspx.<br />
<br />
* Save the GPO and link it to the desired OU.<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Time Synchronisation on Linux Clients =<br />
<br />
See [[#Configuring_Time_Synchronisation_on_Samba_Member_Servers|Configuring Time Synchronisation on Samba Member Servers]].</div>Moggahttps://wiki.samba.org/index.php?title=BIND9_DLZ_DNS_Back_End&diff=9323BIND9 DLZ DNS Back End2014-10-06T19:11:24Z<p>Mogga: /* Adding a user and group for Bind */</p>
<hr />
<div>= Introduction =<br />
<br />
This HowTo describes how to compile and configure a basic Bind installation, that can be used as Samba DC DNS backend.<br />
<br />
Bind as DNS backend is recommended, if you plan setup a complexer DNS setup, than the Samba 4 internal DNS currently made possible.<br />
<br />
<br />
<br />
<br />
= Setting up a basic Bind installation =<br />
<br />
Skip this section if you already having an existing Bind installation; that can be used as a Samba AD backend.<br />
<br />
<br />
<br />
== Installing Bind ==<br />
<br />
Bind as backend for your Samba Active Directory Domain Controller is currently supported in version 9.8 and 9.9 only. 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.<br />
<br />
If you install Bind from the repositories of your distribution, you can skip the following two steps. But make sure that your vendor compiled Bind with the '--with-gssapi' and '--with-dlopen' options (see below) before using it as Samba AD DNS backend.<br />
<br />
<br />
=== Downloading ===<br />
<br />
Download your desired and Samba 4 supported version from [https://www.isc.org/software/bind https://www.isc.org/software/bind].<br />
<br />
<br />
=== Compiling Bind ===<br />
<br />
To use Bind 9.8.1 or later as Samba AD backend, at least the following two configure options are required:<br />
<br />
# ./configure --with-gssapi=/usr/include/gssapi --with-dlopen=yes<br />
<br />
Please check if there are other options you require for your environment. For building Bind 9.8.0, you must use '--with-dlz-dlopen=yes' instead of '--with-dlopen=yes'.<br />
<br />
To build and install:<br />
<br />
# make<br />
# make install<br />
<br />
<br />
<br />
== Configuration ==<br />
<br />
=== Setting up a basic named.conf ===<br />
<br />
The following example is a basic 'named.conf' for a pure minimal Bind installation without any Samba AD parts. We will add the Samba required parameters later.<br />
<br />
# /etc/named.conf<br />
# Global Bind configuration options<br />
<br />
options {<br />
<br />
auth-nxdomain yes;<br />
directory "/var/named";<br />
notify no;<br />
empty-zones-enable no;<br />
<br />
allow-query {<br />
127.0.0.1;<br />
10.1.1.0/24;<br />
# add other networks you want to allow to query your DNS<br />
};<br />
<br />
allow-recursion {<br />
10.1.1.0/24;<br />
# add other networks you want to allow to do recursive queries<br />
};<br />
<br />
forwarders {<br />
# Google public DNS server here - replace with your own if necessary<br />
8.8.8.8;<br />
8.8.4.4;<br />
};<br />
<br />
allow-transfer {<br />
# this config is for a single master DNS server<br />
none;<br />
};<br />
<br />
};<br />
<br />
<br />
# Root servers (required zone for recursive queries)<br />
zone "." {<br />
type hint;<br />
file "named.root";<br />
};<br />
<br />
# Required localhost forward-/reverse zones <br />
zone "localhost" {<br />
type master;<br />
file "master/localhost.zone";<br />
};<br />
<br />
zone "0.0.127.in-addr.arpa" {<br />
type master;<br />
file "master/0.0.127.zone";<br />
};<br />
<br />
We chose '/var/named' as directory in 'named.conf' to be the place where our zonefiles, etc. reside. If you want to place them on a different location, please regard this in all further instructions.<br />
<br />
For more details on the parameters used in the sample 'named.conf', see 'man 5 named.conf'.<br />
<br />
=== Adding a user and group for Bind ===<br />
<br />
If you don't want to run bind as root (and I'm sure you don't want that!), we add an account and group.<br />
<br />
First check if we have an existing `named` group:<br />
<br />
# getent group|grep named<br />
<br />
Add the user and group if none exists (adapt the UID/GID if required) :<br />
<br />
# groupadd -g 25 named<br />
# useradd -g named -u 25 -d /var/named -M -s /sbin/nologin named<br />
<br />
=== Getting the root name server list ===<br />
<br />
Download the root name server list from InterNIC:<br />
<br />
# wget -q -O /var/named/named.root http://www.internic.net/zones/named.root<br />
# chown named:named /var/named/named.root<br />
<br />
To have always the current file, you can add a cronjob to automatically download.<br />
<br />
<br />
<br />
=== Creating the localhost zone file ===<br />
<br />
Create a forward zone file ('/var/named/master/localhost.zone') for your 'localhost' zone:<br />
<br />
$TTL 3D<br />
<br />
$ORIGIN localhost.<br />
<br />
@ 1D IN SOA @ root (<br />
2013050101 ; serial<br />
8H ; refresh<br />
2H ; retry<br />
4W ; expiry<br />
1D ; minimum<br />
)<br />
<br />
@ IN NS @<br />
IN A 127.0.0.1<br />
<br />
<br />
<br />
=== Creating the 0.0.127.in-addr.arpa zone file ===<br />
<br />
Create a reverse zone file ('/var/named/master/0.0.127.zone') for your '0.0.127.in-addr.arpa' zone:<br />
<br />
$TTL 3D<br />
<br />
@ IN SOA localhost. root.localhost. (<br />
2013050101 ; Serial<br />
8H ; Refresh<br />
2H ; Retry<br />
4W ; Expire<br />
1D ; Minimum TTL<br />
)<br />
<br />
IN NS localhost.<br />
<br />
1 IN PTR localhost.<br />
<br />
<br />
<br />
=== Set permissions on the zone files ===<br />
<br />
# chown named:named /var/named/master/*.zone<br />
# chmod 640 /var/named/master/*.zone<br />
<br />
<br />
<br />
<br />
<br />
== Starting Bind ==<br />
<br />
# named -u named<br />
<br />
If the configuration is valid, you should see no errors on the console and in the system logfile.<br />
<br />
To have Bind automatically started at boot time, it's recommended, to create a init.d script or start it by systemd.<br />
<br />
<br />
<br />
<br />
<br />
== Testing your zone ==<br />
<br />
Now we try to lookup our zone entries. We tell the 'host' command, to use the resolver on 127.0.0.1, so that we don't query an foreign DNS server, that is maybe also configured in '/etc/resolv.conf'.<br />
<br />
First check the forward lookup for 'localhost':<br />
# host localhost. 127.0.0.1<br />
Using domain server:<br />
Name: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
Aliases: <br />
<br />
localhost has address 127.0.0.1<br />
<br />
And then the reverse lookup for '127.0.0.1':<br />
# host 127.0.0.1 127.0.0.1<br />
Using domain server:<br />
Name: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
Aliases: <br />
<br />
1.0.0.127.in-addr.arpa domain name pointer localhost.<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Bind as Samba Active Directory backend =<br />
<br />
* 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.<br />
<br />
<br />
<br />
== Bind 9.8 / 9.9 ==<br />
<br />
During provisioning/upgrading, a file ('/usr/local/samba/private/named.conf') was created, that must be included in your Bind named.conf:<br />
<br />
include "/usr/local/samba/private/named.conf";<br />
<br />
If you had provisioned with the internal DNS, there are some few steps required first to [[Changing_the_DNS_backend#Changing_from_Samba_Internal_DNS_to_BIND_DLZ|switch to Bind]].<br />
<br />
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.<br />
<br />
Restart Bind to have the included file being 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.<br />
<br />
== Bind 9.7==<br />
<br />
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.<br />
<br />
<br />
<br />
== DNS dynamic updates via Kerberos (optional, but recommended) ==<br />
<br />
Samba has the capability to automatically update the Bind zone files via Kerberos.<br />
<br />
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!<br />
<br />
To find out what version of Bind you are running, use<br />
<br />
# named -V<br />
<br />
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]].<br />
<br />
<br />
<br />
=== Bind 9.8 / 9.9 ===<br />
<br />
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:<br />
<br />
options {<br />
[...]<br />
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";<br />
[...]<br />
};<br />
<br />
<br />
<br />
=== Bind 9.7 ===<br />
<br />
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:<br />
<br />
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.<br />
<br />
include "/usr/local/samba/private/named.conf.update";<br />
<br />
Be advised that if you include this file in Bind versions that don't support it, Bind will fail to start!<br />
<br />
You additionally need to set two environment variables when using 9.7:<br />
<br />
KEYTAB_FILE="/usr/local/samba/private/dns.keytab"<br />
KRB5_KTNAME="/usr/local/samba/private/dns.keytab"<br />
export KEYTAB_FILE<br />
export KRB5_KTNAME<br />
<br />
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.<br />
<br />
The 'dns.keytab' must be readable by the bind server process:<br />
<br />
# chown named:named /usr/local/samba/private/dns.keytab<br />
<br />
Normally, the provision/update should have setup these permissions for you automatically.<br />
<br />
Finally, you need to add the following to the options section of your named.conf:<br />
<br />
options {<br />
[...]<br />
tkey-gssapi-credential "DNS/server.samdom.example.com";<br />
tkey-domain "SAMDOM.EXAMPLE.COM";<br />
[...]<br />
};<br />
<br />
The last part of the credential in the first line must match the dns name of the server, you have set up.<br />
<br />
<br />
<br />
=== Testing/Debugging dynamic DNS updates ===<br />
<br />
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.<br />
<br />
If you want to test or debug this process, then please run as root:<br />
<br />
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names<br />
<br />
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.<br />
<br />
= Interaction with AppArmor or SELinux =<br />
<br />
If you are getting an error from samba_dnsupdate and nsupdate '''return dns_tkey_negotiategss: TKEY is unacceptable''' try the following:<br />
<br />
If you are using AppArmor or SELinux, you have to ensure that the Bind process has read access to the following files: <br />
* /usr/local/samba/private/dns.keytab<br />
* /usr/local/samba/private/named.conf<br />
as well read-write access to the<br />
* /usr/local/samba/private/dns/<br />
directory and it's own zone file(s).<br />
<br />
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.<br />
<br />
Permissions, SELinux Labeling and Policy<br />
<br />
These instructions are intended for RHEL6, but may serve as a guide for other distributions/versions.<br />
<br />
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.<br />
<br />
For all the commands below, make sure you have set the following environment variable:<br />
MYREALM="samdom.example.com"<br />
<br />
Set Permissions (SELinux):<br />
<br />
chown named:named /usr/local/samba/private/dns<br />
chgrp named /usr/local/samba/private/dns.keytab<br />
chmod g+r /usr/local/samba/private/dns.keytab<br />
chmod 775 /usr/local/samba/private/dns<br />
<br />
Label files (SELinux):<br />
<br />
chcon -t named_conf_t /usr/local/samba/private/dns.keytab<br />
chcon -t named_conf_t /usr/local/samba/private/named.conf.update<br />
chcon -t named_var_run_t /usr/local/samba/private/dns<br />
chcon -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
<br />
Set Label Persistence (SELinux):<br />
<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/dns.keytab<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf.update<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone.jnl<br />
<br />
AppArmor Configuration :<br />
<br />
Add the following to the end of /etc/apparmor.d/local/usr.sbin.named (create it if it doesn't already exist).<br />
<br />
# Samba4 DLZ and Active Directory Zones (default source installation)<br />
/usr/local/samba/lib/** rm,<br />
/usr/local/samba/private/dns.keytab r,<br />
/usr/local/samba/private/named.conf r,<br />
/usr/local/samba/private/dns/** rwk,<br />
<br />
= Debugging Bind as Samba AD backend =<br />
<br />
For enabling debugging on the Bind DLZ module, change the following line in '/usr/local/samba/private/named.conf' from<br />
<br />
database "dlopen .../bin/modules/bind9/dlz_bind9.so";<br />
<br />
to<br />
<br />
database "dlopen .../bin/modules/bind9/dlz_bind9.so -d 3";<br />
<br />
If you are running Bind 9.9, then add the '-d 3' to the corresponding line.<br />
<br />
Stop Bind and run the service manually to capture logs:<br />
<br />
# /usr/sbin/named -u named -f -g 2>&1 | tee named.log<br />
<br />
<br />
<br />
<br />
<br />
= Known issues and ways to fix/workaround =<br />
<br />
== Chroot Bind ==<br />
<br />
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.<br />
<br />
To disable chroot for Bind, see the documentation for your distribution. In some, you can set <br />
NAMED_RUN_CHROOTED="no"<br />
in "/etc/sysconfig/named" and restart the service.<br />
<br />
<br />
<br />
== Debian: Bind is listening on wrong IP address ==<br />
<br />
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.<br />
<br />
<br />
<br />
== Debian Sid: Named does not start ==<br />
<br />
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. <br />
<br />
<br />
<br />
== New added DNS entries are not resolvable ==<br />
<br />
If you have problems with resolving new added DNS entries using the BIND9 DLZ interface, you maybe want to check the following:<br />
<br />
The DNS zones and the metadata.ldb file in 'samba/private/dns/sam.ldb.d/' are hardlinks to 'samba/private/sam.ldb.d/'.<br />
Maybe you've copied/moved it across filesystems and the hardlinking got lost<br />
and you're now running with two different copies of the databases at the moment<br />
(You can test this by adding a new DNS entry, e. g. by 'samba-tool'. If you can't<br />
resolve it, check if the inodes differ).<br />
<br />
If you 'ls -i' on the two folders, you should see, that the following files<br />
have the same inodes (what indicates, that they are hard-linked):<br />
<br />
# ls -lai .../samba/private/sam.ldb.d/<br />
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb<br />
<br />
# ls -lai .../samba/private/dns/sam.ldb.d/<br />
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb<br />
<br />
If the files in the two folders have different inode numbers, then they<br />
aren't hard-links. To fix this, run<br />
<br />
# samba_upgradedns --dns-backend=BIND9_DLZ<br />
<br />
This will recreate the DNS files with correct hard links and permissions.<br />
<br />
Then restart Bind.<br />
<br />
<br />
<br />
== DDNS updates not working ==<br />
<br />
Check that the file '/etc/krb5.conf' is readable by Bind.</div>Moggahttps://wiki.samba.org/index.php?title=BIND9_DLZ_DNS_Back_End&diff=9322BIND9 DLZ DNS Back End2014-10-06T19:08:20Z<p>Mogga: /* Setting up a basic named.conf */</p>
<hr />
<div>= Introduction =<br />
<br />
This HowTo describes how to compile and configure a basic Bind installation, that can be used as Samba DC DNS backend.<br />
<br />
Bind as DNS backend is recommended, if you plan setup a complexer DNS setup, than the Samba 4 internal DNS currently made possible.<br />
<br />
<br />
<br />
<br />
= Setting up a basic Bind installation =<br />
<br />
Skip this section if you already having an existing Bind installation; that can be used as a Samba AD backend.<br />
<br />
<br />
<br />
== Installing Bind ==<br />
<br />
Bind as backend for your Samba Active Directory Domain Controller is currently supported in version 9.8 and 9.9 only. 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.<br />
<br />
If you install Bind from the repositories of your distribution, you can skip the following two steps. But make sure that your vendor compiled Bind with the '--with-gssapi' and '--with-dlopen' options (see below) before using it as Samba AD DNS backend.<br />
<br />
<br />
=== Downloading ===<br />
<br />
Download your desired and Samba 4 supported version from [https://www.isc.org/software/bind https://www.isc.org/software/bind].<br />
<br />
<br />
=== Compiling Bind ===<br />
<br />
To use Bind 9.8.1 or later as Samba AD backend, at least the following two configure options are required:<br />
<br />
# ./configure --with-gssapi=/usr/include/gssapi --with-dlopen=yes<br />
<br />
Please check if there are other options you require for your environment. For building Bind 9.8.0, you must use '--with-dlz-dlopen=yes' instead of '--with-dlopen=yes'.<br />
<br />
To build and install:<br />
<br />
# make<br />
# make install<br />
<br />
<br />
<br />
== Configuration ==<br />
<br />
=== Setting up a basic named.conf ===<br />
<br />
The following example is a basic 'named.conf' for a pure minimal Bind installation without any Samba AD parts. We will add the Samba required parameters later.<br />
<br />
# /etc/named.conf<br />
# Global Bind configuration options<br />
<br />
options {<br />
<br />
auth-nxdomain yes;<br />
directory "/var/named";<br />
notify no;<br />
empty-zones-enable no;<br />
<br />
allow-query {<br />
127.0.0.1;<br />
10.1.1.0/24;<br />
# add other networks you want to allow to query your DNS<br />
};<br />
<br />
allow-recursion {<br />
10.1.1.0/24;<br />
# add other networks you want to allow to do recursive queries<br />
};<br />
<br />
forwarders {<br />
# Google public DNS server here - replace with your own if necessary<br />
8.8.8.8;<br />
8.8.4.4;<br />
};<br />
<br />
allow-transfer {<br />
# this config is for a single master DNS server<br />
none;<br />
};<br />
<br />
};<br />
<br />
<br />
# Root servers (required zone for recursive queries)<br />
zone "." {<br />
type hint;<br />
file "named.root";<br />
};<br />
<br />
# Required localhost forward-/reverse zones <br />
zone "localhost" {<br />
type master;<br />
file "master/localhost.zone";<br />
};<br />
<br />
zone "0.0.127.in-addr.arpa" {<br />
type master;<br />
file "master/0.0.127.zone";<br />
};<br />
<br />
We chose '/var/named' as directory in 'named.conf' to be the place where our zonefiles, etc. reside. If you want to place them on a different location, please regard this in all further instructions.<br />
<br />
For more details on the parameters used in the sample 'named.conf', see 'man 5 named.conf'.<br />
<br />
=== Adding a user and group for Bind ===<br />
<br />
If you don't want to run bind as root (and I'm sure you don't want that!), we add an account and group (adapt the UID/GID if required):<br />
<br />
# groupadd -g 25 named<br />
# useradd -g named -u 25 -d /var/named -M -s /sbin/nologin named<br />
<br />
<br />
<br />
=== Getting the root name server list ===<br />
<br />
Download the root name server list from InterNIC:<br />
<br />
# wget -q -O /var/named/named.root http://www.internic.net/zones/named.root<br />
# chown named:named /var/named/named.root<br />
<br />
To have always the current file, you can add a cronjob to automatically download.<br />
<br />
<br />
<br />
=== Creating the localhost zone file ===<br />
<br />
Create a forward zone file ('/var/named/master/localhost.zone') for your 'localhost' zone:<br />
<br />
$TTL 3D<br />
<br />
$ORIGIN localhost.<br />
<br />
@ 1D IN SOA @ root (<br />
2013050101 ; serial<br />
8H ; refresh<br />
2H ; retry<br />
4W ; expiry<br />
1D ; minimum<br />
)<br />
<br />
@ IN NS @<br />
IN A 127.0.0.1<br />
<br />
<br />
<br />
=== Creating the 0.0.127.in-addr.arpa zone file ===<br />
<br />
Create a reverse zone file ('/var/named/master/0.0.127.zone') for your '0.0.127.in-addr.arpa' zone:<br />
<br />
$TTL 3D<br />
<br />
@ IN SOA localhost. root.localhost. (<br />
2013050101 ; Serial<br />
8H ; Refresh<br />
2H ; Retry<br />
4W ; Expire<br />
1D ; Minimum TTL<br />
)<br />
<br />
IN NS localhost.<br />
<br />
1 IN PTR localhost.<br />
<br />
<br />
<br />
=== Set permissions on the zone files ===<br />
<br />
# chown named:named /var/named/master/*.zone<br />
# chmod 640 /var/named/master/*.zone<br />
<br />
<br />
<br />
<br />
<br />
== Starting Bind ==<br />
<br />
# named -u named<br />
<br />
If the configuration is valid, you should see no errors on the console and in the system logfile.<br />
<br />
To have Bind automatically started at boot time, it's recommended, to create a init.d script or start it by systemd.<br />
<br />
<br />
<br />
<br />
<br />
== Testing your zone ==<br />
<br />
Now we try to lookup our zone entries. We tell the 'host' command, to use the resolver on 127.0.0.1, so that we don't query an foreign DNS server, that is maybe also configured in '/etc/resolv.conf'.<br />
<br />
First check the forward lookup for 'localhost':<br />
# host localhost. 127.0.0.1<br />
Using domain server:<br />
Name: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
Aliases: <br />
<br />
localhost has address 127.0.0.1<br />
<br />
And then the reverse lookup for '127.0.0.1':<br />
# host 127.0.0.1 127.0.0.1<br />
Using domain server:<br />
Name: 127.0.0.1<br />
Address: 127.0.0.1#53<br />
Aliases: <br />
<br />
1.0.0.127.in-addr.arpa domain name pointer localhost.<br />
<br />
<br />
<br />
<br />
<br />
= Configuring Bind as Samba Active Directory backend =<br />
<br />
* 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.<br />
<br />
<br />
<br />
== Bind 9.8 / 9.9 ==<br />
<br />
During provisioning/upgrading, a file ('/usr/local/samba/private/named.conf') was created, that must be included in your Bind named.conf:<br />
<br />
include "/usr/local/samba/private/named.conf";<br />
<br />
If you had provisioned with the internal DNS, there are some few steps required first to [[Changing_the_DNS_backend#Changing_from_Samba_Internal_DNS_to_BIND_DLZ|switch to Bind]].<br />
<br />
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.<br />
<br />
Restart Bind to have the included file being 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.<br />
<br />
== Bind 9.7==<br />
<br />
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.<br />
<br />
<br />
<br />
== DNS dynamic updates via Kerberos (optional, but recommended) ==<br />
<br />
Samba has the capability to automatically update the Bind zone files via Kerberos.<br />
<br />
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!<br />
<br />
To find out what version of Bind you are running, use<br />
<br />
# named -V<br />
<br />
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]].<br />
<br />
<br />
<br />
=== Bind 9.8 / 9.9 ===<br />
<br />
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:<br />
<br />
options {<br />
[...]<br />
tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";<br />
[...]<br />
};<br />
<br />
<br />
<br />
=== Bind 9.7 ===<br />
<br />
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:<br />
<br />
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.<br />
<br />
include "/usr/local/samba/private/named.conf.update";<br />
<br />
Be advised that if you include this file in Bind versions that don't support it, Bind will fail to start!<br />
<br />
You additionally need to set two environment variables when using 9.7:<br />
<br />
KEYTAB_FILE="/usr/local/samba/private/dns.keytab"<br />
KRB5_KTNAME="/usr/local/samba/private/dns.keytab"<br />
export KEYTAB_FILE<br />
export KRB5_KTNAME<br />
<br />
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.<br />
<br />
The 'dns.keytab' must be readable by the bind server process:<br />
<br />
# chown named:named /usr/local/samba/private/dns.keytab<br />
<br />
Normally, the provision/update should have setup these permissions for you automatically.<br />
<br />
Finally, you need to add the following to the options section of your named.conf:<br />
<br />
options {<br />
[...]<br />
tkey-gssapi-credential "DNS/server.samdom.example.com";<br />
tkey-domain "SAMDOM.EXAMPLE.COM";<br />
[...]<br />
};<br />
<br />
The last part of the credential in the first line must match the dns name of the server, you have set up.<br />
<br />
<br />
<br />
=== Testing/Debugging dynamic DNS updates ===<br />
<br />
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.<br />
<br />
If you want to test or debug this process, then please run as root:<br />
<br />
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names<br />
<br />
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.<br />
<br />
= Interaction with AppArmor or SELinux =<br />
<br />
If you are getting an error from samba_dnsupdate and nsupdate '''return dns_tkey_negotiategss: TKEY is unacceptable''' try the following:<br />
<br />
If you are using AppArmor or SELinux, you have to ensure that the Bind process has read access to the following files: <br />
* /usr/local/samba/private/dns.keytab<br />
* /usr/local/samba/private/named.conf<br />
as well read-write access to the<br />
* /usr/local/samba/private/dns/<br />
directory and it's own zone file(s).<br />
<br />
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.<br />
<br />
Permissions, SELinux Labeling and Policy<br />
<br />
These instructions are intended for RHEL6, but may serve as a guide for other distributions/versions.<br />
<br />
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.<br />
<br />
For all the commands below, make sure you have set the following environment variable:<br />
MYREALM="samdom.example.com"<br />
<br />
Set Permissions (SELinux):<br />
<br />
chown named:named /usr/local/samba/private/dns<br />
chgrp named /usr/local/samba/private/dns.keytab<br />
chmod g+r /usr/local/samba/private/dns.keytab<br />
chmod 775 /usr/local/samba/private/dns<br />
<br />
Label files (SELinux):<br />
<br />
chcon -t named_conf_t /usr/local/samba/private/dns.keytab<br />
chcon -t named_conf_t /usr/local/samba/private/named.conf.update<br />
chcon -t named_var_run_t /usr/local/samba/private/dns<br />
chcon -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
<br />
Set Label Persistence (SELinux):<br />
<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/dns.keytab<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf<br />
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf.update<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone<br />
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone.jnl<br />
<br />
AppArmor Configuration :<br />
<br />
Add the following to the end of /etc/apparmor.d/local/usr.sbin.named (create it if it doesn't already exist).<br />
<br />
# Samba4 DLZ and Active Directory Zones (default source installation)<br />
/usr/local/samba/lib/** rm,<br />
/usr/local/samba/private/dns.keytab r,<br />
/usr/local/samba/private/named.conf r,<br />
/usr/local/samba/private/dns/** rwk,<br />
<br />
= Debugging Bind as Samba AD backend =<br />
<br />
For enabling debugging on the Bind DLZ module, change the following line in '/usr/local/samba/private/named.conf' from<br />
<br />
database "dlopen .../bin/modules/bind9/dlz_bind9.so";<br />
<br />
to<br />
<br />
database "dlopen .../bin/modules/bind9/dlz_bind9.so -d 3";<br />
<br />
If you are running Bind 9.9, then add the '-d 3' to the corresponding line.<br />
<br />
Stop Bind and run the service manually to capture logs:<br />
<br />
# /usr/sbin/named -u named -f -g 2>&1 | tee named.log<br />
<br />
<br />
<br />
<br />
<br />
= Known issues and ways to fix/workaround =<br />
<br />
== Chroot Bind ==<br />
<br />
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.<br />
<br />
To disable chroot for Bind, see the documentation for your distribution. In some, you can set <br />
NAMED_RUN_CHROOTED="no"<br />
in "/etc/sysconfig/named" and restart the service.<br />
<br />
<br />
<br />
== Debian: Bind is listening on wrong IP address ==<br />
<br />
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.<br />
<br />
<br />
<br />
== Debian Sid: Named does not start ==<br />
<br />
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. <br />
<br />
<br />
<br />
== New added DNS entries are not resolvable ==<br />
<br />
If you have problems with resolving new added DNS entries using the BIND9 DLZ interface, you maybe want to check the following:<br />
<br />
The DNS zones and the metadata.ldb file in 'samba/private/dns/sam.ldb.d/' are hardlinks to 'samba/private/sam.ldb.d/'.<br />
Maybe you've copied/moved it across filesystems and the hardlinking got lost<br />
and you're now running with two different copies of the databases at the moment<br />
(You can test this by adding a new DNS entry, e. g. by 'samba-tool'. If you can't<br />
resolve it, check if the inodes differ).<br />
<br />
If you 'ls -i' on the two folders, you should see, that the following files<br />
have the same inodes (what indicates, that they are hard-linked):<br />
<br />
# ls -lai .../samba/private/sam.ldb.d/<br />
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb<br />
<br />
# ls -lai .../samba/private/dns/sam.ldb.d/<br />
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb<br />
17344372 -rw-rw---- 2 root named 421888 11. Nov 17:53 metadata.tdb<br />
<br />
If the files in the two folders have different inode numbers, then they<br />
aren't hard-links. To fix this, run<br />
<br />
# samba_upgradedns --dns-backend=BIND9_DLZ<br />
<br />
This will recreate the DNS files with correct hard links and permissions.<br />
<br />
Then restart Bind.<br />
<br />
<br />
<br />
== DDNS updates not working ==<br />
<br />
Check that the file '/etc/krb5.conf' is readable by Bind.</div>Mogga