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

1106 views
Skip to first unread message

Jo L

unread,
May 16, 2016, 3:50:03 AM5/16/16
to
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

mathias dufresne

unread,
May 23, 2016, 9:30:03 AM5/23/16
to
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

Jo

unread,
May 24, 2016, 4:10:03 PM5/24/16
to
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-...@lists.samba.org] Im Auftrag von mathias dufresne
Gesendet: Montag, 23. Mai 2016 15:19
An: Jo L <j....@live.com>
Cc: sa...@lists.samba.org
Betreff: Re: [Samba] DC2: TKEY is unacceptable, Failed DNS update?

mathias dufresne

unread,
May 25, 2016, 5:00:03 AM5/25/16
to
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 !

Jo

unread,
May 26, 2016, 10:50:03 AM5/26/16
to
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. 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..
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. 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.
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

-----Ursprüngliche Nachricht-----
Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von mathias dufresne
Gesendet: Mittwoch, 25. Mai 2016 10:48
An: Jo <j....@live.com>
Cc: samba <sa...@lists.samba.org>

mathias dufresne

unread,
May 26, 2016, 11:30:04 AM5/26/16
to
2016-05-26 16:42 GMT+02:00 Jo <j....@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 ;)

Jo

unread,
May 26, 2016, 11:40:03 AM5/26/16
to
Hi Marc,
I appreciate that you reply, but I got it resolved by following the advice of Mathias. I was aware of the links below, however the first is about using the BIND9_DLZ backend, and at the time I experienced the issue I was using the internal one.
Marc & Mathias,
The 2nd link that Marc references is about a DC should not use itself for DNS queries is exactly the opposite of your recommendation to use localhost. In fact I am not really decided yet, given the fact that using the other DC is long term via a VPN connection, albeit at least slow if not unreliable, and also relying on both DCs up at the same time, whereas using the local instance for sure requires some extra monitoring in order to prevent stuck replications.
Any idea?
Thanks & Best regards, Joachim

-----Ursprüngliche Nachricht-----
Von: Marc Muehlfeld [mailto:mmueh...@samba.org]
Gesendet: Donnerstag, 26. Mai 2016 17:16
An: Jo L <j....@live.com>
Betreff: Re: [Samba] DC2: TKEY is unacceptable, Failed DNS update?

Hello,

Am 15.05.2016 um 22:36 schrieb Jo L:
> /usr/sbin/samba_dnsupdate:
> dns_tkey_negotiategss: TKEY is unacceptable

Have you checked
https://wiki.samba.org/index.php/Dns_tkey_negotiategss:_TKEY_is_unacceptable



> 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.

It's better if you use the local IP only as _secondary_ nameserver entry in your resolv.conf.
https://blogs.technet.microsoft.com/askds/2010/07/17/friday-mail-sack-saturday-edition/#dnsbest



Regards,
Marc

Rowland penny

unread,
May 26, 2016, 11:40:03 AM5/26/16
to
On 26/05/16 15:42, Jo wrote:
> 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. 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..
> 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.

Cloning the Samba database is pointless, the provision part of the join
wipes the database and creates it from new.

> Even then I had to create the DNS record for DC2 manually

What you should have done on a new secondary DC, is start the 'samba'
binary (or restart it, if it is running, which it shouldn't be), this
will then run 'samba_upgradedns'. This will then use the
'dns_update_list' file to create various DNS settings in AD including
the new DCs A and if required AAAA records.

Rowland

Andrew Bartlett

unread,
May 26, 2016, 3:20:03 PM5/26/16
to
On Thu, 2016-05-26 at 17:32 +0200, Jo wrote:
> Hi Marc,
> I appreciate that you reply, but I got it resolved by following the
> advice of Mathias. I was aware of the links below, however the first
> is about using the BIND9_DLZ backend, and at the time I experienced
> the issue I was using the internal one.
> Marc & Mathias,
> The 2nd link that Marc references is about a DC should not use itself
> for DNS queries is exactly the opposite of your recommendation to use
> localhost. In fact I am not really decided yet, given the fact that
> using the other DC is long term via a VPN connection, albeit at least
> slow if not unreliable, and also relying on both DCs up at the same
> time, whereas using the local instance for sure requires some extra
> monitoring in order to prevent stuck replications.
> Any idea?
> Thanks & Best regards, Joachim

Yes, it should use itself as the DNS server, once the initial
registration work is done.

We know this area isn't ideal, and we are actively working to improve
it. I expect Samba 4.5 to be much more sensible in this regard, given
the patches I've seen from other Samba team members and the work my
team at Catalyst is currently doing for our clients.

Thanks,

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

Jo

unread,
May 27, 2016, 3:30:04 AM5/27/16
to
Hi Andrew,
thanks for the clarification. Makes me feel more comfortable with what I would have preferred. Until that´s improved in software - what do you recommend to monitor in order to verify the forest is not going to split into individual trees?
Thanks & Best regards, Joachim

-----Ursprüngliche Nachricht-----
Von: samba [mailto:samba-...@lists.samba.org] Im Auftrag von Andrew Bartlett
Gesendet: Donnerstag, 26. Mai 2016 21:11
An: Jo <j....@live.com>; 'Marc Muehlfeld' <mmueh...@samba.org>; 'mathias dufresne' <infra...@gmail.com>
Cc: 'samba' <sa...@lists.samba.org>
Betreff: Re: [Samba] DC2: TKEY is unacceptable, Failed DNS update?

Reply all
Reply to author
Forward
0 new messages