[Samba] Samba AD /dns /dhcp

Thu Nov 30 16:25:25 UTC 2017

Hi there, thanks for your reply.  Probably I should add that:
a) I'm running Centos7 on the RPi3.
b) Compiled and installed samba 4.7.2 from source (packaged AD samba not
available for CentOS)
c) I haven't managed an AD before this thing landed in my lap, much less a
Samba AD :)

On 30 November 2017 at 15:45, Rowland Penny via samba <samba at lists.samba.org
> wrote:

>
> > Basically, I followd this set of instructions:
> > https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_
> Existing_Active_Directory
> > I have run into several problems.
> >
> >    1. The new DCs were not automatically added to the master zone A
> > record, i.e. "host -t A samdom.example.com localhost" would only
> > return the original host.  all of the other records (including GUIDS)
> > were inserted fine.  I ended up adding these manually.
>
> It is probably down to the version of Samba running on the rpi's, later
> versions should do this.
>
Original DC samba version is 4.5.0, also compiled from source
Possibly the issue was that the original DC01 had its record manually
inserted nin the dns, at least, the dns viewer flagged it as 'static'

>
> >    2. The SOA record for my dns zones seem to have migrated to point
> > to the last DC that I set up.  New zones get the orignal one (the one
> > with the master token).  I am unsure what this means, but from what I
> > can tell, dnsupdate contacts the host in the SOA record to make
> > updates.  What is the recommended practice here?  Does it matter
> > which of my now three redundant DNS hosts is the SOA?  How can I
> > change it?
>
> Again, later versions of Samba will make all Samba DCs authoritative.
>
Running 4.7.2.
What does that mean, can a zone have more than one SOA record?  Using the
DNS Manager tool on windows, the "properties" of a zone has only one
"Primary server" in the SOA.
The pre-existing zones seem to have all migrated to DC03 (the last one
where i installed the AD).   Is it ok to have different DCs as primary
server for a zone?  How does this affect redundancy if one DC goes offline?

>
> >3. I was unable to the dynamic DNS updates from DHCPD to
> > work without adding an "allow-update {any;};" clause (or similar) to
> > named.conf.  This was not documented anywhere and caused me a lot of
> > headaches, particularly since this setting was in the original DC and
> > so dynamic updates would work or not, based on the SOA record for the
> > zones.  What is the recommended practice here?
> You shouldn't need that line, at least, I never have.
> It might help if you post your bind conf files.
>

Sure, this is what I'm using.  It's the default one for Centos7 rpm bind,
modified for AD:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
        listen-on port 53 { 127.0.0.1; 192.168.0.0/16; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        # changes for BIND for AD
        #allow-query     { localhost; any; };
        allow-query { localhost; 192.168.0.0/16;};
        allow-recursion { localhost; 192.168.0.0/16;};
        auth-nxdomain yes;
        notify no;
        empty-zones-enable no;
        allow-transfer { none; };

        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable
recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need
to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST
enable access
           control to limit queries to your legitimate users. Failing to do
so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* option from /usr/local/samba/private/named.txt */
        tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
        allow-update     { localhost; any; };
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

/* the include file for samba support */
include "/usr/local/samba/private/named.conf";

>
> >
> >
> > I was unable to find on the samba wiki an overview over a recommended
> > setup of the combination of SambaAD/BIND/DHCP which is sort of a
> > minimum to maintain a site.  Particularly how they interact.
> > From what I can tell, Samba AD and BIND always go hand in hand, but
> > there are at most two DHCPD servers on the net, running on two of the
> > DCs.  Is this correct?
>
> Can I suggest you read again the Samba wikipage that you couldn't
> find:
>
> https://wiki.samba.org/index.php/Configure_DHCP_to_update_
> DNS_records_with_BIND9
>
> it changed yesterday because of a bug.
>
> Thanks, that's exactly the page I followed when it came to this. I had
already fixed the problems with the read access to /etc/dhcp, (chgrp dhcpd
/etc/dhcp) and setting the right path in the script.

> >
> > Finally, dynamic NDS updates from the DHCP server seem to take some 8
> > or nine seconds, during which time a cliend does not get a DHCPD ack.
> > Sometimes the client gives up waiting.
> > I'm currently looking into this, but here is a log:
>
> I feel this must be down to the rpi's, less than a second on my DCs
>
> I'm sure you are right.  I'm having problems with IO performance on this
particular machine.  I probably should replace the SD card.
However, a considerable time in the script (after analysis) is spent on
doing checking, particularly the wbinfo -u call, which can take anything
from .17 seconds to 5 seconds in my case.
"wbinfo -i dhcpduser" is consistently faster.
I will continue to  investigate.  I"ll remove the redundant wbinfo call in
my install, since it is only there for prolem diagnostics.

Cheers!

- K