[Samba] DC2: TKEY is unacceptable, Failed DNS update?

Wed May 25 08:48:26 UTC 2016

So you have 2 DC using BIND9_DLZ as dns backend, they both answer DNS from
clients.
Am I right?

If yes, how are configured your client DNS resolvers? Resolver on clients
should be aiming one of your DC (or the two of them in case of DC downtime).
NOTE: "should" only because you could make clients using your company DNS
servers as resolvers if these DNS servers knows how to forward request
about AD DNS zones to your AD DNS servers.

Once (windows) clients resolver is configured to check that configuration
try something like that:
nslookup -type=srv _ldap._tcp.YOUR.AD.DOMAIN.TLD

This should reply 2 addresses: one per DC.

This test is because Kerberos stuffs and AD stuffs are relying on SRV
records to get information about how to reach the different services.

Now I must say I don't expect you get an answer with 2 IP addresses as you
wrote initially that DC1 can not resolve DC2.
The fact DC1 can't resolve DC2 should come from DNS updates issues. Samba4
is using a python script called "samba_dnsupdate" to check that DNS records
related to local DC are well declared into AD, and if they are not this
script is meant to create them, removing by the way those which have to be
removed (if you switch a DC from one site to another for instance).

With SAMBA_INTERNAL dns backend I believe samba_dnsupdate is not working
for now.
With BIND9_DLZ dns backend samba_dnsupdate is working once Bind is well
configured to work with Samba (tricky point to achieve that is rights on
files into private directory).

You should first create DC2 DNS entries by adding them manually or by
setting Bind9_DLZ as backend and let Samba (with samba_dnsupdate which is
run at each start up of samba daemon) do the job.

To create entries manually:
samba_dnsupdate --verbose --all-names

That command which these switches shows what the script is trying to do,
showing information about each DNS record to create. You can use these
information to create manually the entries with "samba-tool dns add ....".

Then, once DNS entries are correctly declared and DNS resolver on clients
are well declared too, it should work.

Good luck !

2016-05-24 21:57 GMT+02:00 Jo <j.o.l at live.com>:

> Hi Mathias,
> thanks for the hint. My interpretation so far was that complex involves
> managing any data in addition to what the AD is supposed to manage anyway.
> Anyway, I tried to follow your advice, but not to success so far. On Ubuntu
> 16.04, bind is running under the user bind instead of root, and app armor
> is active. I figured out how to change both and bind starts successfully
> and answers questions, but when I try another domain join, the 2nd system
> complains there is no writeable DC. Any idea how to fix that or what to
> check?
> Thanks,  Joachim
>
> -----Ursprüngliche Nachricht-----
> Von: samba [mailto:samba-bounces at lists.samba.org] Im Auftrag von mathias
> dufresne
> Gesendet: Montag, 23. Mai 2016 15:19
> An: Jo L <j.o.l at live.com>
> Cc: samba at lists.samba.org
> Betreff: Re: [Samba] DC2: TKEY is unacceptable, Failed DNS update?
>
> Hi,
>
> Are you using Samba's internal DNS or Bind?
>
> If you are using Bind9_DLZ as dns-backend it should be a right issue on
> files used by Bind itself (ie private/dns.keytab, private/named.conf,
> private/dns or private/dns/* and of course private itself).
>
> If you are running internal DNS as backend, you can change that parameter
> into smb.conf:
> from: allow dns updates = secure only (default, not necessarily written
> into smb.conf)
> to: allow dns updates = unsecure
> And after restarting samba the command "samba_dnsupdate" should work
> without error.
>
> The Samba wiki told for some time you should use BIND9_DLZ backend for DNS
> if you have a complex DNS configuration. Two DC could be a complex
> configuration... especially if you want them to be on different network.
>
> Another issue with internal DNS: when AD DNS is supposed to be
> multi-master (each DNS server reply "I am SOA" for every DNS server is able
> to receive DNS updates and push them into AD DB) with internal DNS the only
> one DNS server replying "I am SOA" is the one declared as SOA into AD DB.
> Here the issue is simple: if the DC declared as SOA into AD is down, no
> DNS server would handle DNS updates as they are not SOA...
>
> In short: if you want to get rid of DNS issues stop using internal DNS
> which is not yet ready. Replace it by BIND9_DLZ which is really easy and
> you will start to love DNS management : )
>
> Cheers, and sorry to have again misspoken about internal DNS backend...
>
> mathias
>
> 2016-05-15 22:36 GMT+02:00 Jo L <j.o.l at live.com>:
>
> > I installed
> > two virtual machines with Samba as domain controllers for the same
> domain.
> > I
> > was struggling with network and DNS configuration initially, maybe my
> > problem is related.
> >
> > DC1 starts
> > up ok, the last line of the log reads
> >
> > STATUS=daemon
> > 'samba' finished starting up and ready to serve connections
> >
> > DC2 starts
> > with plenty of lines
> >
> >  [2016/05/15 22:00:32.744910,  0]
> > ../lib/util/util_runcmd.c:328(samba_runcmd_io_handler)
> >
> >   /usr/sbin/samba_dnsupdate:
> > dns_tkey_negotiategss: TKEY is unacceptable
> >
> > and also
> >
> > [2016/05/15
> > 22:00:34.232460,  0]
> > ../source4/dsdb/dns/dns_update.c:294(dnsupdate_nameupdate_done)
> >
> >   ../source4/dsdb/dns/dns_update.c:294: Failed DNS update -
> > NT_STATUS_UNSUCCESSFULBoth use bridge network configuration, static IP
> > addresses, /etc/resolv.conf points to themselves (and the other), they
> > can ping each other, but DC1 cannot resolve the name of DC2. I was
> > assuming that the name information is part of the replicated
> > information?When DC2 joined DC1, resolv.conf was pointing to DC1. I
> > changed that later on as I want to be able to continue to operate DC2
> > while DC1 is down. Ultimately I want to run the DCs in two different
> > networks that may occasionally become disconnected.
> >
> > What am I doing
> > wrong?
> >
> > Thx -
> > Joachim
> > --
> > To unsubscribe from this list go to the following URL and read the
> > instructions:  https://lists.samba.org/mailman/options/samba
> >
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>