JGSS: Integrity check on decrypted field failed (31)

Wed Nov 8 12:01:33 EST 2006

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
> 

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/