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 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.
My bad, the SSSD bug is actually for RHEL 7.1.
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.
Simo, please advise on GSSAPI use.
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.
Tomas, let me know if you need to setup testing environment - I can certainly help you with that!
(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
Created attachment 1041058 [details] patch sent to upstream 1/2
Created attachment 1041059 [details] patch sent to upstream 2/2
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.
Would it make sense to use "realm" option as an override to GSSAPI logic? I'm not sure if it is worth.
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 1043574 [details] Patch for RHEL-7 version
We agreed with Tomas that behavior described in comment #15 sounds reasonable.
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