#272 Error using single sign-on native library under the wrapper

Martin Sant

I have a rather peculiar problem using a single sign-on native library for windows in a windows service vrated with the wrapper (the library is ntlmauth.dll from http://jtds.sourceforge.net\). The library basically gets domain, username and password of the currently-logged-on user in windows. We want to use this single sign-on system on a datalogger project were developing so we can install our software on new computeres without having to ask for the user´s windows account information. Im linking to the native library using java.library.path in wrapper.conf and i should be locating the library fine as when i temporarily remove it i get a "java.lang.IllegalStateException: Native SSPI library not loaded." exception.

Here´s my problem. When i run wrapper.exe from a console (using wrapper.exe -c wrapper.conf) everything works fine, or even if i just run the program with a java.exe command. Im using the user´s sign-on information to create a DCom-connection and i can do so without explicitly typing in the windows user´s username and password. Great. When i create a windows service with the wrapper batch-files , however, and start it, my program is unable to make the DCom-connection and i get a nondescript SocketTimeoutException. I do know the actual windows user´s username and password on our testmachine and when i use those directly to create the DCom-connection everything works fine, even as a windows service.

Any ideas as to what the core of the problem might be? My program seems to only fail when i install it as a windows service. Could it be because of somehow differing environments between a console and a windows service? I've tried setting account and password with the wrapper configuration properties, wrapper.ntservice.account, wrapper.ntservice.password, but this still doesnt work.

What am i missing here?


  • Leif Mortenson

    Leif Mortenson - 2010-02-25

    I do not have experience with that library, but most likely this is being caused because the Wrapper is running as the "SYSTEM" user when running as a service by default. This is different than the currently logged in user so the library may not be figuring out what the current user is.

    It is possible to tell Windows to run the service as a specific user by using the wrpaper.ntservice.account property:

    As a quick test, could you read the above page and then try setting the account to the current user and rerunning your test.


  • Leif Mortenson

    Leif Mortenson - 2010-02-25
    • assigned_to: nobody --> mortenson
  • Martin Sant

    Martin Sant - 2010-02-25

    Hi Leif

    I tried setting the wrapper.ntservice.account property in wrapper.conf but i get a logon failure as i try to start the windows service, please excuse the danish: Unable to start the service - Tjenesten startede ikke pga. en logonfejl. (0x42d)

    Now that seems to me that its missing the password, which i then set with wrapper.ntservice.password. Now the service starts and i can even see the service is set to launch on the specified account rather than local system account (in control panel->Administrative tools->Services). I am, however, still getting the same SocketTimeoutException as described above. For wrapper.ntservice.account i've tried the values ".\username" and "actual-domainname\username" and neither worked.

    Thank you for pointing out the system user is different from the logged-in user. I didnt know that. Maybe that has something to do with the error im getting though. I've fiddled around with it some more and tried creating another windows user (with admin rights). Using that account to open a DCom-connection gives the same SocketTimeoutException. Maybe the DCom-connection doesnt want to open when it is using credentials other than the logged-in user. But then shouldnt it work once we set the windows service to launch with the same account+password as the logged-in user?

    Any other suggestions on how to solve this? There must be something different between running the program from a console and as a windows service.

  • Martin Sant

    Martin Sant - 2010-02-26

    No my application doesnt have a javax.comm.properties file, nor the win32com.dll file. I found a copy of these two files (on http://www.cs.uml.edu/~fredm/courses/91.305/software/JDK118-javaxcomm.zip\) and placed them according to the FAQ you linked. This still did not do away with the error im getting.

    Here is a stack trace of the only exception im getting when running my application as a windows service. The stuff above dk.sdu.mmmi.predict.sl4logger.Daemon is part of the application and below it is the wrapper and underlying DCom-library:

    dk.sdu.mmmi.predict.sl4logger.driver.SL4DCOMException: Opening SL connection failed.
    at dk.sdu.mmmi.predict.sl4logger.driver.SL4BasicDCOMConnector.<init>(SL4BasicDCOMConnector.java:97)
    at dk.sdu.mmmi.predict.sl4logger.driver.SL4ReliableDCOMConnector.reinit(SL4ReliableDCOMConnector.java:32)
    at dk.sdu.mmmi.predict.sl4logger.driver.SL4ReliableDCOMConnector.<init>(SL4ReliableDCOMConnector.java:27)
    at dk.agrotech.infogrow.setup.DetectClimateComputerSetup.<init>(DetectClimateComputerSetup.java:51)
    at dk.agrotech.infogrow.setup.LoggerConfigurationManagementThread.<init>(LoggerConfigurationManagementThread.java:36)
    at dk.sdu.mmmi.predict.sl4logger.driver.Driver.<init>(Driver.java:77)
    at dk.sdu.mmmi.predict.sl4logger.driver.Driver.createDriverWithDefaultPersistence(Driver.java:181)
    at dk.sdu.mmmi.predict.sl4logger.Daemon.start(Daemon.java:55)
    at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:3271)
    Caused by: org.jinterop.dcom.common.JIException: An internal error occurred. [0x8001FFFF]
    at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:576)
    at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:481)
    at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:445)
    at dk.sdu.mmmi.predict.sl4logger.driver.SL4BasicDCOMConnector.<init>(SL4BasicDCOMConnector.java:86)
    ... 8 more
    Caused by: java.net.SocketTimeoutException
    at sun.nio.ch.SocketAdaptor$SocketInputStream.read(Unknown Source)
    at sun.nio.ch.ChannelInputStream.read(Unknown Source)
    at org.jinterop.dcom.transport.JIComTransport.receive(JIComTransport.java:152)
    at rpc.DefaultConnection.receiveFragment(DefaultConnection.java:199)
    at rpc.DefaultConnection.receive(DefaultConnection.java:85)
    at rpc.ConnectionOrientedEndpoint.receive(ConnectionOrientedEndpoint.java:226)
    at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:123)
    at rpc.Stub.call(Stub.java:113)
    at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:568)
    ... 11 more

  • Christian Mueller


    I'm very sorry for the delay replying you.

    Have been able to resolve your problem?
    I prepared some COM examples from j-Interop, but haven't been able to execute and test them properly yet.
    I will run the tests until this weekend and report back to you what behaviour I was experiencing.

    Best Regards,

  • Martin Sant

    Martin Sant - 2010-03-31

    Awesome that you're willing to test this out.

    In the meanwhile i've been pulled away to work on a different project and so our problem remains unsolved. However, we´re still very much interested in figuring out why we get this DCom-error while under the wrapper and hope to get this to work at a later date.

  • Christian Mueller


    I'm sorry for keeping you waiting for my reply.
    I haven't been using DCOM in Java so far and I'm more the unix developer.

    I created a very small test app using j-interop to access Windows Management Instrumentation and Internet Explorer. The code was following basically your example:
    - parameterless createSession()
    - creating the JIComServer via the session & ClassID valueOf the UUID value.

    I was successfully running this app with the wrapper in console mode.
    However when running as service, I initially run into org.jinterop.dcom.common.JIException: Access is denied ....
    After setting the wrapper.ntservice.account property to a user account the example was also working when running as service.
    This however doesn't seem like a problem with the wrapper but rather in interpreting the Local System User Account, which is by default running the application.

    Relevant parts of my conf file look like this:
    wrapper.java.classpath.1=../lib/example.jar -- My example jar
    wrapper.java.classpath.3=../lib/j-interop/*.jar -- the jars from j-interop (jcifs-1.2.19.jar,j-interop.jar,j-interopdeps.jar)
    wrapper.java.classpath.4=../lib/jtds/*.jar -- the jars from jtds (jtds-1.2.5.jar)

    wrapper.java.library.path.2=../lib/jtds -- the location of the ntlmauth.dll file (I only copied the x86 bit library to there)

    I however could not reproduce - so far - the SocketTimeoutException you are seeing.

    Can you tell me more of your application? Are you accessing a remote target?



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks