Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

Testing RedHat6/CentOS6 krb5.conf compatible enctypes - httpd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)

Fletcher Cocquyt fcocquyt at stanford.edu
Mon Sep 26 10:40:19 PDT 2011


Russ thanks for all the great info -

from my reading of your reply you recommend simply removing the

>>  default_tkt_enctypes =
>>  default_tgs_enctypes =

Lines and allowing negotiation of encryption types.

I'm testing this now and it seems to work fine for CentOS5 and CentOS6
distros (tested ssh and webauth)

Q: What's the best way to determine the enctype that ends up being
negotiated?

Thanks,

-- 
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine

Email: fcocquyt at stanford.edu
Phone: (650) 724-7485

On 9/19/11 10:27 AM, "Russ Allbery" <eagle at windlord.stanford.edu> wrote:

> Fletcher Cocquyt <fcocquyt at stanford.edu> writes:
> 
>> We are testing CentOS6 builds and found our existing krb5.conf enctypes
>> have been deprecated resulting in the kerberos auth for ssh failing
>> until we update the krb5.conf as follows:
> 
>>  # default_tkt_enctypes = des-cbc-crc # DES is deprecated in RHEL 5.6 and 6.
>>  # default_tgs_enctypes = des-cbc-crc # DES is deprecated in RHEL 5.6 and 6.
>>  default_tkt_enctypes = rc4-hmac
>>  default_tgs_enctypes = rc4-hmac
>>  permitted_enctypes = rc4-hmac
> 
> You should never restrict to only rc4-hmac as an enctype at Stanford
> unless you're interacting specifically with Windows XP systems under very,
> very specific circumstances.  We introduced 256-bit AES and 3DES (both of
> which are stronger than RC4) prior to introducing RC4, so any system that
> has RC4 keys also has AES and 3DES keys except for some Windows
> cross-realm situations.
> 
> In general, you never want to set those krb5.conf configuration options at
> all.  If you don't set them, the Kerberos library will negotiate
> appropriate encryption types.  (Be aware that if you use the Kerberos
> ticket caches directly from Java, you'll need to have the US encryption
> module installed, but that's fairly easy to do and worthwhile anyway.)
> 
>> Now the question is, are these new enctypes perfectly backward
>> compatible?
> 
> It's a completely different enctype with no relationship to DES, so in
> that sense it's not backward compatible at all.  But my guess is that what
> you're asking is whether every Stanford service that had DES keys has RC4
> keys.  The answer is no: RC4 keys are a relatively new addition only for
> Windows XP support.  If you allow 3DES and 256-bit AES, you'll be on much
> firmer ground, but there are still some services (although no ITS services
> apart from AFS, which is special) that are DES-only.
> 
>> We¹re testing the new enctypes on CentOS/RedHat 5 and so far the only
>> error turning up is on our webservers:
> 
>> httpd: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
>> information (Credential cache is empty)
> 
> This implies that you can't get Kerberos tickets, which probably means
> that your local Kerberos keytab doesn't have RC4 keys, which is not
> surprising if it's older than a couple of years.  If you just remove those
> krb5.conf settings, I suspect WebAuth will start working fine.
> 
> Alternately, you can add:
> 
>     allow_weak_crypto = true
> 
> to the [libdefaults] section of krb5.conf, which will enable DES keys
> again, although in the long run we do want to phase out use of DES.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/webauth-info/attachments/20110926/a40f08c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 9320 bytes
Desc: not available
URL: <http://mailman.stanford.edu/pipermail/webauth-info/attachments/20110926/a40f08c0/attachment.jpg>


More information about the webauth-info mailing list