LAPI and LDAP 2

[oscript]

Does anyone have any experience of connecting to a Livelink instance using LAPI and LDAP authentication. In other words normally you use the LL_SessionAllocEx passing in the necessary login and server details but if LDAP is enabled then how is this done for example as the logged in user ?

Any help gratefully received.

 

[suhailnizam]

Hi all
i m using lilvelink 9.0.0.1 with sql 2000 server along with win2k server, my server get crashed, fortunately i have a backup i restored everything from my backup. Each n every services of my server is working.
But there is no connectivity between livelink and sql database as soon as i gets login into Livelink it says "could not connect". Could anyone help me out with this.

Thanx in advance

 

[oscript]

If you remove the following lines from the Opentext.ini file then you will be presented with the 'connect to a new or existing' database page when accessing via Admin:

1. Stop the Admin and Livelink services.
2. Backup the Opentext.ini file.
3. In the general section: remove the dftConnection entry.
4. Remove the entire [dbconnection] section.
5. Restart the services and login as Admin.

Hope that this helps.

 

[Elst]

Does it make sense to install LDAP for permission management when you are using LL?
Is there any other directory software that would be more appropriate?
We are currently using LL 9.1 and plan to jump to LL9.5 later this year.
Thank you for your help

 

[appnair]

We use NTLM authentication (User Name Only) in our organization and tie to our company's Active Directory service.Our directory services module is directory_2_2_1.It is pretty simple to setup the only overhead being we have to re-create each user again in the livelink DB.We don't plan to synchronize as our AD population is so huge that may affect licensing on our livelink.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[VOLFONI]

Hi,
We have LDAP authentication at the Web server (sun one) level additionaly to Directory service.
We do not have any problem connecting with LAPI.
regards

 

[BKQc]

I think I understand what you want as we encountered the same "problem" here. First of all, I want to mention that I didn't try every options I will explain here and that we're using .NET version.

The first thing you may look at is HTTP tunnelling. Using this method, you should be able to directly use NTLM by setting EnableNTLM to LL_TRUE in the config parameter (typed as LLValue). Normally, this should authenticate the user to the webServer. This is one of the methods we didn't test.
My fear about this approach is that even if you use impersonation on the web server, if you don't use kerberos (and even if you do, maybe LAPI doesn't support it), the security token will probably [red]not be passed[/red] to the web server.

Second option is to use impersonation using the ImpersonateUser(loginName) method. To be able to do this, you must be logged as Admin which may become a [red]security breach[/red] for some reasons:[ul][li]You must enter somewhere Admin password[/li]
[li]A user in debug mode could print the value of fPassword in the command window[/li]
[li]If the password is directly in the code, the code could be decompiled and the password would render visible[/li]
[/ul]
Third option: develop and "In-Livelink" mechanism of authentication based on "private-public key". What you could do is use a DB to store a key which is regenarated on a regular basis which key is used by both LL and your LAPI component/wrapper. But this is [red]not bullet-proof[/red] neither:[ul][li]A user in debug mode could print the value of fPassword in the command window[/li]
[li]The code could be decompiled and your logic would render visible[/li]
[/ul]

To prevent uncompile, what you could do is to use Precompiler Instructions and give 2 versions of a wrapper: 1 for developers and 1 for production. The first one would use a default user or a "Dev-User" submitted by the developper which would then be replaced by your impersonated user.

If you have any question/suggestion/remark, feel free to ask them! I hope we'll be able to help each other on this delicate subject.

 

[appnair]

what is this about.Are you explaining how to connect to a livelink server/web server that has single sign on(read directory services) installed.
I have a hard time understanding the post as it talks a whole lot about a lot os things above my head.
There are several examples at opentext that allows you to connect and even a lapiconnection tester tool that allows you to debug
What kind of security implications are you trying to solve
My understanding is even with all kinds of security at the web server in place,it takes a livelink account( a user account needs to exist in livelink) to access the livelink object be it a lapi call or a GUI call.
Please consider writing this as an FAQ as it will help other livelink enthusiasts also.Please provide sufficient clarity(I apologize for being dumb) but please write it in the context of people who like me administer livelink,but do not have an advanced networking/http protocol degree.


Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[BKQc]

Yes, you're right about the intentions: the goal is to "simulate" SSO in LAPI.

First of all, after taking a look to the inners of EnableNTLM, it doesn'T look like it will do it for SSO. It seems to simply receive user/password and encode it in an NTLM header.

But simply for general comprehension for those who don'T know, there are 3 ways to connect to LL using LAPI: non-tunneled, non-secure tunneled and secure tunneled.

From what I know, the first one talks directly to llserver on the port you find in "the Port variable in the [general] section of the opentext.ini file" usually 2099. This is I suppose the fastest method as there is no middle tier application to handle the request.

Both secure and non-secure tunneled connections use the same basic operation: talk to the web server. The main difference is if it uses SSL or not. Normally, unsecured will be on port 80 and secured on 443. This is mainly useful if your application have to go through a proxy or firewall. If you have to connect through a proxy, read carefully the documentation on how to set your different connection parameters.


The impersonateUser method seems to be the OT way of doing it. The principle is easy: you log as Admin and then pretend to be someone else. See the above post for more warnings.

The last method is more of a PS customization and is not really supported. This imply that you will probably have to modify the code for each upgrade or patch as you will probably have to override the _login method of the APIBase:APIHandler object in the builder. The basic about it is to detect what type of user you have and if it is using a hash login through LAPI, try to log it in using the private key in the DB. This approach demands a lot more development but from many aspects is more dangerous than others if well implemented.

BTW, the regeneration of the key may be done in many ways: agent in LL, trigger in DB, parallel application, etc.

Once you have this key, you may hash with user name and a public key or anything like that. You may also read about cryptography and secure apps before getting in this process.

Hope this helps a bit

 

[appnair]

Great job BKQC converting the latin into something more I could understand.I really appreciate the time you took in putting this.Now I know who to talk when I am having problems with LDAP/Single Sign On.I was always puzzled by examining the ll_environ assoc on my builder with SSO and it seemed to just believe windows sending the domain\username.Pretty much since we are intranet I believe it is safe.I believe(I may be wrong) in our simple case with NTLM enabled it gets the header assoc(for eg conoco\<myuserid>) parses it out uses the ini 'Admin' password to get and set all necessary sessions(I see that being used so much in code).I don't really know if the impersonate user is happening here.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937