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

[Leif M. <le...@ta...>]

Chris,
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?

If it is failing under the Wrapper as a console that would help narrow
down the causes.

The Wrapper does not do anything at all to restrict what the JVM has
access to.  In console mode, it should run exactly as it would without
the Wrapper in the equation.   The only exceptions are as follows:

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

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

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.

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

Did you have a chance to run the Wrapper generated java command
without the wrapper.key property?

Cheers,
Leif

On Tue, Mar 10, 2009 at 10:17 AM, Christopher Corbell
<chr...@gm...> wrote:
> Leif,
>
> Thanks for your help - still no luck though.
>
> I have been alternately testing both in console mode and doing a full
> service install and start.  Also I am using wrapper.java.command so I'm sure
> that the JVM is OK (and I've tried a few other options including use of the
> freshest JDK).
>
> I just attempted going through a range of options with
> wrapper.ntservice.accountname and full service deployment, thinking it might
> be an issue of being able to access the keyTab file locally. This didn't
> really lead anywhere; we're using the default (.\LocalSystem) which should
> be providing the most local access anyway.  I also verified that the keyTab
> file is readable as are its parent directories.
>
> Reading through the MSDN service docs it certainly seems like it should work
> and that LocalSystem is the correct way to run the service.  Could it be
> that in calling back to the KDC there's some transport protocol or port
> that's used which an app launched by the wrapper wouldn't have access to,
> when a straight JBoss console run would?
>
> Another thought - does the service running via wrapper automatically do
> anything involving the host machine's login network domain/realm?  The
> machine I'm working on is actually not bound to the realm of the service's
> KDC (which is a test server), it's bound to our company realm (as my user
> login).  But the server KDC does have its own DNS and, as mentioned, it all
> works fine when running JBoss as just a straight console app.
>
> - Chris
>
> On Fri, Mar 6, 2009 at 8:40 PM, Leif Mortenson
> <lei...@ta...> wrote:
>>
>> Chris,
>> When it is failing to find the keyTab file, are you running as a
>> service or in console mode.  Please be sure to test in console mode.
>> If that works but the service fails it will significantly narrow down
>> the possibilities.
>>
>> Another thing to try is to run once with the following property set:
>> wrapper.java.command.loglevel=INFO
>> This will cause the full generated Java command line to be written to
>> the log.   Copy this into a batch file and, important, remove the
>> -Dwrapper.key parameter.   You will then be able to run your
>> application using the same settings as the Wrapper but without having
>> the Wrapper in the equation.  This mode was written as a sanity check
>> so the Wrapper can be removed from the list of potential causes.
>>
>> One common cause is running the wrong JVM.  When you run from your
>> run.bat, the JAVA_HOME or PATH may be finding a different java version
>> than the wrapper.  Setting the Java command to a known value will
>> resolve this kind of problem.
>> wrapper.java.command=%JAVA_HOME%/bin/java
>> You should be able to see he exact JVM being run by looking at the
>> above java command line.
>>
>> Cheers,
>> Leif
>>
>>
>> On Sat, Mar 7, 2009 at 7:26 AM, Christopher Corbell
>> <chr...@gm...> wrote:
>> > Has anyone used the magic compination of: wrapper (for Windows service),
>> > JBoss, and Kerberos/GSSAPI?
>> >
>> > What I'm finding is that when my (JBoss) service runs under wrapper, the
>> > Java GSSAPI code can't seem to load/validate the service's credentials.
>> > I'm
>> > using a local keyTab file exported from an ActiveDirectory KDC for the
>> > service credentials.
>> >
>> > When I do this with the standard JBoss run.bat (avoiding wrapper),
>> > everything works fine - the credential gets created and the
>> > acceptSecContext() call succeeds (meaning my service has been validated
>> > by
>> > the local keyTab file in conjunction with an ActiveDirectory KDC).  The
>> > local absolute path to the keyTab is configured (along with other
>> > Kerberos
>> > login module properties) in the JBoss login-config.xml file.
>> >
>> > When I run the exact same code and configuration but run my service via
>> > wrapper, I get a "GSSException: no valid credentails provided" error.
>> > Most
>> > of the time I've seen this exception during credentials creation it's
>> > because the service can't find or resolve its keyTab file.  Any reason
>> > the
>> > wrapper-launched service might fail to resolve an absolute path to a
>> > local
>> > keyTab file, or fail to read the file, when it works fine via straight
>> > launch of JBoss?
>> >
>> > I'm using JBoss 4.0.5 and wrapper 3.2.3.  Thanks for any help.
>> >
>> > - Chris