RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1261155 - nsupdate exits on first GSSAPI error instead of processing other commands
Summary: nsupdate exits on first GSSAPI error instead of processing other commands
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 7.2
Assignee: Pavel Reichl
QA Contact: Dan Lavu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-08 17:52 UTC by Dan Lavu
Modified: 2020-05-02 18:09 UTC (History)
15 users (show)

Fixed In Version: sssd-1.13.0-33.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1262430 (view as bug list)
Environment:
Last Closed: 2015-11-19 11:40:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sssd_no_ptr.log (105.41 KB, text/plain)
2015-09-08 17:52 UTC, Dan Lavu 		no flags Details
sssd_logs_with_dyndns_update_true (152.80 KB, text/plain)
2015-09-10 08:16 UTC, Dan Lavu 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3824 0 None None None 2020-05-02 18:09:56 UTC
Red Hat Product Errata RHSA-2015:2355 0 normal SHIPPED_LIVE Low: sssd security, bug fix, and enhancement update 2015-11-19 10:27:42 UTC

Description Dan Lavu 2015-09-08 17:52:57 UTC 
Created attachment 1071439 [details]
sssd_no_ptr.log

Description of problem:
This looks like a regression, tests are failing to update the ptr record using the ad provider. 

Version-Release number of selected component (if applicable):
sssd-client-1.13.0-26.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. realm join sssd2012r2.com 
2. check AD for the PTR record
3.

Actual results:
A record exists, PTR does not

Expected results:
A record and PTR record exits


Additional info:
Comment 2 Dan Lavu 2015-09-08 17:58:59 UTC 
Forgot to mention, logs show that dyndns is set to false and update_ptr is true, sssd.conf and is not adhering to the defaults values. Configuration is posted below.

[sssd]
domains = sssdad2012r2.com
config_file_version = 2
services = nss, pam

[domain/sssdad2012r2.com]
ad_domain = sssdad2012r2.com
krb5_realm = SSSDAD2012R2.COM
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

[sssd]
debug_level = 0xFFFF
[domain/sssdad2012r2.com]
debug_level = 0xFFFF
Comment 3 Lukas Slebodnik 2015-09-09 08:13:48 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2783
Comment 4 Pavel Reichl 2015-09-09 11:48:18 UTC 
Dan, do I understand it correctly that it seems that we have changed default value of dyndns_update option for AD from true to false?
Comment 6 Lukas Slebodnik 2015-09-09 14:28:43 UTC 
(In reply to Pavel Reichl from comment #4)
> Dan, do I understand it correctly that it seems that we have changed default
> value of dyndns_update option for AD from true to false?
I checked the source code of sssd-1.13.0-26.el7.x86_64 and the default value for dyndns_update_ptr is TRUE; it was not changed.

My understanding is that ptr record is not updated even though it should be.
Comment 7 Pavel Reichl 2015-09-09 14:34:38 UTC 
In the attached log you can see: "Option dyndns_update is FALSE"
Comment 8 Michal Zidek 2015-09-09 14:54:21 UTC 
Does setting dyndns_update explicitly to true help? That would confirm that we have wrong defaults.
Comment 9 Pavel Reichl 2015-09-09 14:57:16 UTC 
Yes Michal I agree that would help, but I'm not able to replicate the issue so far only Dan and Lukas seem to be able to replicate.
Comment 10 Lukas Slebodnik 2015-09-09 15:18:50 UTC 
Dan,
could you upload log files for sssd.conf from comment#2 ?
Comment 14 Dan Lavu 2015-09-10 08:16:58 UTC 
Created attachment 1072059 [details]
sssd_logs_with_dyndns_update_true
Comment 15 Petr Spacek 2015-09-10 09:25:34 UTC 
Hello. According the last log you do not have configured IPv6 reverse zone in AD. Quick look to AD DNS configuration confirms that - I can see only IPv4 zone in there.
Comment 16 Lukas Slebodnik 2015-09-10 10:02:41 UTC 
(In reply to Petr Spacek from comment #15)
> Hello. According the last log you do not have configured IPv6 reverse zone
> in AD. Quick look to AD DNS configuration confirms that - I can see only
> IPv4 zone in there.

That's wrong approach. Many users could have configured just a IPv4 reverse zone.
Because they do not care about IPv6 on server side. But clients can have IPv6 addresses which new sssd will try to use in nsupdate.

It worked before an update and does not work aftert an upgrade. That's really bad user experience and moreover customers can notice it after a long time. The right approach will be to update just parts which can be updated (IPv4 in this case)
Comment 19 Petr Spacek 2015-09-10 12:10:31 UTC 
Okay then, in that case we have to fix a bug in nsupdate.

nsupdate apparently exists on GSSAPI failure when called with option -g and does not process other command blocks (separated by 'send' command).

This is different than behavior for other errors where nsupdate just skips the block which failed and continues with the next block of commands.
Comment 20 Petr Spacek 2015-09-10 12:14:09 UTC 
Dan, the bug is in nsupdate. Please be so kind and respect that.
Comment 22 Dan Lavu 2015-09-10 12:18:42 UTC 
Petr, 

Yes, sorry people wanted me to add the keywords.
Comment 26 Petr Spacek 2015-09-10 12:58:10 UTC 
Reproducer:

Store this in a file called "upd":

update add nsupdate.test.redhat.com 666 IN A 192.0.2.1
send
update add nsupdate.test.redhat.com 666 IN TXT "HELLo!"
send

And compare output from following commands:
$ nsupdate /tmp/upd 
update failed: REFUSED
update failed: REFUSED

$ nsupdate -g /tmp/upd 
tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor code may provide more information, Minor = Server DNS/xxx not found in Kerberos database.

You can see that first run without GSSAPI tried both command blocks but the second run with GSSAPI failed on first command block and did not continue.
Comment 39 Jakub Hrozek 2015-09-22 12:56:30 UTC 
* master: eeac17ebbe38f16deaa8599231cccfc97aaac85c
Comment 41 Dan Lavu 2015-09-23 01:55:12 UTC 
Verified, on sssd-client-1.13.0-33.el7.x86_64 , against automated test suite.
Comment 43 Jakub Hrozek 2015-09-24 13:42:17 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2783
Comment 44 errata-xmlrpc 2015-11-19 11:40:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2355.html
Note You need to log in before you can comment on or make changes to this bug.