[Samba] Fixing dns_tkey_gssnegotiate: TKEY is unacceptable but stuck on check_spn_alias_collision

[Matthew Schumacher]

On 8/8/22 10:43 AM, Rowland Penny via samba wrote:
>>> 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
> This usually happens when a DC is joined to an existing Samba AD domain
> (at which point the nameserver needs to be pointing at another DC) and
> then just restarted without changing the nameserver to itself. Have you
> tried restarting Samba ?


Yes, I tried restarted samba and bind.  It makes sense that there is the 
cart before the horse when first joining the domain, for that reason it 
makes sense to not put the local IP address in /etc/resolv.conf until 
after the join, but even after replication is working and bind on the 
samba DC has all of the records, it simply won't let me update with gssapi.

Doing a bit more debugging, I can see that if I delete the dns-dc-2 
user, then call "samba_upgradedns --dns-backend=BIND9_DLZ" it correctly 
recreates the user as well as a new /var/lib/samba/bind-dns/dns.keytab.  
I can even confirm that user works with other domain controllers as I 
have commented out "os.unlink(ccachename) and os.unlink(tmpfile)" in 
samba-dnsupdate so that I have access to cache file and update commands:

Calling it manually I get:

KRB5CCNAME=/tmp/tmpwdgm8jd4 KRB5_CONFIG=/var/lib/samba/private/krb5.conf 
cat /tmp/tmpzu6yvua4 | nsupdate -g

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

But... if I edit /tmp/tmpzu6yvua4 and change "server dc-2.ad.domain.net" 
to "server windowsserver.ad.domain.net" and call the same command, it 
updates without any issues.

So, it seems that the dns-dc-2 account is fine, and getting Kerberos 
tickets works fine too.  The only thing that makes sense is that bind is 
misconfigured, but I double confirmed that bind is using 
/var/lib/samba/bind-dns/dns.keytab and samba is creating it, and it has 
read permissions from the named user, and if I start a shell as that 
user, I can read the file.

The only thing I can think of is that there is some compatibility 
issue.  The bind server is compiled against the systems (slackware) MIT 
krb5 implementation while Samba is using it's internal Heimdal 
implementation because it wasn't reliable when built against the systems 
MIT libraries.

Anything else you can think of?  I'm running samba  4.16.4 and bind 9.16.29.


>> 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?
> Yes they use kerberos, but you mixing up the two things, the clients
> will be using their ticket and samba-dnsupdate uses the DC ticket.
>
> Rowland

I see, but I can't get the samba bind/dlz system to work with gssapi 
updates at all, so I would think that would affect other workstations.  
I'm not sure how I would test it.

Many Thanks
Matt