Michael,
If by "speak binary" you mean "parse hex dumps of ASN.1 BER" then yes.
These are both truncated GSS tokens. See below.
I don't want to convince you of anything. I was just trying to help,
but I'll stop now.
--David
Michael B Allen wrote:
> On Thu, 09 Nov 2006 10:10:56 -0500
> David
On Thu, 09 Nov 2006 10:10:56 -0500
David Shambroom <[EMAIL PROTECTED]> wrote:
> Mike,
>
> The mechToken is a Kerberos AS_REQ message, not a GSS token.
My understanding is that this statement is wholely incorrect.
Do you speak binary? I think that's the only way you're going to convince
me. The
nterSystems Corporation [EMAIL PROTECTED]
>>
>>
>>> Message: 2
>>> Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
>>> From: "Michael B Allen" <[EMAIL PROTECTED]>
>>> Subject: JGSS: Integrity check on decrypted field
Message: 2
> > Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
> > From: "Michael B Allen" <[EMAIL PROTECTED]>
> > Subject: JGSS: Integrity check on decrypted field failed (31)
> > To: kerberos@mit.edu
> > Message-ID: <[EMAIL PROTECTED]>
> > Co
CTED]>
> Subject: JGSS: Integrity check on decrypted field failed (31)
> To: kerberos@mit.edu
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain;charset=iso-8859-1
>
> I wrote an SPNEGO Java Servlet Filter that decodes the SPNEGO token,
> plucks out the krb5 mechTo
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
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
Hi Michael,
Once I had to implement SPNEGO protocol, and I think I've seen such
errors. Most probably you unwrap SPNEGO tokens in wrong way, which leads
to corrupt (or invalid) GSSAPI token.
Best regards, vadim tarassov
On Mon, 2006-11-06 at 14:26 -0500, Michael B Allen wrote:
> I wrote an SPNEG
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 j
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
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 krb
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 wro
12 matches
Mail list logo
