11 Replies Latest reply: Jun 18, 2010 2:49 PM by 843810 RSS

    Kerberos TGT From Memory

    843810
      I am rather new to Kerberos. Our workstations when logging in already have a TGT stored in memory.

      I have been trying to find a way to pull this information from the memory cache. Is this even possible? If so, where should I begin?

      Thanks!
        • 1. Re: Kerberos TGT From Memory
          843810
          The Java Krb5LoginModule allows to use the native in-memory Kerberos ticket.

          For details refer to the Java GSS programming guide:
          http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/index.html

          Seema
          • 2. Re: Kerberos TGT From Memory
            843810
            Thanks for the quick reply.
            • 3. Re: Kerberos TGT From Memory
              843810
              I'm still doing something wrong. I have a simple login setup to authenticate. However, it is still prompting for my password.

              I got this error:

              Kerberos password for <principal>: <password>
              Authentication failed:
              Pre-authentication information was invalid (24) - PREAUTH_FAILED


              In my client config
              com.sun.security.auth.module.Krb5LoginModule required
              useTicketCache=true
              principal="<principal>";

              I can add doNotPrompt=true

              then I get:
              Authentication failed:
              Unable to obtain password from user

              Message was edited by:
              jjhusa01
              • 4. Re: Kerberos TGT From Memory
                843810
                Here is my debug

                Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is isInitiator true KeyTab is null refreshKrb5Config is false principal is <principal> tryFirstPass is false useFirstPass is false storePass is false clearPass is false
                Acquire TGT from Cache
                Principal is <principal>
                null credentials from Ticket Cache
                          [Krb5LoginModule] authentication failed
                Unable to obtain password from user

                Authentication failed:
                Unable to obtain password from user
                • 5. Re: Kerberos TGT From Memory
                  843810
                  I got it working. Apperently, It had to do with encryption. We are using Java 1.5 and it doesn't support AES256. I adjusted it to use Triple DES and it worked fine. However, I cannot read it from the PIPE cache.
                  • 6. Re: Kerberos TGT From Memory
                    843810
                    Sorry to bump this. But between looking for information and feeling I may have not accurately described my problem, I decided to post again. Hopefully giving a clearer picture of what I am looking at.

                    First, let me try to explain what I am working with.

                    OS: RedHat Enterprise & CentOS
                    Location of TGT: PIPE:#### stored in memory
                    Java Version: Java(TM) SE Runtime Environment (build 1.6.0_01-b06)


                    At log on, the PIPE is created in memory and given a four digit number. This is where the credential cache is stored. From what I understand, this most likely considered an "unnamed" pipe. Therefore, only the parent/children processes can access this. I believe this is where my problem is coming from. I need a separate Java application to access this and authenticate to use other Java applications.

                    I have used the examples Seema has posted. I can get it to work with only a file Ccache. I generally set the file to /tmp/krb5cc_uid. I have been able to test and authenticate this way. Again, once I move it to the PIPE, I cannot read the Ccache.

                    Moving this to a file is out of the question. For security reason, most likely reason I am having my problems, it must stay in this form.

                    Message was edited by:
                    jjhusa01

                    Message was edited by:
                    jjhusa01
                    • 7. Re: Kerberos TGT From Memory
                      843810
                      The Java Krb5LoginModule can read Kerberos ticket following native ticket cache:
                      - File based ticket cache
                      - Windows in-memory ticket cache using LSA API

                      Can you send me the details of your in-memory ticket cache on Linux ?

                      Seema
                      • 8. Re: Kerberos TGT From Memory
                        843810
                        Seema,

                        You'll have to excuse me. My Linux/Unix programming is limited to classroom experience in which we never covered anything like this.

                        What information are you looking for about the ticket cache?

                        From what I know, its a credential cache stored in a pipe in memory.

                        At login a PIPE is initialized. Kinit, which is the child of kshell creates the pipe. The name of this pipe is stored in the KRB5CCNAME variable. When it was a file cache, it was "FILE:/tmp/krb5cc_uid". Now it is set to "PIPE:XXXX" where XXXX is an integer. Just for an example, we'll use 1234. In the Linux environment, KRB5CCNAME=PIPE:1234.

                        The PIPE will store the exact information as the krb5cc_uid file would.

                        I think the problem stems from the java applications are not children of the shell that created the pipe.

                        I can run kshell to create a new shell and kinit under that. That will setup another pipe to store my ticket.

                        Message was edited by:
                        jjhusa01
                        • 9. Re: Kerberos TGT From Memory
                          843810
                          I solved my problem. I was unaware the pipe was written by an internal programmer. I have gotten in contact with him and solving my problem.
                          • 10. Re: Kerberos TGT From Memory
                            843810
                            Hi,

                            Though this a very old thread but I am still writing with hope.

                            I am using Kerberos for the first time. Our application is deployed in Jboss - Linux and need to validate against AD. When I test the "Jboss negotiate toolkit (jboss-negotiation-toolkit/SecurityDomainTest?securityDomain=host), I get the following error. Same error comes when I try for application as well.


                            2010-04-17 10:42:31,105 INFO [STDOUT] Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is /opt/apps/obcbs/obdsmq-zd6.keytab refreshKrb5Config is false principal is HTTP/localhost@REALM tryFirstPass is false useFirstPass is false storePass is true clearPass is false
                            2010-04-17 10:42:31,109 INFO [STDOUT] Key for the principal HTTP/localhost@REALM not available in /opt/apps/obcbs/obdsmq-zd6.keytab
                            2010-04-17 10:42:31,109 INFO [STDOUT] [Krb5LoginModule] authentication failed
                            Unable to obtain password from user
                            2010-04-17 10:42:31,110 ERROR [org.jboss.security.negotiation.toolkit.SecurityDomainTestServlet] testDomain Failed
                            javax.security.auth.login.LoginException: Unable to obtain password from user

                            at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:789)

                            I am really struggling with these errors for last 1 week. I will really appreciate any of your valuable suggestion.

                            I have also logged an another thread. Will appreciate if anyone helps on this. New Thread - http://forums.sun.com/thread.jspa?threadID=5435969

                            Many Thanks.

                            Best Regards - Sidd
                            • 11. GSS API failing with java 1.6 but working with java 1.5 in jboss 3.2.6
                              843810
                              Hi,
                              i am trying to update java 1.5 to 1.6 on jboss 3.2.6 but i getting following exception. the current code work perfectly with java 1.5 but start failing when use 1.6


                              18:05:08,210 INFO [STDOUT] GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
                              18:05:08,210 INFO [STDOUT]      at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Krb5AcceptCredential.java:87)
                              18:05:08,210 INFO [STDOUT]      at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:111)
                              18:05:08,213 INFO [STDOUT]      at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:178)
                              18:05:08,214 INFO [STDOUT]      at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:384)
                              18:05:08,214 INFO [STDOUT]      at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:42)
                              18:05:08,214 INFO [STDOUT]      at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:139)
                              18:05:08,214 INFO [STDOUT]      at com.apple.ist.ds.server.impl.snkp.SSOTokenVerifier.credentialForService(SSOTokenVerifier.java:324)
                              18:05:08,214 INFO [STDOUT]      at com.apple.ist.ds.server.impl.snkp.SSOTokenVerifier.initialize(SSOTokenVerifier.java:97)
                              18:05:08,214 INFO [STDOUT]      at com.apple.ist.saci.iphonevpn.servlet.SACIIPhoneStartUpServlet.init(SACIIPhoneStartUpServlet.java:26)
                              18:05:08,214 INFO [STDOUT]      at javax.servlet.GenericServlet.init(GenericServlet.java:256)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1029)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:862)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4013)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.StandardContext.start(StandardContext.java:4357)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
                              18:05:08,214 INFO [STDOUT]      at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
                              18:05:08,214 INFO [STDOUT]      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                              18:05:08,214 INFO [STDOUT]      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                              18:05:08,214 INFO [STDOUT]      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                              18:05:08,215 INFO [STDOUT]      at java.lang.reflect.Method.invoke(Method.java:597)
                              18:05:08,215 INFO [STDOUT]      at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:149)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
                              18:05:08,215 INFO [STDOUT]      at org.apache.catalina.core.StandardContext.init(StandardContext.java:5441)
                              18:05:08,215 INFO [STDOUT]      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                              18:05:08,215 INFO [STDOUT]      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                              18:05:08,215 INFO [STDOUT]      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                              18:05:08,215 INFO [STDOUT]      at java.lang.reflect.Method.invoke(Method.java:597)
                              18:05:08,215 INFO [STDOUT]      at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:149)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:316)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:76)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:320)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.web.WebModule.startModule(WebModule.java:62)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.web.WebModule.startService(WebModule.java:40)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
                              18:05:08,215 INFO [STDOUT]      at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
                              18:05:08,215 INFO [STDOUT]      at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
                              18:05:08,215 INFO [STDOUT]      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                              18:05:08,215 INFO [STDOUT]      at java.lang.reflect.Method.invoke(Method.java:597)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
                              18:05:08,216 INFO [STDOUT]      at $Proxy20.start(Unknown Source)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.system.ServiceController.start(ServiceController.java:414)
                              18:05:08,216 INFO [STDOUT]      at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
                              18:05:08,216 INFO [STDOUT]      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                              18:05:08,216 INFO [STDOUT]      at java.lang.reflect.Method.invoke(Method.java:597)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
                              18:05:08,216 INFO [STDOUT]      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)

                              18:05:08,221 INFO [STDOUT] Caused by: javax.security.auth.login.LoginException: java.lang.NullPointerException
                                   at com.sun.security.auth.callback.TextCallbackHandler.handle(TextCallbackHandler.java:102)
                                   at org.jboss.security.auth.spi.UsernamePasswordLoginModule.getUsernameAndPassword(UsernamePasswordLoginModule.java:216)
                                   at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:131)
                                   at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:124)
                                   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                                   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                                   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                                   at java.lang.reflect.Method.invoke(Method.java:597)
                                   at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
                                   at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
                                   at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
                                   at java.security.AccessController.doPrivileged(Native Method)
                                   at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)