Java GSS/Kerberos issue - Autheticating server

[Laurence Brockman]

I can authenticate as that particular principal in the client portion of the
code that I have written using exactly the same case, etc.

I have a server and a client portion of code that pass GSS-wrapped kerberos
tokens through a SOAP connection and the server is unable to authenticate to
the KDC using any credentials (Same error) and the client can authenticate
using any credentials.

Both use the same code:

LoginContext("confName", new PasswordCallbackClass(....,....));
lc.login();

Thc lc.login() on the server portion is failing. The server is runnning on
my Windows XP devel box and is running as a Tomcat servlet. Any known issues
with this type of setup?

Thanks all the help!

Laurence


On 11/30/05, Douglas E. Engert <deengert at anl.gov> wrote:
>
>
>
> Laurence wrote:
>
> > Hey guys, hopefully someone can help me out here.
> >
> > I am having a problem with authenticating a user to a KDC (I believe
> > the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
> > through GSS.
> >
> > Here is the background:
> >
> > I have two processes running on one machine (Client and Server).
> >
> > 1. Client authenticates to kerberos server and logs in, uses the GSS
> > libraries to create a service ticket for destination server
> > (Authenticates with principal test/admin at realm.com).
> > 2. Server receives request from client (Through soap transcation).
> > Generates a login context and tries to authenticate against the
> > kerberos server using test2/admin at realm.com. Server is returned an
> > error from the kerberos server (Integrity check on decrypted field
> > failed (31) - PREAUTH_FAILED).
>
> There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
> It has to do with Jave assuming it knows the "salt" to use when generating
> the key from the password. key = fun(passwrod,salt); The salt is based on
> user and realm. Jave assumes that the these have not changed since the
> password was last changed. Windows is also case insensitive but does
> preserve the case of the salt when changing the password.
>
> So if you have moved an AD account from one domain to another or changed
> the acount name (even the case) and not changed the password  you could
> have problems.
>
> So make sure the case of the principal and the principal is the same
> as when the password for the acount was last changed.
>
>
> >
> > If I configured the client to use the same username/password I can
> > authenticate on the client, but no matter what I put in the server it
> > fails.
> >
> > I don't know the kerberos protocol well enough to know if I can even do
> > this (Having the server contact the KDC after a service ticket has been
> > issued to the client to authenticate). Is that why I'm getting what
> > I've read indicates a password error?
> >
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
> Douglas E. Engert  <DEEngert at anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois  60439
> (630) 252-5444
>