Java GSS/Kerberos issue - Autheticating server
Douglas E. Engert
deengert at anl.gov
Fri Dec 2 10:28:15 EST 2005
I think your problem is in the use of the createName.
Normally a services uses a Kerbeors principal of <service>/<host>@<realm>
You are trying to use a user principal another/admin at BWOO.COM
The use of the @ when calling the createName is not the same
as used in a Kerberos principal. (GSS is generic, and can handle
mechanisum names that are not Kerberos.) As far as I know, there is no
way to pass in the realm of the user or client to GSS at this time.
The IETF Kitten group doies a a proposal on how to do this
See:
http://www.ietf.org/html.charters/kitten-charter.html
and
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-01.txt
I beleieve the @ is treated special by createName only when called with
the GSSName.NT_HOSTBASED_SERVICE. In this case is seperates the service
from the host.
See:
http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/GSSName.html
If you call it with GSSName.NT_USER_NAME and it looks like it treated
the @ as part of the name. Note the " Got Name: another at admin" below.
So if you want to use GSSName.NT_USER_NAME you may want to try
"another/admin"
But you should also look at a <service> at <host> based approach
which is much more standard.
Laurence Brockman wrote:
> 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
>>
>
>
--
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