Description of problem:
I have a Fedora 25 Workstation Machine and 2 Debian Jessie machines in a Windows Active Directory domain. All of them were joined with realmd and use sssd.
None of them are able to update their PTR DNS records which makes reverse lookups impossible which in turn leads to various kerberos problems.
The actual problem appears to be, that nsupdate can't authenticate to the AD.
The error message is "; TSIG error with server: tsig verify failure".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. join the machine to the domain using realmd
2. stop the sssd service
3. run sssd -d 0xffff -i as root
4. search the point where sssd tries to update the dns records with nsupdate
I can't reproduce the error message with plain nsupdate on fedora (I get a different kerberos error), but I can do so on debian.
The nsupdate command prints "; TSIG error with server: tsig verify failure" during update of the A (forward) records and returns 2 (funnily the update still succeeds). sssd interprets this as an error and doesn't even try to update the PTR (reverse) record. The reverse record update needs TSIG authentication, of it fails.
The PTR record in the AD gets created and nslookup of the IP of the machine succeeds.
This problem also affects debian jessie in a similar form.
I would recommend to follow wiki
With the HOWTO (by the way the commands given there are invalid) I managed to reproduce the problem with plain nsupdate. No matter what I do, the DNS server doesn't accept the kerberos ticket, I always get the "; TSIG error with server: tsig verify failure" error.
I did set up a new AD domain for testing pruporses and unfortunately I can't reproduce the problem there (nsupdate works as expected).
I also did some tracing with wireshark to figure out how Windows 7 behaves.
It updates the A record with unauthenticated DNS update commands and the PTR record is set by the DHCP server, by request of the windows DHCP client. If I use the fqdn.fqdn option in dhclient, I can get the same behavior and everything seems to work.
I'm not exactly sure what the best solution would look like, maybe to configure dhclient to match the Windows behavior.
I can provide additional information but I'm not all that sure what would be helpful. A debug log from nsupdate doesn't seem to contain anything useful.
I think it would still be helpful to provide the (sanitized if needed) nsupdate message dump, at least as a reference for other users..
I managed to reproduce the problem in my test setup. It's actually very simple, but I got confused by a missing reverse lookup zone in our AD :/
Basically, it's enough to enable unsafe dynamic DNS update in the DNS server configuration.
In this case the GSS-TSIG authentication always fails. The DNS server still runs the query and the update succeeds, but nsupdate returns an error (return code 2).
I'm not sure, if nsupdate should return success in this case, or if sssd should ignore this return code. Windows clients always seem to try an unauthenticated update first and switch to an authenticated update if this fails.
I will attach an nsupdate log, if you need any further informations, please don't hesitate to ask.
Created attachment 1221136 [details]
nsupdate log with authentication
nsupdate command used:
update del fedora25.testdomain.example.com A
Interesting, I'm not sure what leads nsupdate to return 2 if the update in fact succeeds. Maybe Tomas (CC) knows?
I'm adding Petr Mensik (soon to be official BIND maintainer) to CC as I will not have time to look into this in near future and I would have to inspect the code to tell where may be the problem.
Do you know answer for Comment 6?
Hi. Yes, this issue is obviously known to the authors of nsupdate. But I doubt they are willing to fix it. They report it as violation of RFC 2845 by MS DNS in a comment. It returns 2 on any error. Unfortunately also TSIG failure is reported as an error, even if server reported success and nsupdate understands it.
Simple fix is commented out in the source code since 2006. See https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/nsupdate/nsupdate.c;h=a631dd8db467c436e1fc3ebf83333442ad999ff9;hb=289ae548d52bc8f982d9823af64cafda7bd92232#l1750
It would be easy to return different error codes for different error. You might ignore specific error if you wanted. But it should be still reported as failure.
Can you make an update log also with nsupdate parameter -L 3?
Created attachment 1268714 [details]
the requested log
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.