JGSS Integrity check on decrypted field failed (31)

While trying to get a java app to authenticate to a webserver using Authentication: Negotiate, (SPNEGO) I hit a hard to debug problem.

The JGSS kept returning Integrity check on decrypted field failed (31).

There are many causes to this:

1) Make sure your realm is all in uppercase.

2) If you are on Windows XP SP2 or Vista, you need to set a registry key in order to allow the TGT session key to be accessed by other applications (in this case Java).

In the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Create value:

DWORD allowtgtsessionkey = 1

I found this here:

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html

History of the Blog Name

Here is the story of why this blog is called this way, I write it mostly so that I remember in the future...

It all started when I wanted to post a comment on the forums of a sourceforge.net project (http://oval.sourceforge.net/). I needed to register and I didn't want to create yet another account for posting a single comment...

Sourceforge.net used openID and I had my google account (but it wasn't compatible with sourceforge) but I saw that blogger was supported. Blogger is integrated with Google accounts, so I already had a Blogger account!

The Blogger OpenID though is based on the blog URL so I didn't simply need a Blogger account, I needed to create an actual blog. When I tried to create the blog I tried several names (e.g. A blog about nothing, and many other variations meant for an unused blog) but all the good names were taken...

I then decided to simply name the blog for its true usage... A blog to have an Open ID!

Cheers

Edit: I forgot to mention that creating this OpenID was a great move, the same day I used my new blogger account to comment on another blog post (http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html). I'm glad I didn't just create another account on sourceforge.net with yet another password to remember and another possibility of having this password mis-handled...

WIA hung on starting

I recently had a problem where (on WinXP embedded) I needed to make a WIA device work.

As soon as we plugged the device, it appeared in Device Manager but never appeared in My Computer.

Eventually, I found out that the Windows Image Acquisition service would be stuck in status Starting... I waited a while (I was debugging other driver issues) but the service was completely hung.

I used SysInternals ProcessMonitor (on XP embedded, you need the Filter Manager component for it to work) to try to see what was happening. You don't get a lot of information, but one of the last actions is that the service tries to open "c:\Windows\Sti_trace.log" and results in Access Denied.

I changed the account for the Windows Image Aquisition service from Local Service to Local System and everything started working!

I checked the permissions and User accounts (Local Service) cannot write to the c:\Windows folder, so the service doesn't start because it can't write its debug log file...

I don't understand how come I only get this error on XP embedded though as it seems this would happen all the time. I'll keep on investigating.

I've spent a day finding this, hope it can save someone some time!