Fails with NTLM

I am unable to get LAPI working with NTLM authentication.

The Opentext "test connection" utility works fine, but when I try and run the attached .NET code I get "loader lock" warnings. If I suppress these warnings the application just hangs then quits - no error messages or anything else.

Using the commented out line to connect to our backend server in the normal manner works without issue.

Can someone point out what I'm doing wrong? Can anyone confirm exactly which LAPI DLLs I should be adding a reference to?

Many thanks

code.txt

Find more posts tagged with

Comments

Appu_Nair1

If the connection is with HTTPS as your code says,then Livelink Secure Connect needs to be installed.It basically allow your client code to use a "cert" when talking https to the livelink webserver who is https as well.The livelink secure connect install has sample code to do that.If you are starting completely new perhaps this is an oppurtunity to do programming in the new webservices paradigm?

Alison_Bilton

Where in my code does it say I'm connecting using HTTPS? I have the HTTPS parameter set to false.

I'm aware of webservices, but we won't be moving to that for a few months yet when I convert our existing LAPI applications (which all link directly using a user name and password to the admin server).

All I want to do here is quickly knock up a load testing application to hit the front-end web servers using NTLM before we proceed with our live upgrade.

Appu_Nair1

Sorry blind with work.I wrote this piece in java/C# few years back that served in most cases where livelink was configured to use SSO and with IWA with the DirSvcs setting set to take off the domain info.

Here is a link for that https://communities.opentext.com/communities/cs.dll/open/2124975

Perhaps you can look at and see if you are doing something similar.

The main thing to remember is when you call the livelink cgi and put func=admin.testargs you should see the "REMOTE_USER" variable coming in.Livelink should be configured to use "REMOTE_USER" and the case of the userid in livelink should be lower to avoid a lot of hassle..Livelink code will reject if user is 'DOMAINANME\APPUNAIR' and the kuaf record says 'appunair'.This will probably never happen in a case insensitive sql server database but in oracle you have to really watch for that as well as most defualt installs are CS.

That is how I figured(or rememeber about that) out most of the problems when coding

Since you have wantalapilogs in this version you can enable that and see the input args or post it here for the community to see.

Alison_Bilton

Thanks very much for your input Appu.

we are using an Oracle database as it happens. I ran ?func=admin.testargs and REMOTE_USER is listed as HIGHWAYS\XXATOSAB3. The KUAF table lists the user as xxatosab3.

Settings under Configure Authentication Source are:
Username Style = Username only
Case Sensitivity = Lowercase
Environment variable = REMOTE_USER.

I've tried running your code sample with the user set to be uppercase, lowercase, with and without the domain and with the password set to blank, plain text and the encrypted value in KUAF.

I've tried with various combinations of the lapi_netp, lapi_nets, lapi_sspip and lapi_sspis DLLs referenced.

No success.

I've attached the thread log generated whilst I had wantLAPILogs switched on.

thread1.out

Appu_Nair1

I am not seeing your lapi call in this thread log.What you could attempt or check is whether you did that correctly.

It hould usually be

Debug=2

wantlogs=true

wantlapilogs=true

usually all the other settings in that section is default

Now run the socket lapi call that works and look in the logs,it could be in any of the threads something like _inargs and you should see a record coming thru.

Now attempt with the tunneled lapi call and see if you see anything like that and compare.

This is probably unwanted but read on as these are my observations and having seen the new otdsintegration stuff

I see from your thread startup these lines

08/17/2012 10:53:07 #OSpace: otdsintegration Root: #32000001 Size: 135936

and these 08/17/2012 10:53:08 #OSpace: directory                      Root: #4e000001 Size: 291072          File: F:\OPENTEXT\module\directory_10_0_0\ospace\directory.oll
08/17/2012 10:53:08 The LDAP dropin is using the LDAP SDK library located in: F:\OPENTEXT\bin\ldapsdk.DLL
08/17/2012 10:53:08 #OSpace: ldap                           Root: #4f000001 Size: 208640          File: F:\OPENTEXT\module\directory_10_0_0\ospace\ldap.oll
08/17/2012 10:53:08 #OSpace: ntlm                           Root: #50000001 Size: 83712           File: F:\OPENTEXT\module\directory_10_0_0\ospace\ntlm.oll

The fact is that when otdsintegration is present the authentication code of livelink is going to hit the tomcat(java code deployed in for making that work) so in all probability this is probably never going to work for you.You might want to touch base with somebody who knows livelink authentication(the oscript side) and lapi.Or it would probably be an hour of your time to write something in websvcs although I think websvcs also has a problem handling SSO.Perhaps it is fixed now.

Or simpler still is if you want to test out a livelink with just CS10 and directory services and keep that for your load testing app,I know not if that s a configuration that is going to work for you.

Your requirement as I read said that you ware trying to mimic a load testing scenario.How would calling something in lapi be akin to that ,there is no html that is shown so lapi tends to be very fast in that case so I am not sure how you will kind of deduce user's hitting the app.

Pierre_Nocera

You're not behind a proxy ?

Alison_Bilton

Cracked it!

The PATH variable hadn't updated. I copied lapi_base.dll and llkernel.dll to my application's bin directory and it works like a dream now.

Thanks very much for all your help.