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 zoneNot 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_dnsupdateYes, 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>
Possibly Parallel Threads
- AD DC without integrated DNS
- default backend = rid not showing full group information for users
- default backend = rid not showing full group information for users
- default backend = rid not showing full group information for users
- AD DC without integrated DNS