The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Kerberos Login Handler - FAQ

Owned by Former user (Deleted)
Last updated: Feb 23, 2012 by Rodrigo RistowVersion comment
3 min read

Troubleshooting

Problem: How to sets a default authentication mechanism for the relying party?

Solution: Check the IdPRelyingParty (defaultAuthenticationMethod) documentation.
Example:

(...)
    <DefaultRelyingParty provider="https://aai-logon.com/idp/shibboleth"
                         defaultSigningCredentialRef="IdPCredential"
                         defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
(...)

Problem:  Checksum error

Log:

Sep 6, 2010 11:44:22 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.GeneralSecurityException: Checksum failed
 at sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:406)
 at sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:91)

Solution: There are two things you can try:
1. If you are using a version of the JDK that is less than 1.5.0_07 then, update to a newer version of Java.
2. On the Active Directory accounts on your domain server, make sure you check the box "use DES encryption type" for the client and service accounts.

Problem: GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)

Log:

10:57:34.290 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:149] - GSS context created.
10:57:34.305 - ERROR [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:99] - security context (Kerberos Ticket) not accepted.
org.ietf.jgss.GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)
        at sun.security.jgss.krb5.InitialToken$OverloadedChecksum.<init>(InitialToken.java:263) ~[na:1.6.0_17]
        at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:126) ~[na:1.6.0_17]

Solution:

In windows 7, and XP with the latest security updates,  Windows now offers something called IWA extended protection. IE8 appears to take advantage of this while earlier versions of IE do not. In short, the Kerberos token being sent by the updated windows initiator contains channel binding information and the Java 6 (before minor release 6u19) Kerberos acceptor fails when trying to match this info to locally configured channel bindings and there is no way in Java 6 (before release 6u19) to tell the VM to ignore this information.

It has been fixed in Java 1.6u19: http://www.oracle.com/technetwork/java/javase/6u19-141078.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6851973

The exception that will be thrown in your logs will look like this:

    GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)

If you must use IE8 and you can't upgrade to Java 6u19, you can try the windows registry tweak listed here:

   http://support.microsoft.com/?scid=kb%3Ben-us%3B968389&x=10&y=18

The configuration that works for me( no registry tweaking) is:

CAS Server OS:  RHEL5 ( I have also tested with tomcat on windows XP as well, it works)
CAS Server Java: java version "1.6.0_18"
        Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
        Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)

Browsers:  
   IE: Version: 7.0.5730.13CO
   Firefox: Firefox/3.6  although the issue does not appear to manifest
itself on Firefox.

Source:

SPNEGO Basics

http://stackoverflow.com/questions/1785199/why-do-i-get-a-gssexception-when-using-active-directory-sso-from-microsoft-ie-to

Problem:  HTTP Error 400 - Bad Request
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Solution:
Multi-group environments potentially have an issue with Transparent Authentication when using Kerberos for the chosen authentication method because the HTTP header length size can affect Kerberos authentication. Typically, the Appliance can handle a header length size of up to 8KB.
The Appliance does not require the Privilege Attribute Certificate (PAC) information that the userAccountControl includes by default.

More information on the PAC is found at: http://support.microsoft.com/kb/832572.
For information on the useraccountcontrol bits see: http://msdn.microsoft.com/en-us/library/cc200366.aspx.

Attention: Changing the Apache "LimitRequestFieldSize" is not a good idea because:

  • This directive gives the server administrator greater control over abnormal client request behavior, which may be useful for avoiding some forms of denial-of-service attacks.
  • Your browser will potently send the same "huge" Authorization header for other servers, causing the same error.

Source: https://kc.mcafee.com/corporate/index?page=content&id=KB60332&pmv=print

Additional Resources/Troubleshooting from microsoft: http://go.microsoft.com/fwlink/?LinkId=134740