[25042] in Kerberos
Re: Java GSS/Kerberos issue - Autheticating server
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Wed Nov 30 18:06:36 2005
Message-ID: <438E2A3F.5090901@anl.gov>
Date: Wed, 30 Nov 2005 16:39:59 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Laurence Brockman <daceilo@gmail.com>
In-Reply-To: <320a0b5e0511301352m2cf59242sdea7f2c7f45fcbd2@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Laurence Brockman wrote:
> On 11/30/05, Douglas E. Engert <deengert@anl.gov> wrote:
>
>>
>>
>>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen the
>>clint and server. And the server accepts the authentication.
>
>
>
> Prior to the server even looking at the packet from the client, it needs to
> contact the kerberos server to get it's own credentials (GSS Uses these
> underlying credentials when communicating with the client).
No.
See:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html
Credential acquisition on the server side occurs as follows:
GSSCredential serverCreds =
manager.createCredential(serverName,
GSSCredential.INDEFINITE_LIFETIME,
desiredMechs,
GSSCredential.ACCEPT_ONLY);
The behavior is similar to the client case, except that the kind of credential
requested is one that can accept incoming requests (i.e., a server credential).
Moreover, servers are typically long lived and like to request a longer lifetime
for the credentials such as the INDEFINITE_LIFETIME shown here. The Kerberos V5
mechanism element stored is an instance of a subclass of
javax.security.auth.kerberos.KerberosKey containing the secret key of the server.
This step can be an expensive one, and applications generally acquire a reference
at initialization time to all the credentials they expect to use during their
lifetime.
There is an example of the server side later on, with gs name of "nfs@bar.foo.com"
which when handled by the Kerberos would turn in into principal
"nfs/bar.foo.com@DEFAULT.REALM"
>
>
>>and the server is unable to authenticate to
>>
>>>the KDC using any credentials (Same error) and the client can
>>
>>authenticate
>>
>>Normally the server does not talk to the KDC at all. SO what is it really
>>trying to do?
>
>
>
> I'm refering to the kerberos server that granted the service ticket to the
> client. My server will need to talk to that server to get it's shared key at
> some point otherwise it will not be able to verify the ticket the client is
> sending.
>
> But the GSSAPI Delegation feature can be used be the client to delegate
>
>>a credential to the server so the server can act as the client. (The
>>client
>>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
>>for example where the user is logging in as the user.
>>
>>
>>>using any credentials.
>>>
>>>Both use the same code:
>>>
>>>LoginContext("confName", new PasswordCallbackClass(....,....));
>>
>>So where is geting the password? Does the server think the principal
>>is that of the user, as the gssapi delegated a TGT to the server?
>
>
>
> The principal is manually submitted and the password is returned from the
> callback class (The call back class is instiated in such a way that it has
> the password stored on the object and when the method responsible for
> returning the password is called on the callback class it returns that
> password (1234567890 in our case). This is the same process that is used on
> my client and it works no problem (Using the same commands, same principals
> and same variables).
>
>
>>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?
>>>
>>
>>You can run Ethereal on the box, and watch the network traffic. Ethereal
>>can format krb5 packets. Very helpfull is cases like this.
>
>
>
> Yup, this will be the next step.
>
> Don't know.
>
>>>Thanks all the help!
>>>
>>>Laurence
>>>
>>>
>>>On 11/30/05, Douglas E. Engert <deengert@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@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@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@mit.edu
>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>>
>>>>>
>>>>
>>>>--
>>>>
>>>>Douglas E. Engert <DEEngert@anl.gov>
>>>>Argonne National Laboratory
>>>>9700 South Cass Avenue
>>>>Argonne, Illinois 60439
>>>>(630) 252-5444
>>>>
>>>
>>>
>>--
>>
>>Douglas E. Engert <DEEngert@anl.gov>
>>Argonne National Laboratory
>>9700 South Cass Avenue
>>Argonne, Illinois 60439
>>(630) 252-5444
>>
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
