JGSS: Integrity check on decrypted field failed (31)

Seema Malkani Seema.Malkani at Sun.COM
Wed Nov 8 17:52:51 EST 2006 

If you getting this error on Windows, but not on Linux, it's likely a 
problem with the keys used.

When using Java GSS, the Kerberos credentials (TGT and KerberosKey) are 
acquired and stored in the JAAS subject. The keys are obtained from your 
keytab file, if you configure to use keytab file. It's not clear why you 
need to create a KerberosKey object.

Have you created a keytab file or are you using passwords ? Can you 
obtain a ticket for this SPN using kinit ? Does this work ?

The JAAS Kerberos configuration option "isInitiator" allows to 
distinguish if are want the Krb5LoginModule to be an acceptor only, in 
which case the TGT will not be acquired.

Seema

Michael B Allen wrote On 11/08/06 09:01,:

>Well I got the filter to work but I never did figured out the "Integrity
>check on decrypted field failed (31)" error.
>
>I just had to create the server credential using the typical code:
>
>  Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
>  Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
>  GSSManager manager = GSSManager.getInstance();
>  GSSName serverName = manager.createName(spn, krb5PrincipalNameType);
>  this.serverCreds = manager.createCredential(serverName,
>              GSSCredential.DEFAULT_LIFETIME,
>              krb5Mechanism,
>              GSSCredential.ACCEPT_ONLY); 
>  } catch(GSSException ge) {
>      throw new ServletException("[SpnegoFilter]", ge);
>  }
>
>The bazaar thing about this is this invokes the Krb5LoginModule and gets
>a TGT. I don't need or want a TGT. I don't want to have to supply a JAAS
>conf. I don't want to have to specify where the KDC is.
>
>The problem was the way with which I created the server credential
>before. Basically I created a KerberosKey from a password, put it into
>a Subject and ran doAsPriviledged to call the above code and return the
>GSSCredential. Then I used that credential to create a GSSContext and call
>acceptSecContext. This works with Java on Linux but with Java on Windows
>acceptSecContext yeilds this "Integrity check on decrypted field failed
>(31)" error.
>
>Seema,
>
>Do you work with the Java security group? Can you confirm or deny that
>the above KerberosKey in Subject method should work?
>
>Mike
>
>On Tue, 7 Nov 2006 23:48:03 -0500
>Michael B Allen <mba2000 at ioplex.com> wrote:
>
>  
>
>>I believe this problem must be a bug in Java for Windows.
>>
>>All of the GSS examples use the default credentials of the user running
>>the server. I do not. I created a KerberosKey from a password and acquired
>>the GSSCredential through Subject.doAsPriviledged. Again the Filter works
>>on Linux this way just fine. But apparently Windows is not satisfied when
>>acceptSecContext is called. I can only guess that the Krb5LoginModule is
>>calling into the host using SSPI routines and as a result the behavior
>>is different.
>>
>>Is there any way to tell Java on Windows not to interact with SSPI at
>>all and do everything natively?
>>
>>So, now I'm trying to go through the LoginContext with the Krb5LoginModule
>>but that's far more complicated (and should be totally unnecessary
>>considering I have a keytab) and I'm weeding through errors with jaas.conf
>>syntax, keytab files, etc.
>>
>>Somebody give me a clue please.
>>
>>Mike
>>
>>On Tue, 7 Nov 2006 17:54:50 -0500
>>Michael B Allen <mba2000 at ioplex.com> wrote:
>>
>>    
>>
>>>Hi Seema,
>>>
>>>I have narrowed things down quite a bit. If I use Firefox which uses
>>>raw kerberos tokens I still get the same error which means that this
>>>has nothing to do with SPNEGO. If I run the Filter in Jetty on Linux it
>>>works. So there's something about Tomcat / Windows / Java on Windows. On
>>>site we tried a variety of different versions of Java but the one I'm
>>>trying right now is Java 1.4.2_13.
>>>
>>>The SPNs are mapped correctly and the password in fact correct. I've been
>>>doing a lot of the SSO stuff recently and I'm pretty good at diagnosing
>>>the many problems that can occur.
>>>
>>>I have compared tickets field by field using a packet sniffer (although
>>>I have not resorted to decrypting the encrypted fields yet).
>>>
>>>Do you happen to know if this particular exception is caused by a
>>>problem with the authenticator or decrypting the ticket in general?
>>>
>>>My next step will be to use Configuration.setConfiguration() to explore
>>>the effect of Krb5LoginModule options.
>>>
>>>Can you recommend futher action?
>>>
>>>Thanks,
>>>Mike
>>>
>>>On Tue, 07 Nov 2006 12:16:22 -0800
>>>Seema Malkani <Seema.Malkani at Sun.COM> wrote:
>>>
>>>      
>>>
>>>>What version of JDK are you using ? Sun's implementation of Java GSS 
>>>>includes support for SPNEGO starting from Java SE 6.
>>>>
>>>>Has the SPN been setup correctly ?
>>>>
>>>>Seema
>>>>
>>>>Michael B Allen wrote On 11/06/06 11:26,:
>>>>
>>>>        
>>>>
>>>>>I wrote an SPNEGO Java Servlet Filter that decodes the SPNEGO token,
>>>>>plucks out the krb5 mechToken and passes it to acceptSecContext. Works
>>>>>great on Linux/Jetty. Tomcat on Windows gives me the following exception.
>>>>>Basically it looks like it's failing to decrypt the ticket as if the
>>>>>password was wrong (but it's not). The service account is set for DES
>>>>>only. For the service credential, I manually create a KerberosKey with a
>>>>>plaintext password and enctype of "DES".
>>>>>
>>>>>Before I start doing byte for byte checking can anyone recommend potential
>>>>>reasons for this error?
>>>>>
>>>>>GSSException: Failure unspecified at GSS-API level (Mechanism level:
>>>>>Integrity check on decrypted field failed (31))
>>>>>	sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:734)
>>>>>	sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:300)
>>>>>	sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:246)
>>>>>________________________________________________
>>>>>Kerberos mailing list           Kerberos at mit.edu
>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>> 
>>>>>
>>>>>          
>>>>>
>>>-- 
>>>Michael B Allen
>>>PHP Active Directory SSO
>>>http://www.ioplex.com/
>>>________________________________________________
>>>Kerberos mailing list           Kerberos at mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>      
>>>
>>-- 
>>Michael B Allen
>>PHP Active Directory SSO
>>http://www.ioplex.com/
>>________________________________________________
>>Kerberos mailing list           Kerberos at mit.edu
>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>    
>>
>
>
>  
>

More information about the Kerberos mailing list