samba - May 2020 - AD DC without integrated DNS

Hi all,

(Samba 4.9.5-Debian (buster) with BIND 9.11.5.P4)

I'm wondering, is it really strictly necessary to use the built-in DNS
backend
or the BIND9 DLZ plugin, at least in a forest with no Windows Server DCs? The 
LDAP and Kerberos I can understand, but DNS is just a bunch of records, right? 
There are a number of records that need to be in place in order for clients to 
find the DCs and the DCs to find each other, but they rarely change, do they, 
unless you regularly add and remove DCs, or change their IP addresses, which 
seems to be a relatively involved procedure?

I can configure BIND9 with a normal dynamic zone, set tkey-gssapi-credential, 
tkey-domain, and tkey-gssapi-keytab (except this doesn't seem to work the
way
the manual says; named still only reads the system keytab, so I put the keytab 
from /var/lib/samba/bind-dns/dns.keytab there), along with the update-policy 
from /var/lib/samba/bind-dns/named.conf.update, and that kinda works; 
samba_dnsupdate can insert all the records from dns_update_cache, *except* the 
NS record for the _msdcs zone (since the aforementioned update-policy
doesn't
allow NS records), and if I set up that as a separate zone, samba_dnsupdate 
starts using a different ticket with a corresponding SPN, which is logical, 
but that one is not in the keytab, so I wonder how that works when using the 
BIND9_DLZ backend, which I thought samba_dnsupdate talked to in exactly the 
same way.
 
https://lists.samba.org/archive/samba/2016-March/198033.html discusses 
disabling DNS services altogether on a Samba DC, but that was in an 
environment with dozens of other DCs. I'm working at a small business and
are
hardly planning to join any Windows machines to this domain, except for one or 
two for the purpose of testing software that we can't install on multiple 
personal laptops (most of which were bought with Windows Home pre-installed), 
and which it would be kinda neat to be able to use centralized accounts to 
logon to. Other than that, the main goal is to implement Kerberos/GSSAPI 
authentication for services running on Debian (including one Samba file 
server), and setting up a Samba AD DC seemed easier than configuring and 
integrating OpenLDAP+Kerberos by hand (and choosing between MIT and Heimdal), 
but perhaps not more convenient for Windows users unless their computers are 
joined to the domain? Currently we're running DHCP on a pfSense firewall, 
dynamically updating a normal BIND9 zone, and I don't want to mess with
that;
making manual changes is much easier with a plain text zone file. I could make 
the AD domain a separate zone and keep it to a minimum. I have done this 
provisionally, and it works - SPNs can be anything and Linux machines with 
FQDNs outside the AD domain can still be joined to it with net ads join - but 
I'm still exploring my options.

So in summary, my questions are: Under these circumstances, if I manually add 
the required DNS records to the right zone (and disable the dnsupdate 
service), what works and what will break (besides joining new DCs, I guess)? 
Alternatively, is it possible to get GSS-TSIG updates working fully with a 
standard zone, or can it work well enough without _msdcs as a separate zone? 
Can I hack the dns_update_list?

The documentation talks a lot about special requirements and limitations when 
running Samba as an AD DC, but it doesn't go into much technical detail as
to
the reasons for those, and I guess it's because AD is complicated.

Thanks!
-- 
Magnus Holmgren        holmgren at lysator.liu.se (this is not my work email)

On 04/05/2020 18:35, Magnus Holmgren via samba wrote:
> Hi all,
>
> (Samba 4.9.5-Debian (buster) with BIND 9.11.5.P4)
>
> I'm wondering, is it really strictly necessary to use the built-in DNS
backend
> or the BIND9 DLZ plugin, at least in a forest with no Windows Server DCs?
If you only have only one or two DC's. then, yes it
is.
> samba_dnsupdate can insert all the records from dns_update_cache, *except*
the
> NS record for the _msdcs zone
Not sure I understand that, by default a Samba AD DC has two zones:
samdom.example.com (DomainDnsZone)
_msdcs.samdom.example.com (ForestDnsZone)

Both of which can be updated by samba_dnsupdate
> hardly planning to join any Windows machines to this domain, except for one
or
> two for the purpose of testing software that we can't install on
multiple
> personal laptops (most of which were bought with Windows Home
pre-installed),
That is never going to work, you cannot join a Windows Home client to a 
domain.
> The documentation talks a lot about special requirements and limitations
when
> running Samba as an AD DC, but it doesn't go into much technical detail
as to
> the reasons for those, and I guess it's because AD is complicated.
Yes, AD is complicated, but your way would make it even more complicated 
and I don't think it is going to work correctly, if at all.

You can run an AD DC without it being a dns server, but only if there 
are more than two DC's (one plus a spare).

Rowland

m?ndag 4 maj 2020 kl. 21:17:13 CEST skrev  Rowland penny via
samba:
> > samba_dnsupdate can insert all the records from dns_update_cache,
*except*
> > the NS record for the _msdcs zone
> 
> Not sure I understand that, by default a Samba AD DC has two zones:
> samdom.example.com (DomainDnsZone)
> _msdcs.samdom.example.com (ForestDnsZone)
> 
> Both of which can be updated by samba_dnsupdate
Yes, samba_dnsupdate successfully injects all the necessary RRs, both for the 
domain and for the forest, except they don't get separated into two zones.
But
that's just an technical-organizational detail when there's only one AD
domain
anyway. As long as all the A/AAAA and SRV records are in place and can be 
found by the clients, what, exactly, would not work? Joining a machine to an 
AD domain doesn't require adding DNS records to its zone; the FQDN of the 
machine can be entirely different, AFAICT. Are there any DNS-related 
operations that require talking some other protocol? (samba_dnsupgrade falling 
back to samba-tool when DDNS doesn't work will of course not be an option.)
> > hardly planning to join any Windows machines to this domain, except
for
> > one or two for the purpose of testing software that we can't
install on
> > multiple personal laptops (most of which were bought with Windows Home
> > pre-installed),
> That is never going to work, you cannot join a Windows Home client to a
> domain.
Exactly. I said we're hardly planning on joining any Windows machines to the
domain, and they're mostly running Windows Home anyway (we could buy Pro 
upgrades, though).

-- 
Magnus Holmgren        holmgren at lysator.liu.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200504/19f1b9a1/signature.sig>