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/[EMAIL PROTECTED]
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: [EMAIL PROTECTED]" 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:
[EMAIL PROTECTED]
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
[EMAIL PROTECTED] : 1.2.840.113554.1.2.1.1
10994 [http-8080-Processor25] DEBUG
org.apache.ws.security.kerberos.GSSAuthorizor - Got Name: [EMAIL PROTECTED]
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!)
[EMAIL PROTECTED] 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 = "[EMAIL PROTECTED]";
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");
[EMAIL PROTECTED] 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/[EMAIL PROTECTED]
KVNO: 2
[2] Service principal: another/[EMAIL PROTECTED]
KVNO: 2
[3] Service principal: another/[EMAIL PROTECTED]
KVNO: 2
[4] Service principal: another/[EMAIL PROTECTED]
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/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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("[EMAIL PROTECTED]",
GSSName.NT_HOSTBASED_SERVICE);
The Kerberos V5 mechanism would map this name to the Kerberos specific
form nfs/[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote:
Laurence Brockman wrote:
On 11/30/05, Douglas E. Engert <[EMAIL PROTECTED]> 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 "
[EMAIL PROTECTED]"
which when handled by the Kerberos would turn in into principal
"nfs/[EMAIL PROTECTED]"
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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]).
2. Server receives request from client (Through soap transcation).
Generates a login context and tries to authenticate against the
kerberos server using test2/[EMAIL PROTECTED] 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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
