Bug 595221 - Unspecified GSS failure
Unspecified GSS failure
Status: CLOSED DUPLICATE of bug 576909
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss (Show other bugs)
6.0
All Linux
high Severity high
: rc
: 6.1
Assigned To: Elio Maldonado Batiz
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-24 02:21 EDT by CAI Qian
Modified: 2010-10-19 17:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-19 17:03:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
debug output (1.92 KB, text/plain)
2010-05-24 02:23 EDT, CAI Qian
no flags Details
krb5.conf (677 bytes, text/plain)
2010-05-24 02:24 EDT, CAI Qian
no flags Details
Unable to log in mail.corp.redhat.com without allow_weak_crypto (4.04 KB, text/plain)
2010-06-21 17:17 EDT, Mike Khusid
no flags Details

  None (edit)
Description CAI Qian 2010-05-24 02:21:53 EDT
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 CAI Qian 2010-05-24 02:23:10 EDT
Created attachment 416032 [details]
debug output

$ export NSPR_LOG_MODULES=negotiateauth:5
$ export NSPR_LOG_FILE=/tmp/moz.log
Comment 2 CAI Qian 2010-05-24 02:24:50 EDT
Created attachment 416034 [details]
krb5.conf
Comment 5 Matěj Cepl 2010-05-26 09:52:40 EDT
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 CAI Qian 2010-05-26 10:16:30 EDT
(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 14:42:37 EDT
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) 2010-06-15 06:24:54 EDT
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 CAI Qian 2010-06-17 22:43:55 EDT
> 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 CAI Qian 2010-06-17 22:46:05 EDT
> 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) 2010-06-18 10:00:06 EDT
(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 13:20:51 EDT
(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 16:28:32 EDT
(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 17:17:43 EDT
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) 2010-07-13 18:19:27 EDT
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) 2010-07-13 18:21:01 EDT
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) 2010-07-13 18:24:22 EDT
(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) 2010-07-13 18:31:22 EDT
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 10:29:53 EDT
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 10:30:50 EDT
re c17: I am on the internal LAN.
Comment 23 Mike Khusid 2010-07-14 12:47:18 EDT
The problem for Thunderbird is Zimbra specific, please see below.
=================================================================
From: nalin@redhat.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 12:47:52 EDT
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 16:57:45 EDT
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 17:03:00 EDT

*** This bug has been marked as a duplicate of bug 576909 ***

Note You need to log in before you can comment on or make changes to this bug.