Java GSS/Kerberos issue - Autheticating server
Laurence Brockman
daceilo at gmail.com
Wed Nov 30 20:21:53 EST 2005
Tried that already too and received:
GSSException: GSSException: No valid credentials provided (Mechanism level:
Failed to find any Kerberos Key)
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).
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
>
More information about the Kerberos
mailing list