Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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.
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 6Alexander Bokovoy
2015-06-07 20:07:22 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.
(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.
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
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
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.
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.
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.
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