|Summary:||Unspecified GSS failure|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Qian Cai <caiqian>|
|Component:||nss||Assignee:||Elio Maldonado Batiz <emaldona>|
|Status:||CLOSED DUPLICATE||QA Contact:||BaseOS QE Security Team <qe-baseos-security>|
|Version:||6.0||CC:||kengert, mkhusid, nalin, rrelyea|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-10-19 21:03:00 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Qian Cai 2010-05-24 06:21:53 UTC
Description of problem: Firefox failed for negotiate authentication following the step, http://people.redhat.com/mikeb/negotiate/ Version-Release number of selected component (if applicable): firefox-3.6.4-3.el6 RHEL6.0-20100522.n.0 nightly How reproducible: always Steps to Reproduce: 1. setup krb.conf -> kinit qcai 2. setup the firefox following the guide above with either .redhat.com or redhat.com as the string values; restart firefox. 3. open kerberos enabled sites like wiki.test.redhat.com Actual results: Still need to enter the password. Expected results: No need to enter the password to login.
Comment 1 Qian Cai 2010-05-24 06:23:10 UTC
Created attachment 416032 [details] debug output $ export NSPR_LOG_MODULES=negotiateauth:5 $ export NSPR_LOG_FILE=/tmp/moz.log
Comment 5 Matěj Cepl 2010-05-26 13:52:40 UTC
Just to be sure, it is not misconfiguration of the server. If you add allow_weak_crypto=1 to the libdefaults section of /etc/krb5.conf, can you still reproduce the issue? Thank you
Comment 6 Qian Cai 2010-05-26 14:16:30 UTC
(In reply to comment #5) > Just to be sure, it is not misconfiguration of the server. If you add > > allow_weak_crypto=1 > > to the libdefaults section of /etc/krb5.conf, can you still reproduce the > issue? No.
Comment 8 Bob Relyea 2010-06-14 18:42:37 UTC
Why is this assigned to NSS? GSS currently does not involve NSS. It looks like krb5 is not authentication. 1. Is the password prompt for softoken? If so, do you have FIPS turned on in the browser?
Comment 9 Kai Engert (:kaie) (inactive account) 2010-06-15 10:24:54 UTC
I can not reproduce this bug. It works perfectly fine for me. If I understand correctly, in comment 6 CAI Qian said, the bug is also fixed for him, if he allows weak crypto. CAI Qian, is it fixed for you? Mike Khusid, if you can still reproduce the problem, please send me your extended logs. Against which site are you trying to authenticate, using Thunderbird? Using Firefox and wiki.test.redhat.com, yes, I had the problem with "weak_crypto", too. In fact, when I tried to run "kinit", I received an error message, which complained about missing crypto support in kdc. Adding the tweak from comment 5 fixed that for me. After I configured krb5.conf for the redhat.com domain, allowed weak crypto, rebooted, ran "kinit kengert", klist showed a ticket. Then I went to "wiki.test.redhat.com". I clicked on "login" in the upper left corner. I did NOT see a prompt for a password. After a few seconds, the page reloaded, and the upper left corner showed my user name, confirming that login worked. For my tests I used the yesterday's snapshot, I did a full "yum update" before testing. In my opinion, this is NOTABUG. do you agree?
Comment 10 Qian Cai 2010-06-18 02:43:55 UTC
> If I understand correctly, in comment 6 CAI Qian said, the bug is also fixed > for him, if he allows weak crypto. CAI Qian, is it fixed for you? Yes.
Comment 11 Qian Cai 2010-06-18 02:46:05 UTC
> In my opinion, this is NOTABUG. do you agree? Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while RHEL5 did not need such.
Comment 12 Kai Engert (:kaie) (inactive account) 2010-06-18 14:00:06 UTC
(In reply to comment #11) > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > RHEL5 did not need such. Matej, did RHEL 6 change the default to disallow weak crypto? CAI Qian, I expect Matej will say "yes", it's a common thing to disable older weaker algorithms by default, for security reasons. For example, there was a time when Firefox disallowed the use of older SSL v2. I'm closing this as NOTABUG, because everything works after correct configuration.
Comment 14 Matěj Cepl 2010-06-18 17:20:51 UTC
(In reply to comment #12) > (In reply to comment #11) > > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > > RHEL5 did not need such. > > Matej, did RHEL 6 change the default to disallow weak crypto? Nothing has changed in /etc/krb5.conf, but I get ticket now from RH server even setting allow_weak_crypto value manually. So probably compilation defaults has changed.
Comment 15 Matěj Cepl 2010-06-19 20:28:32 UTC
(In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > Yes if use the allow_weak_crypto=1 to workaround is expected in RHEL6 while > > > RHEL5 did not need such. > > > > Matej, did RHEL 6 change the default to disallow weak crypto? > > Nothing has changed in /etc/krb5.conf, but I get ticket now from RH server even > setting allow_weak_crypto value manually. So probably compilation defaults has > changed. Actually it is not, my testing was insufficient. I am still not able to login to mail.corp.redhat.com with the ticket without allow_weak_crytpo= true and krb5-libs-1.8.2-1.el6.x86_64
Comment 16 Mike Khusid 2010-06-21 21:17:43 UTC
Created attachment 425755 [details] Unable to log in mail.corp.redhat.com without allow_weak_crypto Notice difference in behaviour between Firefox and Thunderbird with allow_weak_crypto on and off. With allow_weak_crypto off, Firefox can obtain ticket, but Thunderbird cannot.
Comment 17 Kai Engert (:kaie) (inactive account) 2010-07-13 22:19:27 UTC
I'm surprised that Thunderbird and Firefox behave differently. If wonder if this is somehow related to https://bugzilla.mozilla.org/show_bug.cgi?id=494969, and Thunderbird not yet having the patch. I guess you're using Thunderbird 3.1.x and Firefox 3.6.x, which both are based on mozilla-1.9.2. Mike, - which versions of Thunderbird and Firefox are you using? - do you connect from outside the corporate network and use VPN?
Comment 18 Kai Engert (:kaie) (inactive account) 2010-07-13 22:21:01 UTC
I'changing the release target of this bug to RHEL 6.1, because Firefox seems fixed, and we might need more time to analyze the failure. If you believe this should be a RHEL 6 blocker, please speak up.
Comment 19 Kai Engert (:kaie) (inactive account) 2010-07-13 22:24:22 UTC
(In reply to comment #17) > I'm surprised that Thunderbird and Firefox behave differently. > If wonder if this is somehow related to > https://bugzilla.mozilla.org/show_bug.cgi?id=494969, and Thunderbird not yet > having the patch. I looked at sources of latest RHEL-6 snapshots of firefox and thunderbird, and both have the upstream patch, so the thunderbird issue must be a different cause.
Comment 20 Kai Engert (:kaie) (inactive account) 2010-07-13 22:31:22 UTC
Who could work on the release note as suggested by Matej? If I understand correctly - Matej is still having problems with Firefox (comment 15) - Firefox works fine for Mike, but Mike has problems with Thunderbird connecting to mail.corp.redhat.com but allowing weak_crypto fixes all problems. We should change the component of this bug. It's not NSS, because the kerberos handshake is implemented outside of NSS.
Comment 21 Mike Khusid 2010-07-14 14:29:53 UTC
kaie, yes, I can still reproduce the same behavior with thunderbird-3.0.5 (version in Beta 2) and thunderbird-3.1-1.el6.x86_64.
Comment 22 Mike Khusid 2010-07-14 14:30:50 UTC
re c17: I am on the internal LAN.
Comment 23 Mike Khusid 2010-07-14 16:47:18 UTC
The problem for Thunderbird is Zimbra specific, please see below. ================================================================= From: email@example.com The short version is that some of the services we have which use Kerberos were set up before we turned on support for newer and stronger ciphers like AES (actually, before AES was available), so they only have keys for use with "weak" ciphers (DES, triple-DES with no checksum). And starting with krb5 1.8, your client will default to no longer claiming to support any of that set of ciphers, so authentication doesn't work to the specific services which don't have keys for the newer ciphers assigned to them already. The fix is to rekey the affected services with keys for both the older types and the newer types, which is something the administrator of the service has to do. This was already done with the ticket-granting service, so you can kinit, provided you yourself have changed your password (and by doing that, reset your keys) since the newer cipher types were enabled. IS is working on getting the rest of the services they administer sorted out, but it turns out that some of the applications we use don't make it that simple, so Zimbra for example hasn't been rekeyed yet. As a workaround, you can configure your client to admit that it still knows how to use the older cipher types, but of course that's just there to ease the transition, and isn't meant to be used for the long-term. See also https://bugzilla.redhat.com/show_bug.cgi?id=556115 and https://bugzilla.redhat.com/show_bug.cgi?id=576909 if you're looking for more details. HTH, Nalin
Comment 25 Elio Maldonado Batiz 2010-10-19 16:47:52 UTC
If I have understood correctly this is not an nss bug. To what component should this bug be reassigned?
Comment 26 Nalin Dahyabhai 2010-10-19 20:57:45 UTC
Looks like it's a duplicate of bug #576909. At this time, anyone who still gets a "KDC has no support for encryption type" from kinit when "allow_weak_crypto" is disabled needs to run kpasswd to set new keys for their client entry in the realm database.
Comment 27 Elio Maldonado Batiz 2010-10-19 21:03:00 UTC
*** This bug has been marked as a duplicate of bug 576909 ***