Re: [Wrapper-user] JBoss + Windows: service GSSAPI+Kerberos won't work for me with wrapper

[Christopher C. <chr...@gm...>]

Thanks Leif, replies inline:

On Mon, Mar 9, 2009 at 9:35 PM, Leif Mortenson <le...@ta...>wrote:

> I was not clear from your reply.   Is the keyTab file failing to be
> found BOTH when running under the Wrapper in console mode and when
> running under the Wrapper as a service?


Yes, it fails both ways.  To be clear though: by console mode, do you simply
mean running my run.bat from the console, which in turn invokes
wrapper.exe?  Vs. installing the service and clicking Start from the
Services menu?  Both of those approaches fail.  Is there another "console
mode" that bypasses wrapper.exe somehow?



>
> 1) The Wrapper creates a backend socket between the Wrapper and Java
> processes.  This results in two ports being bound.  By default these
> will be 31000 and 32000:
> http://wrapper.tanukisoftware.org/doc/english/prop-port.html
> http://wrapper.tanukisoftware.org/doc/english/prop-jvm-port.html
>

Cool, I doubt that's it, I believe communications to the KDC are on lower
ports (mainly 88).


>
> 2) Normally when a JVM is run, a java.library.path is not defined on
> the Java command line.  When this is the case, the JVM will search the
> system PATH by default for any native libraries.   When running under
> the Wrapper, for stability reasons, we specify a java.library.path for
> the wrapper.dll file.  We recommend that you use this method for any
> of your native libraries as well.  If your application makes use of
> any native libraries that would normally be found on the PATH they
> would not be found unless their location was added specifically.
> There is a property which will get the PATH support back by appending
> the full PATH to the java library path.
> http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-n.html
>
> http://wrapper.tanukisoftware.org/doc/english/prop-java-library-path-append-system-path.html


I'm pretty sure that's not it either, but good info and I'll keep a
lookout.  I use wrapper.java.classpath in my wrapper.conf to include .jar
dependencies that aren't in the JVM lib or the JBoss class path (where my
.ear is deployed).  All of the other application behavior besides this
GSSAPI stuff seems to be OK so it's likely all working.

As of Java 6 all of the needed GSSAPI and Kerberos implementation should be
available in the JRE.


> Could you add the wrapper.java.command.loglevel=INFO property and then
> copy the resulting Java command when running in Console mode into a
> reply email.  Send that along with the full java command generated by
> your JBoss startup script.  You can get that by inserting an "echo" at
> the beginning of the line where java is launched.    I might be able
> to point to the problem by comparing them.


I've made the script and wrapper.conf as similar as possible in terms of JVM
-D args etc.

Here's the full java command from my JBoss .bat:

"C:\Program Files\Extensis\Universal Type
Server\applications\jboss\bin\..\..\jre\bin\java"  -Dprogram.name=jboss.bat
-server -Xms512m -Xmx1024m -Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.krb5.realm=MTEST.EXTENSIS.COM-Djava.security.krb5.kdc=10.1.6.100
-Dextensis.krb5.service-principal=utswin/10.1.3.101-Djava.library.path="../services/lib;../../../../../Bonjour"
-Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname=
"-Djava.endorsed.dirs=C:\Program Files\Extensis\Universal Type
Server\applications\jboss\bin\..\lib\endorsed" -classpath "C:\Program
Files\Extensis\Universal Type
Server\applications\jboss\bin\..\..\jre\lib\tools.jar";"C:\Program
Files\Extensis\Universal Type
Server\applications\jboss\bin\run.jar";"C:\Program Files\Extensis\Universal
Type Server\applications\jboss\bin\..\services\lib\esp-preferences.jar"
org.jboss.Main -b 0.0.0.0

Here's the java command logging from wrapper:

wrapper  | command: "C:\Program Files\Extensis\Universal Type
Server\applications\jre\bin\java.exe" -server
-Djava.endorsed.dirs=../lib/endorsed/ -Dprogram.name=jboss.bat
-Djava.net.preferIPv4Stack=true -Djava.rmi.server.hostname=
-Djava.security.krb5.realm=MTEST.EXTENSIS.COM-Djava.security.krb5.kdc=10.1.6.100
-Djava.security.auth.useSubjectCredsOnly=false
-Dextensis.krb5.service-principal=utswin/10.1.3.101-Dsun.security.krb5.principal=utswin/
10.1.3.101 -Xms512m -Xmx1024m
-Djava.library.path="../services/lib;../../../../../Bonjour" -classpath
"run.jar;../services/lib/wrapper.jar;../services/lib/esp-preferences.jar;../services/lib/services.jar"
-Dwrapper.key="sUvQil1BnYGHRgIP" -Dwrapper.port=32000
-Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=3720
-Dwrapper.version="3.2.3" -Dwrapper.native_library="wrapper"
-Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 extensis.esp.win32.JBossService
org.jboss.Main -b 0.0.0.0




> What is the exception stack you are getting when the keyTab file fails
> to be located?


Here's a bit of it; most of the stuff higher in the stack are just
EJB/webservice layers:

2009-03-11 18:02:53,569    DEBUG    [extensis.esp.core]    50
<unknown>    <unknown>    - creating service GSSCredential
2009-03-11 18:02:53,569    ERROR    [extensis.esp.core]    50
<unknown>    <unknown>    Exception from GSSAPI:
GSSException: No valid credentials provided
    at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
    at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
    at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)
    at
extensis.esp.core.identity.auth.GSSCredentialsValidator.establishContext(GSSCredentialsValidator.java:114)
    at
extensis.esp.core.common.EspSessionBean.authenticateGSSAPICredentials(EspSessionBean.java:159)
    at
extensis.esp.core.common.EspSessionBean.authenticateCredentials(EspSessionBean.java:146)
    at
extensis.esp.core.common.EspSessionBean$AbstractFacadeMethod.invoke(EspSessionBean.java:248)
    at extensis.esp.core.ejb.SystemFacade.login(SystemFacade.java:112)
    at extensis.esp.core.ejb.SystemFacade.login(SystemFacade.java:103)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
    at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
(etc...)

I tried removing the -Dwrapper.key from the wrapper console output command
and running it directly at the prompt - no change, server runs but same
exception from GSS-API.

Thanks for your help.
- Chris