Authentication attempt failedjavax.security.auth.login.LoginException: null (68)
Max (Weijun) Wang
Weijun.Wang at sun.com
Mon Jan 4 19:17:49 EST 2010
Hi Paulo
I have really no idea how the following could happen:
>>>> KrbKdcReq send: kdc=FISHERSLDAP.USA-ED.NET UDP:88, timeout=30000,
>>>> number of retries =3, #bytes=245
>>>> KDCCommunication: kdc= FISHERSLDAP.USA-ED.NET UDP:88,
>>>> timeout=30000,Attempt =1, #bytes=245 KrbKdcReq send: #bytes
>>>> read=116
Here, the second realm name has a strange " " at its head. I've read
the source codes [1] and there's really no chance for this to happen.
The same space also appears in the error response from the KDC. The
KDC surely wouldn't issue a ticket for this realm name.
What version of JRE are you using? Does Java's kinit.exe also fail on
your system?
Thanks
Weijun
[1] http://hg.openjdk.java.net/jdk7/tl/jdk/file/1/src/share/classes/sun/security/krb5/KrbKdcReq.java
On Jan 5, 2010, at 12:42 AM, Paulo Lima wrote:
> Hi Weijun,
>
> Please see the code I am running below this email message (right
> after my name)
>
> This error is happening on Windows with simple JAVA SE. Here is
> the debugging info on it:
>
> *************************************************************
>
> C:\Temp\jaasinfo>java
> -Djava.security.auth.login.config="C:\Temp\jaasinfo\token_jaas.conf"
> -Djava.security.krb5.conf="C:\Temp\jaasinfo\krb5.conf"
> -Dsun.security.krb5.debug=true
> com.jtester.actional.training.samples.ClientSideKerberosHandler
> Kerberos username [Administrator]: jtester Kerberos password for
> jtester: foo123 Using builtin default etypes for default_tkt_enctypes
> default etypes for default_tkt_enctypes: 3 1 16.
> Using builtin default etypes for default_tkt_enctypes default etypes
> for
> default_tkt_enctypes: 3 1 16.
>>>> EType: sun.security.krb5.internal.crypto.DesCbcMd5EType
>>>> KrbAsReq calling createMessage
>>>> KrbAsReq in createMessage
>>>> KrbKdcReq send: kdc=FISHERSLDAP.USA-ED.NET UDP:88, timeout=30000,
>>>> number of retries =3, #bytes=245
>>>> KDCCommunication: kdc= FISHERSLDAP.USA-ED.NET UDP:88,
>>>> timeout=30000,Attempt =1, #bytes=245 KrbKdcReq send: #bytes
>>>> read=116
>
>>>> KrbKdcReq send: #bytes read=116
>>>> KDCRep: init() encoding tag is 126 req type is 11
>>>> KRBError:
> sTime is Tue Dec 29 15:07:24 GMT-06:00 2009 1262120844000
> suSec is 450702
> error code is 68
> error Message is null
> realm is FISHERSLDAP.USA-ED.NET
> sname is krbtgt/ FISHERSLDAP.USA-ED.NET Authentication attempt
> failedjavax.security.auth.login.LoginException: null (68)
>
> C:\Temp\jaasinfo>
>
> *************************************************************
>
> Thanks for your help,
> Paulo
>
>
> package com.plima.actional.training.samples;
>
> /*
> * Kerberos Token Generator v1 May 2008
> *
> * This class implements the Kerberos version 5 protocol. Upon
> successful
> * authentication, the Ticket Granting Ticket (TGT) is stored in the
> * Subject's private credentials set and the Kerberos principal is
> stored
> * in the Subject's principal.
> */
>
> import com.manning.samples.soasecimpl.commons.Constants;
> import com.sun.security.auth.callback.TextCallbackHandler;
> import org.apache.commons.codec.binary.Base64;
> import org.ietf.jgss.*;
>
> import javax.security.auth.Subject;
> import javax.security.auth.kerberos.KerberosPrincipal;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import java.io.UnsupportedEncodingException;
> import java.security.PrivilegedAction;
> import java.util.Set;
>
> public class ClientSideKerberosHandler {
> public ClientSideKerberosHandler () {
> }
>
> public static void main(String[] args) {
> try {
> addKerberosToken();
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> static private void addKerberosToken() throws Exception {
> Subject kerberosSubject = null;
> try {
>
> /*
> * 1. Log in (to Kerberos)
> * (Authenticating to Kerberos)
> *
> * On the Java platform, you use the Java Authentication and
> Authorization Service (JAAS)
> * for authentication to security services.
> *
> * A Java application logs into one or more security systems
> by first creating
> * a LoginContext. You supply to the LoginContext
> constructor
> * the name of the class that is doing the authentication
> and
> a CallbackHandler
> *
> * The class name is used by the JAAS to identify the login
> modules that are required
> * for the class. The JAAS allows dynamic configuration of
> login modules.
> * When the program is run, you specify a JAAS configuration
> file that
> * specifies the login modules to use.
> *
> * The CallbackHandler is used by the login modules to
> obtain
> the required
> * authentication information. The Kerberos v5 login module,
> for example,
> * requires a username and password. In the example, the
> callback handler is
> * SampleCallbackHandler, the same handler we used for the
> CRAM-MD5 callback example.
> *
> * After you have create an instance of LoginContext, you
> perform the authentication
> * by invoking LoginContext.login(). This method throws a
> subclass of LoginException
> * if the authentication fails. The exception indicates the
> cause of the failure.
> * For certain exceptions, such as FailedLoginException
> */
>
> LoginContext loginContext = new LoginContext("GssExample",
> new TextCallbackHandler());
>
> /*
> * 2. Attempt authentication
> */
>
>
> loginContext.login();
> kerberosSubject = loginContext.getSubject();
> System.out.println("INFO: Obtained TGT from Kerberos");
> } catch (LoginException le) {
> System.err.println("Authentication attempt failed" + le);
> System.exit(-1);
> }
>
> /*
> * 3. Perform JNDI work as logged in subject
> * (Assuming the Identity of the Authenticated Principal)
> *
> * The Subject argument is obtained
> * by invoking LoginContext.getSubject() on the LoginContext
> that
> was used
> * for Kerberos authentication. PrivilegedAction and
> PrivilegedExceptionAction
> * define the computation to be performed with the privileges of
> the authenticated
> * user enabled. PrivilegedAction and PrivilegedExceptionAction
> are used for
> * computations that, respectively, do and do not throw checked
> exceptions.
> * The AccessControlContext argument is used to specify a
> security context
> * to use other than that of the caller. For example, a worker
> thread might
> * use the security context of its master instead of its own.
> *
> * Below we need to define a class that implements either
> PrivilegedAction
> * or PrivilegedExceptionAction and encapsulate the JNDI calls
> within the
> * class's run() method. In our class, we defined a class called
> ServiceTicketGrabber
> * that performs the directory access calls using the JNDI.
> * The following code executes ServiceTicketGrabber's run()
> method with the
> * privileges of the authenticated Kerberos principal enabled.
> */
>
> PrivilegedAction action = new ServiceTicketGrabber();
> Subject.doAs(kerberosSubject, action);
>
>
> }
> }
>
> class ServiceTicketGrabber implements PrivilegedAction {
> public Subject kerberosSubject;
>
>
> public ServiceTicketGrabber() {
> this.kerberosSubject = kerberosSubject;
> }
>
> /*
> * 4. Performing the JNDI Task
> *
> * From within the PrivilegedAction.run() and
> PrivilegedExceptionAction.run()
> * methods, the JNDI calls are made in the same way as before. It
> is
> important to
> * make the calls in the class's run() method (not its constructor).
> * The only thing to note is that when you specify
> * the hostname in the URL in the Context.PROVIDER_URL property, be
> sure to
> * use the name that the host is known as in the Kerberos database.
> * Typically, this means using the fully qualified hostname. If you
> use a
> * name that is not in the Kerberos database, the program will fail
> with an
> * authentication error.
> *
> * The following code shows how to set the environment properties
> for
> * performing authentication using the GSS-API SASL mechanism.
> */
>
>
> public Object run() {
> /*
> * Java GSS-API
> *
> * The Java API for the Generic Security Service was also
> defined
> at the
> * IETF and is documented in RFC 2853. Sun is pursuing the
> standardization
> * of this API under the Java Community Process (JCP) and plans
> to deliver
> * a reference implementation with Merlin. Because the JCP is
> merely endorsing
> * this externally defined API, the IETF assigned package
> namespace "org.ietf.jgss"
> * will be retained in Merlin.
> *
> * Sun's implementation of Java GSS-API, will initially ship
> with
> support
> * for the Kerberos V5 mechanism only. Kerberos V5 mechanism
> support is
> * mandatory for all Java GSS-API implementations in J2SE,
> although
> * they are free to support additional mechanisms. In a future
> release, a
> * Service Provider Interface (SPI) will be added so that new
> mechanisms
> * can be configured statically or even at runtime. Even now the
> reference
> * implementation in Merlin will be modular and support a
> private
> provider SPI
> * that will be converted to public when standardized.
> *
> * The Java GSS-API framework itself is quite thin, and all
> security related
> * functionality is delegated to components obtained from the
> underlying mechanisms.
> * The GSSManager class is aware of all mechanism providers
> installed and is
> * responsible for invoking them to obtain these components.
> */
>
>
> GSSManager gssManager = null;
> KerberosPrincipal kerberosPrincipal = null;
> // try {
> gssManager = GSSManager.getInstance();
>
> // Set kerberosPrincipals =
> kerberosSubject.getPrincipals(KerberosPrincipal.class);
> // if (kerberosPrincipals.size() < 1) {
> // throw new RuntimeException
> // ("ServiceTicketGrabber requires a Kerberos
> Principal");
> // }
> // kerberosPrincipal = (KerberosPrincipal)
> // kerberosPrincipals.iterator().next();
> // } catch (RuntimeException e) {
> // e.printStackTrace();
> // }
>
> try {
> Oid kerberos5Oid = new Oid(Constants.KERBEROS5_OID);
>
> /*
> * The GSSName Interface
> *
> * This interface represents an entity for the purposes of
> * Java GSS-API. An implementation of this interface is
> instantiated below
> *
> * This call returns a GSSName that represents the user
> principal "plima"
> * at a mechanism independent level. Internally, it is
> assumed that each
> * supported mechanism will map the generic representation
> of
> the user to a
> * more mechanism specific form. For instance a Kerberos V5
> mechanism
> * provider might map this name to plima at FOO.COM where
> FOO.COM is
> * the local Kerberos realm. Similarly, a public key based
> mechanism
> * provider might map this name to an X.509 Distinguished
> Name.
> */
>
>
> GSSName clientName = gssManager.createName
> ("plima",
>
> GSSName.NT_USER_NAME);
>
> /*
> * The GSSCredential Interface
> *
> * This interface encapsulates the credentials owned by one
> entity.
> * Like the GSSName, this interface too is a multi-mechanism
> container.
> */
>
> GSSCredential clientCredentials =
> gssManager.createCredential
> (clientName,
> GSSCredential.DEFAULT_LIFETIME,
> kerberos5Oid,
> GSSCredential.INITIATE_ONLY);
> String serviceNameStr =
> "soasecimpl at mainline.actionaltraining.com";
>
> if (serviceNameStr == null) {
> throw new NullPointerException();
>
> }
>
> /*
> * The GSSContext Interface
> *
> * The GSSContext is an interface whose implementation
> provides security
> * services to the two peers (client and server).
> *
> * Before the GSSContext can be used for its security
> services it has to
> * be established with an exchange of tokens between the two
> peers.
> * Each call to the context establishment methods will
> generate an opaque
> * token that the application must somehow send to its peer
> using a
> * communication channel of its choice.
> *
> * The client uses the following API call to establish the
> context:
> */
>
> GSSName serviceName = gssManager.createName
> (serviceNameStr,
> GSSName.NT_HOSTBASED_SERVICE);
>
> GSSContext gssContext = gssManager.createContext
> (serviceName,
> kerberos5Oid,
> clientCredentials,
> GSSContext.DEFAULT_LIFETIME);
>
> /*
> * Packaging the retunred binary token in a string base64
> encoded format
> * to be retunred to the user via system.out
> *
> */
>
> byte[] inToken = new byte[0];
>
> byte[] outToken;
> outToken = gssContext.initSecContext(inToken, 0,
> inToken.length);
> String val = null;
> try {
> val = new String(Base64.encodeBase64(outToken),
> "US-ASCII");
> } catch (UnsupportedEncodingException e) {
> e.printStackTrace();
> }
> System.out.print("TOKEN VALUE: " + val);
>
> }
> catch (GSSException e) {
> throw new RuntimeException(e);
> }
> return null;
> }
>
> }
>
>
> -----Original Message-----
> From: Weijun.Wang at Sun.COM [mailto:Weijun.Wang at Sun.COM]
> Sent: Wednesday, December 30, 2009 7:11 PM
> To: Paulo Lima
> Cc: krbdev at mit.edu
> Subject: Re: Authentication attempt
> failedjavax.security.auth.login.LoginException: null (68)
>
> Can you provide more info about the context?
>
> - Full exception stack trace
> - What environment? simple Java SE or EE?
> - What API did you call? JAAS? JGSS? Third-party tool?
> - JAAS and krb5 configurations? system properties related?
>
> Thanks
> Max
>
>
> On Dec 31, 2009, at 1:21 AM, Paulo Lima wrote:
>
>> Any ideas on this error?
>>
>>
>>
>> ________________________________
>>
>> From: Paulo Lima
>> Sent: Wednesday, December 30, 2009 1:50 AM
>> To: 'krbdev at mit.edu'
>> Subject: Authentication attempt
>> failedjavax.security.auth.login.LoginException: null (68)
>>
>>
>>
>>
>>
>> Hi All,
>>
>>
>>
>> Has anybody seen this error before? Any ideas of what might be
>> causing
>> it?
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Paulo
>>
>> _______________________________________________
>> krbdev mailing list krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>
More information about the krbdev
mailing list