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 1214827 - nsupdate realm auto-detection is broken
Summary: nsupdate realm auto-detection is broken
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomáš Hozza
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1206607
TreeView+ depends on / blocked
 
Reported: 2015-04-23 15:32 UTC by Petr Spacek
Modified: 2015-11-19 08:06 UTC (History)
5 users (show)

Fixed In Version: bind-9.9.4-25.el7
Doc Type: Bug Fix
Doc Text:
Cause: nsupdate was extracting REALM from the local kerberos ticket, if the REALM was not specified explicitly as an option. Consequence: In cross-realm trust scenarios, the REALM extracted from local kerberos ticket was not right, if the update was supposed to be sent to nameserver from another REALM. Fix: nsupdate code was updated to leave the REALM detection up to GSSAPI in case the REALM is not specified explicitly using an option. Result: As a result, nsupdate now correctly determines the REALM in cross-realm trust scenarios. Users are still able to specify the REALM using an option and override the detected REALM.
Clone Of:
Environment:
Last Closed: 2015-11-19 08:06:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
patch sent to upstream 1/2 (1.53 KB, patch)
2015-06-19 18:44 UTC, Tomáš Hozza 		no flags Details | Diff
patch sent to upstream 2/2 (5.98 KB, patch)
2015-06-19 18:45 UTC, Tomáš Hozza 		no flags Details | Diff
reworked patch (15.31 KB, patch)
2015-06-26 11:39 UTC, Tomáš Hozza 		no flags Details | Diff
Patch for RHEL-7 version (15.78 KB, patch)
2015-06-26 15:10 UTC, Tomáš Hozza 		no flags Details | Diff
Patch for RHEL-7 version (15.51 KB, patch)
2015-06-29 09:17 UTC, Tomáš Hozza 		no flags Details | Diff
Show Obsolete (3) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2222 0 normal SHIPPED_LIVE bind bug fix update 2015-11-19 08:39:03 UTC

Description Petr Spacek 2015-04-23 15:32:53 UTC 
Description of problem:
nsupdate -g does not work without explicit "realm" specification if Kerberos cross-realm trust is used because nsupdate lacks proper realm auto-detection.

This breaks nsupdate in IPA-AD trusts.

How reproducible:
100 %

Steps to Reproduce:
0. $ kinit principal@REALM1
1. $ nsupdate -g
2. > update add test.domain.belonging.to.realm2.test 333 IN TXT "test"
3. > send

Actual results:
Update fails because wrong realm was selected and TSIG negotiation failed.

Expected results:
Update succeeds.

Additional info:
It uses custom function get_ticket_realm() instead of GSS-API library. This custom method does not produce meaningful results for cross-realm scenarios.

Let me know if you need any assistance with this, we can hack this together.
Comment 2 Petr Spacek 2015-04-23 16:00:14 UTC 
I just realized that this likely breaks nsupdate in environment with multiple AD realms, i.e. it affects SSSD which is directly connected to AD too.
Comment 3 Petr Spacek 2015-04-23 19:05:48 UTC 
My bad, the SSSD bug is actually for RHEL 7.1.
Comment 5 Tomáš Hozza 2015-05-26 15:30:22 UTC 
I did some investigation.

The realm detection is done by the get_ticket_realm() from the default principal of credential cache. The "@REALM1" part is stripped of from the principal name and used as the realm.

The "service name" passed to dns_tkey_buildgssquery() is constructed as "DNS/<hostname_of_master_server_for_the_domain>@<realm_extracted_from_ticket>".

The same "service name" is passed to dst_gssapi_initctx() for gssapi context initialization. Inside it, the gss_import_name() is called with GSS_C_NO_OID and the "service name" as principal for conversion to the internal GSSAPI representation of the name. The name is then passed as the name of target to the gss_init_sec_context().

So far I was not able to find any GSSAPI library function to determine the REALM more reliably, than done currently in the code. From your description I assume, that the error is only in the way the REALM is determined, but the rest is OK.

Please provide some clues on the proper GSSAPI library call to use for the proper REALM detection.

Setting Patch, Design Devel Cond NAKs until it is clear how this can be improved.

Thank you in advance.
Comment 6 Alexander Bokovoy 2015-06-07 20:07:22 UTC 
Simo, please advise on GSSAPI use.
Comment 7 Simo Sorce 2015-06-08 12:50:25 UTC 
Is there any reason why you need to determine the realm before calling GSSAPI ?

Normally you should leave REALM determination to GSSAPI itself, by passing in service@fqdn as the name and GSS_C_NT_HOSTBASED_SERVICE as the name type.

Unless you need the realm for some specific reason, I'd change the code to let GSSAPI take care of it, as GSSAPI has the means to find the correct realm for the target name.
Comment 8 Petr Spacek 2015-06-09 09:14:26 UTC 
Tomas, let me know if you need to setup testing environment - I can certainly help you with that!
Comment 9 Tomáš Hozza 2015-06-09 09:58:27 UTC 
(In reply to Petr Spacek from comment #8)
> Tomas, let me know if you need to setup testing environment - I can
> certainly help you with that!

Please do so Petr. It would really help me.

Thank you in advance.
Comment 10 Tomáš Hozza 2015-06-19 17:43:51 UTC 
Thank you Simo for the tip. I also found that RFC 4752 section 3.1 [1] states that client should use GSS_C_NT_HOSTBASED_SERCICE.

I tested a possible fix and it seems to work. I can get the same results as if I specified REALM explicitly. The "realm" option does not make sense any more IMHO, since the realm detection is not left up to the GSSAPI itself. I'll be sending patch to the upstream shortly.

[1] https://www.ietf.org/rfc/rfc4752.txt
Comment 11 Tomáš Hozza 2015-06-19 18:27:11 UTC 
In RHEL we may leave the 'realm' option and just not use it, just for the sake of backward compatibility. The documentation should be changed and maybe some warning printed that the option is not used any more.

Patches sent to upstream:
[ISC-Bugs #39840] nsupdate GSSAPI cross-realm detection does not work
Comment 12 Tomáš Hozza 2015-06-19 18:44:57 UTC 
Created attachment 1041058 [details]
patch sent to upstream 1/2
Comment 13 Tomáš Hozza 2015-06-19 18:45:17 UTC 
Created attachment 1041059 [details]
patch sent to upstream 2/2
Comment 14 Simo Sorce 2015-06-19 19:23:34 UTC 
Patches look good, I agree you should somehow process (and ignore ?) the realm opttion in RHEL, breaking that interface would be really unfriendly and it is not necessary.
Comment 15 Petr Spacek 2015-06-23 07:34:04 UTC 
Would it make sense to use "realm" option as an override to GSSAPI logic? I'm not sure if it is worth.
Comment 16 Tomáš Hozza 2015-06-26 11:39:18 UTC 
Created attachment 1043485 [details]
reworked patch

I reworked the patch for better backward compatibility. The 'realm' option is preserved. If not specified, the realm detection is left up to the GSSAPI. If specified, the "old" code is used.
Comment 17 Tomáš Hozza 2015-06-26 15:10:09 UTC 
Created attachment 1043574 [details]
Patch for RHEL-7 version
Comment 18 Petr Spacek 2015-06-26 16:39:54 UTC 
We agreed with Tomas that behavior described in comment #15 sounds reasonable.
Comment 19 Tomáš Hozza 2015-06-29 09:17:25 UTC 
Created attachment 1044267 [details]
Patch for RHEL-7 version

Previous rebased patch contained error. This is fixed now. I tested the functionality on RHEL-7 and it worked well.

Without explicit 'realm' the realm is now correctly discovered by GSSAPI. With the explicit 'realm' it overrides the detection and passed realm is used instead.

Still no response from the upstream on the patch.
Comment 27 errata-xmlrpc 2015-11-19 08:06:39 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/RHBA-2015-2222.html
Note You need to log in before you can comment on or make changes to this bug.