On Mon, 2017-03-06 at 16:59 +0000, Rowland Penny via samba wrote:> On Mon, 6 Mar 2017 16:30:48 +0000 (UTC) > Mircea Husz via samba <samba at lists.samba.org> wrote: > > > All, > > > > I configured two DCs (Samba version 4.5.5) replicating ad.corp.com > > in > > two sites ( > > > > https://wiki.samba.org/index.php/Active_Directory_Sites) > > > > Following 'DNS configuration on Domain Controllers' section from > > this > > wiki > > https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_ > > Active_Directory > > > > If I configure nameserver DC1 to be the first resolver for DC2, > > samba_dnsupdate --verbose --all-names fails with ' > > tkey query failed: GSSAPI error: Major = Unspecified GSS failure. > > Minor code may provide more information, Minor = Server not found > > in > > Kerberos database.' > > > > The failure makes sense because each DC has keys only for itself in > > dns.keytab, as shown by 'klist > > -k /usr/local/samba/private/dns.keytab'. It makes no sense > > functionally for one DC to update another's DNS directly. > > > > Seems to me the failure from 'samba_dnsupdate --verbose --all- > > names' > > can be ignored when another DC's nameserver is listed first. Unless > > I'm missing something ? > > > > -Mike > > > > This is all down to the mythical 'islanding' problem. I personally > think that each DC should use its own ipaddress as the first > nameserver > in /etc/resolv.conf and another DC as the second.This can have some other impacts, if a DNS run hasn't happened by the time we first start up. I've got some patches to force the first DNS entries to be created during the domain join. I hope that will help a lot here, but this remains a problematic area. There is also an issue with a patch that went in to 4.5 to help us with resolv_wrapper that make the real-world use more fragile, because it requires that the DC we point to first already have the NS records (and our local IP won't have those yet). Using it the other way around (remote first, then local) seems to avoid some of that. I'm really sorry we have got this far in to Samba as an AD DC without this stuff 'just working', and I hope to have improved patches in master soon. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
On Tue, 07 Mar 2017 07:05:25 +1300 Andrew Bartlett <abartlet at samba.org> wrote:> This can have some other impacts, if a DNS run hasn't happened by the > time we first start up. I've got some patches to force the first DNS > entries to be created during the domain join. I hope that will help a > lot here, but this remains a problematic area.I think this will help a lot, the new DC's DNS records not being created during the join is undoubtedly a big problem.> > There is also an issue with a patch that went in to 4.5 to help us > with resolv_wrapper that make the real-world use more fragile, > because it requires that the DC we point to first already have the NS > records (and our local IP won't have those yet).The problem at the moment (as far as I see it) is that when samba_dnsupdate is first run on the new DC, it uses the kerberos info for the first DC and so doesn't work.> > Using it the other way around (remote first, then local) seems to > avoid some of that. > > I'm really sorry we have got this far in to Samba as an AD DC without > this stuff 'just working', and I hope to have improved patches in > master soon.There are quite a few things that need sorting, but as they say 'Rome wasn't built in a day' ;-) Rowland
On Mon, 2017-03-06 at 18:31 +0000, Rowland Penny via samba wrote:> On Tue, 07 Mar 2017 07:05:25 +1300 > Andrew Bartlett <abartlet at samba.org> wrote: > > > > > > This can have some other impacts, if a DNS run hasn't happened by > > the > > time we first start up. I've got some patches to force the first > > DNS > > entries to be created during the domain join. I hope that will > > help a > > lot here, but this remains a problematic area. > > I think this will help a lot, the new DC's DNS records not being > created during the join is undoubtedly a big problem. > > > > > > > There is also an issue with a patch that went in to 4.5 to help us > > with resolv_wrapper that make the real-world use more fragile, > > because it requires that the DC we point to first already have the > > NS > > records (and our local IP won't have those yet). > > The problem at the moment (as far as I see it) is that when > samba_dnsupdate is first run on the new DC, it uses the kerberos info > for the first DC and so doesn't work.Yes, one discovers that problem the hard way. But that's a one-time initial configuration issue so not a big deal.> > > > > > Using it the other way around (remote first, then local) seems to > > avoid some of that. > > > > I'm really sorry we have got this far in to Samba as an AD DC > > without > > this stuff 'just working', and I hope to have improved patches in > > master soon. > > There are quite a few things that need sorting, but as they say 'Rome > wasn't built in a day' ;-) > > Rowland >The recommendation to cross-reference DCs on the wiki comes after the second DC is running and synchronizing to the primary. It aims to be a best-practice recommendation, but if one follows the advice and cross- references DCs then 'samba_dnsupdate --verbose --all-names' gives a false postitive. The advice raises questions so I asked ... Thank you both for great answers. -Mike