Java GSS/Kerberos issue - Autheticating server
Douglas E. Engert
deengert at anl.gov
Thu Dec 1 08:12:09 EST 2005
Laurence Brockman wrote:
> Tried that already too and received:
>
> GSSException: GSSException: No valid credentials provided (Mechanism level:
> Failed to find any Kerberos Key)
Then you have to get the key into the keytab. This is the way a server works,
It does not try and get a ticket.
Figure 2 provides a sample login configuration entry for a server
application. With this configuration, the secret key from the keytab
is used to authenticate the principal "nfs/bar.foo.com" and both the TGT
obtained from the Kerberos KDC and the secret key are stored in the Subject's
private credentials set. The stored key may be used later to validate a service
ticket sent by a client (See the section on Java GSS-API.)
SampleServer {
com.sun.security.auth.module.Krb5LoginModule
required useKeyTab=true storeKey=true principal="nfs/bar.foo.com"
};
There should be an option above to set the file name. If not, it will use the
default which is owned by root, and something like /etc/krb5.keytab or
/etc/krb5/krb5.keytab. (If you server is not run as root, then it should have its
own keytab.) (If the KDC is a windows AD, then the Microsoft ktpass can be used
to create the key, and a keytab, that can be copied to your server.)
Also note well that the <serevice>@<host> is used GSS, and is changed
to a principal <service>/<host>@<realm>
GSSName serverName = manager.createName("nfs at bar.foo.com",
GSSName.NT_HOSTBASED_SERVICE);
The Kerberos V5 mechanism would map this name to the Kerberos specific
form nfs/bar.foo.com at FOO.COM where FOO.COM is the realm of the principal.
This principal represents the service nfs running on the host machine bar.foo.com.
>
> If I don't setup the Kerberos stuff before calling that GSSCredentials I get
> that error (See code below).
>
> GSSManager manager = GSSManager.getInstance();
> Oid kerberos = new Oid("1.2.840.113554.1.2.2");
> GSSName serverGSSName = manager.createName(this.serverName, null);
> GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
> GSSCredential.INDEFINITE_LIFETIME,
> kerberos, GSSCredential.ACCEPT_ONLY);
> this.serverGSSContext = manager.createContext(serverGSSCreds);
>
> this.serverName = "another/admin" (The principal that I want to authenticate
> as).
No. See the above about the gss name to principal mapping. Its not the admin.
You need to ge the keytab.
>
> Thanks for all the help!
>
> Laurence
>
> On 11/30/05, Douglas E. Engert <deengert at anl.gov> wrote:
>
>>
>>
>>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
>>
>
>
--
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