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

Thu May 26 15:23:04 UTC 2016

2016-05-26 16:42 GMT+02:00 Jo <j.o.l at live.com>:

> Hi Mathias,
> Once more: Thanks for your support and guidance! Actually I reconfigured
> only the first DC initially, assuming that the second join asks me as does
> the initial one - wrong assumption.

I did not understood what was the issue, sorry :/

> My take is the tools could be improved, e.g. : join of DC2 adds DNS record
> of DC2 to DC1 and verifies it is replicated before claiming success...
> looking in all the tools and logs for errors is tedious at best, but a big
> hurdle to me as a novice..
>

They are also after some time : )
The point is we can't really blame Samba team because AD is aggregation of
complex tools. Only is [or seems to me] a huge task. But in addition they
have to assemble these complex tools to not only make them work but to make
them work as and with Microsoft tools.
And there is certainly lot of work to do in their code to solve bugs,
improve perfs, add little features, add big features...

> In the meantime I started from scratch until I got the first DC working
> with BIND9_DLZ, then cloned it, changed the network configuration
> (including host names), deleted the smb.conf file, and retried the join.

One thing about cloning VMs: as DC are different in term of database - I
mean files in private/sam.ldb.d/*.tdb - (even if the differences are very
little) but also perhaps for files around (here I mean others files in
private directory), I do not dare to clone a working DC.
The way we use is to create a master system, ready to receive samba, we
clone that master (so without samba) and then we launch a home-made script
to deploy samba and perform various needed configurations on the new VM.

The idea is to be sure there is nothing left in data files for samba, for
these old data do not interfere with the new installation or the join.

> Even then I had to create the DNS record for DC2 manually and then restart
> replication, but now it is working - at least I can add users and they are
> replicated in both directions.
>

If your 2 DCs are running with --dns-backend=BIND9_DLZ you can set their
resolv.conf with "nameserver 127.0.0.1".
With BIND9_DLZ on DC a DC requested for SOA record will answer "I am SOA"
because each DC can modify the zone. So with that configuration the DC at
samba start up will launch samba_dnsupdate and these DNS updates wil be
send to the local Bind service. Which should not fail if you have set
correctly the rights on files used by Bind:
dns.keytab, private directory should not forbid Bind's user to get inside
to read dns.keytab and others, named.conf and dns directory and all files
in that directory.

> I am struggling however with joining a Win 10 Pro system as a member,
> reporting "The specified network resource or device is no longer valid".
> Staring to search for the problem or instructions...
> I do not plan to point my network clients to use the DCs as their primary
> DNS, but my DNS resolver (dnsmasq) knows how to forward the domain related
> requests to a DC, and windows is able to resolve the ldap SRV as
> expected...
>
Thanks & Best regards, Joachim
>
> With pleasure, good luck and have fun ;)

> -----Ursprüngliche Nachricht-----
> Von: samba [mailto:samba-bounces at lists.samba.org] Im Auftrag von mathias
> dufresne
> Gesendet: Mittwoch, 25. Mai 2016 10:48
> An: Jo <j.o.l at live.com>
> Cc: samba <samba at lists.samba.org>
> Betreff: Re: [Samba] DC2: TKEY is unacceptable, Failed DNS update?
>
> 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
> >
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>