[Samba] Fixing dns_tkey_gssnegotiate: TKEY is unacceptable but stuck on check_spn_alias_collision
Matthew Schumacher
matt.s at aptalaska.net
Mon Aug 8 17:18:38 UTC 2022
On 8/8/22 9:02 AM, Rowland Penny via samba wrote:
>
>> I can't post the output of that script due to it showing a lot of
>> internal information, but I can say :
> Did you miss this:
>
> Please check this and if required, sanitise it.
Apologies, I did miss that.
>> */etc/resolve.conf is 127.0.0.1 and then the other DNS servers* *(*I
>> think this is the problem*)*
> You should be using the DC's ipaddress as the nameserver.
>
Roger.
> You could use winbind instead of ldap, but you would probably need to
> create the required links.
I may look at that, but have a lot of history with ldap with a number of
other things like radius and web apps using ldap as well. I don't think
this is related.
>> --------------------------------------------------------------------
>>
>> Given the above, let me include my /etc/named.conf
>>
>> --------------------------------------------------------------------
>> options {
>> directory "/var/named";
>> /*
>> * If there is a firewall between you and nameservers you want
>> * to talk to, you might need to uncomment the query-source
>> * directive below. Previous versions of BIND always asked
>> * questions using port 53, but BIND 8.1 uses an unprivileged
>> * port by default.
>> */
>> // query-source address * port 53;
>>
>> tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
>> minimal-responses yes;
>>
>> // forwarders {
>> // x.x.x.x;
>> // };
> You need to set the 'forwarders'
What would I set this to the public DNS server? I looked at the wiki
(https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End) and it talks
about putting a DNS server in front of BIND9_DLZ to handle everything
but domain related queries, but if this is on the DC itself, then does
forwarding queries to the public name server accomplish the same goals?
Looking at the DNS servers in /etc/resolve.conf it occurred to me
>> that
>> using the loopback address wouldn't work, so I removed that, and it
>> updated the dns against another domain controller without issue.
>>
>> So, my question. Is there any reason the local bind server with the
>> DLZ
>> plugin can't take kerberos authenticated updates? Any thoughts on
>> how
>> to debug this?
> Are you sure it isn't working now that you have fixed /etc/resolv.conf
> ?
Yes, I'm sure. If I delete this host from
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net, then with the
IP of this host listed first in /etc/resolv.conf call samba_dnsupdate
--verbose I get:
1 DNS updates and 0 DNS deletes needed
Successfully obtained Kerberos ticket to DNS/dc-2.ad.domain.net as DC-2$
update(nsupdate): SRV
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net
dc-2.ad.domain.net 389
Calling nsupdate for SRV
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net
dc-2.ad.domain.net 389 (add)
Successfully obtained Kerberos ticket to DNS/dc-2.ad.domain.net as DC-2$
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net. 900 IN SRV 0
100 389 dc-2.ad.domain.net.
dns_tkey_gssnegotiate: TKEY is unacceptable
Failed nsupdate: 1
Failed update of 1 entries
If I remove the local samba host from the first nameserver record in
/etc/resolv.conf and allow the first record to be an actual windows DC I
get:
1 DNS updates and 0 DNS deletes needed
Successfully obtained Kerberos ticket to DNS/ktchdc.ad.domain.net as DC-2$
update(nsupdate): SRV
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net
dc-2.ad.domain.net 389
Calling nsupdate for SRV
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net
dec-2.ad.domain.net 389 (add)
Successfully obtained Kerberos ticket to DNS/ktchdc.ad.domain.net as DC-2$
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
_ldap._tcp.Default-First-Site-Name._sites.ad.domain.net. 900 IN SRV 0
100 389 dc-2.admin.aptalaska.net.
I started looking into enabling debug on the bind side and added this to
my named.conf
logging {
channel default_file {
file "/var/log/named.log" size 10m;
severity debug;
print-time yes;
print-severity yes;
print-category yes;
};
category default{ default_file; };
};
But still don't see anything in the log related to kerberos auth.
Looking at my packet sniffer I see:
Transmission Control Protocol, Src Port: 53, Dst Port: 58987, Seq: 1,
Ack: 1651, Len: 107
Domain Name System (response)
Length: 105
Transaction ID: 0x43ce
Flags: 0x8080 Standard query response, No error
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
1951668233.sig-dc-2.ad.domain.net: type TKEY, class ANY
Name: 1951668233.dc-2.ad.domain.net
[Name Length: 49]
[Label Count: 5]
Type: TKEY (Transaction Key) (249)
Class: ANY (0x00ff)
Answers
1951668233.sig-dc-2.ad.domain.net: type TKEY, class ANY
Name: 1951668233.dc-2.ad.domain.net
Type: TKEY (Transaction Key) (249)
Class: ANY (0x00ff)
Time to live: 0 (0 seconds)
Data length: 26
Algorithm name: gss-tsig
Signature Inception: (0)Dec 31, 1969 16:00:00.000000000 PST
Signature Expiration: (0)Dec 31, 1969 16:00:00.000000000 PST
Mode: GSSAPI (3)
Error: Key not recognized (17)
Key Size: 0
Other Size: 0
[Request In: 189]
[Time: 0.000930000 seconds]
Looking at /var/lib/samba/bind-dns/dns.keytab I see that the timestamp
hasn't changed for 3 days. Is that right? Does this file stay fairly
static?
>> Also, samba_dnsupdate --use-samba-tool works just fine, so, can I
>> configure samba to use that internally when calling samba-dnsupdate
>> with?
>>
>> dns update command = /usr/sbin/samba_dnsupdate --use-samba-tool
>>
>> Any disadvantages of doing it that way?
> None what so ever.
>
> Rowland
>
>
Don't the workstations use kerberos against the name server to update
their IP addresses? If so, wouldn't that break if I just reverted to
using --use-samba-tool?
Thanks for the help!
Matt
More information about the samba
mailing list