Java GSS/Kerberos issue - Autheticating server
Laurence Brockman
daceilo at gmail.com
Thu Dec 1 17:57:16 EST 2005
If I do not try and use the lc.login() method and instead try to pull from
the /etc/krb5.keytab file then I get the below error:
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Setting Realm/KDC/Config to
BWOO.COM/10.0.78.20//tmp/jaas.conf
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - In the run() method.
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.realm:
BWOO.COM
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.kdc:
10.0.78.20
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor -
java.security.auth.login.config: /tmp/jaas.conf
10988 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor -
javax.security.auth.useSubjectCredsOnly: false
10991 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Got instance:
sun.security.jgss.GSSManagerImpl at 15d616e
10991 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Got kerberos:
1.2.840.113554.1.2.2
10991 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Going to get a Name for
another at admin : 1.2.840.113554.1.2.1.1
10994 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Got Name: another at admin
11004 [http-8080-Processor25] ERROR
org.apache.ws.security.kerberos.GSSAuthorizor - GSSException: GSSException:
No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT
credentials failed!)
[root at localhost laurence]# more /tmp/jaas.conf
/** Login Configuration
**/
JaasServer {
com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true
storeKey=true keyTab="/etc/krb5.keytab";
};
*Code from GSSAuthorizor:*
GSSManager manager = GSSManager.getInstance();
Oid kerberos = new Oid("1.2.840.113554.1.2.2");
this.serverName = "another at admin";
GSSName serverGSSName = manager.createName(this.serverName,
GSSName.NT_USER_NAME);
GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
GSSCredential.INDEFINITE_LIFETIME,
kerberos, GSSCredential.ACCEPT_ONLY);
log.debug("Created credentials for the service");
[root at localhost laurence]# /usr/java/jdk1.5.0_06/bin/klist -k
FILE:/etc/krb5.keytab
Key tab: FILE:/etc/krb5.keytab, 4 entries found.
[1] Service principal: another/admin at BWOO.COM
KVNO: 2
[2] Service principal: another/admin at BWOO.COM
KVNO: 2
[3] Service principal: another/admin at BWOO.COM
KVNO: 2
[4] Service principal: another/admin at BWOO.COM
KVNO: 2
I have no idea what that error means. I have pointed it to the keytab file,
the keytab file has the Service Principal for another/admin at BWOO.COM as
indicated above and it still does not find it.
Any help would be greatly appreciated. I do not have a policy file, does
this need to be added?
Laurence
On 12/1/05, Douglas E. Engert <deengert at anl.gov> wrote:
>
>
>
> 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