Java GSS/Kerberos issue - Autheticating server
Douglas E. Engert
deengert at anl.gov
Wed Nov 30 17:39:59 EST 2005
Laurence Brockman wrote:
> On 11/30/05, Douglas E. Engert <deengert at 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 at bar.foo.com"
which when handled by the Kerberos would turn in into principal
"nfs/bar.foo.com at 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 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
>>>>
>>>
>>>
>>--
>>
>>Douglas E. Engert <DEEngert at anl.gov>
>>Argonne National Laboratory
>>9700 South Cass Avenue
>>Argonne, Illinois 60439
>>(630) 252-5444
>>
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list