Description of problem:
Firefox failed for negotiate authentication following the step,
Version-Release number of selected component (if applicable):
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
Still need to enter the password.
No need to enter the password to login.
Created attachment 416032 [details]
$ export NSPR_LOG_MODULES=negotiateauth:5
$ export NSPR_LOG_FILE=/tmp/moz.log
Created attachment 416034 [details]
Just to be sure, it is not misconfiguration of the server. If you add
to the libdefaults section of /etc/krb5.conf, can you still reproduce the issue?
(In reply to comment #5)
> Just to be sure, it is not misconfiguration of the server. If you add
> to the libdefaults section of /etc/krb5.conf, can you still reproduce the
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?
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?
> 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?
> 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.
(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.
(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.
(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
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
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.
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
- which versions of Thunderbird and Firefox are you using?
- do you connect from outside the corporate network and use VPN?
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.
(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.
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.
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.
re c17: I am on the internal LAN.
The problem for Thunderbird is Zimbra specific, please see below.
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
If I have understood correctly this is not an nss bug. To what component should this bug be reassigned?
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.
*** This bug has been marked as a duplicate of bug 576909 ***