Bug 1394320 - sssd can't update PTR dns record in AD leading to kerberos problems
Summary: sssd can't update PTR dns record in AD leading to kerberos problems
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 25
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-11-11 17:30 UTC by Bernhard Loos
Modified: 2017-12-12 10:35 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-12 10:35:19 UTC

Attachments (Terms of Use)
nsupdate log with authentication (4.48 KB, text/plain)
2016-11-16 12:48 UTC, Bernhard Loos
no flags Details
the requested log (3.30 KB, text/plain)
2017-04-04 15:50 UTC, Bernhard Loos
no flags Details

Description Bernhard Loos 2016-11-11 17:30:43 UTC
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):

How reproducible:

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.

Actual results:
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.

Expected results:
The PTR record in the AD gets created and nslookup of the IP of the machine succeeds.

Additional info:
This problem also affects debian jessie in a similar form.

Comment 1 Lukas Slebodnik 2016-11-11 18:49:04 UTC
I would recommend to follow wiki

Comment 2 Bernhard Loos 2016-11-15 19:06:33 UTC
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.

Comment 3 Jakub Hrozek 2016-11-16 10:40:35 UTC
I think it would still be helpful to provide the (sanitized if needed) nsupdate message dump, at least as a reference for other users..

Comment 4 Bernhard Loos 2016-11-16 12:45:54 UTC
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.

Comment 5 Bernhard Loos 2016-11-16 12:48:16 UTC
Created attachment 1221136 [details]
nsupdate log with authentication

nsupdate command used:
server dc.testdomain.example.com
zone testdomain.example.com
update del fedora25.testdomain.example.com A

Comment 6 Jakub Hrozek 2016-11-16 13:19:19 UTC
Interesting, I'm not sure what leads nsupdate to return 2 if the update in fact succeeds. Maybe Tomas (CC) knows?

Comment 7 Tomáš Hozza 🤓 2016-11-21 13:35:31 UTC
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.

Comment 8 Lukas Slebodnik 2017-03-16 08:04:37 UTC
Do you know answer for  Comment 6?

Comment 9 Petr Menšík 2017-03-21 11:30:11 UTC
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?

Comment 10 Bernhard Loos 2017-04-04 15:50:27 UTC
Created attachment 1268714 [details]
the requested log

Comment 11 Fedora End Of Life 2017-11-16 18:55:58 UTC
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'
of '25'.

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.

Comment 12 Fedora End Of Life 2017-12-12 10:35:19 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.