Livelink8 Password Encryption/Encoding

Paul_Manoian_(PManoian_(Delete)_1351693)

I am currently developing the Web Single Login standards for my company. At first glance, the livelink passwords appear to be BASE64 encoded; however, it seems to be slightly more complicated than that.My goal is to update the Livelink/Oracle database with a new password each time a user changes their password in our LDAP server. In order to do so I need to know what form of encoding that OpenText uses for its passwords. Is there some form of offset for each character before the whole password is encoded?Thanks in advance!Paul ManoianWeb TechnologistPhoenix Group, Division of Moorepmanoian@phoenixgroup.com

Find more posts tagged with

Comments

Scott_Chate_(schate_-_(deleted))

The nirvanna of single logon is a dream here at TransCanada too, but I understand this may be a capability of the upcoming productized version of the LDAP integration module from professional services. So I think I'm going to investigate that before trying anything ourselves. However you may want to inquire whether that is an option for your situation.

Dany_Riopel_(alcateladmin_-_(deleted))

There is already a Single Login module available from Open Text PS. We have purchased it and plan to install it around April 17. This module provides user authentication to LDAP. We have already tested the module, and it works quite well. Regards,Stephanie

Simone_Oettinger_(SOettinger_(Delete)_177592)

Open Text is comming up with a Directory Service module this Summmer. The module will support authentication (single login) and synchronization between Livelink and LDAP servers, as well as MS Exchange.

Mike_Zettler_(hoffmanadmin_-_(deleted))

We have been the first implementation of the Directory Synchronisation tool, using a module developed by professional services. I understand Opentext is turning this into a module and is starting the beta program.There is 2 parts to this module:- a synchronisation tool (java program) synchronizes the Livelink user data base with LDAP. It only extracts from LDAP users and groups being declared as Livelink users. The consequence is that there is no user management in Livelink anymore. We synchronize our 2500 Livelink users and 300 groups 3 times per day and it takes 10mn on average (heavy load on the system).- the login module authenticates through the web server onto the LDAP server and checks the password there. There is no password stored/ managed in Livelink anymore.We are using Netscape Directory Server 3.5 soon to be upgraded to V4 and all the 60000 people in our company are defined in it. An undocumented but extremely nice feature of this product (that we discovered by pure chance) is that, provided you have an NT infrastructure and the NT user info defined in your LDAP, it will go and validate your password on the NT PDC, so that you do not need to manage passwords on your LDAP server.This implementation has allowed us to accelerate the rollout and acceptance of Livelink tremendously. My recommendation would be to consider LDAP as a corporate resource for many other web based applications and hence as a seperate project independant of Livelink.

Scott_Chate_(schate_-_(deleted))

When we looked into this last year, the LDAP integration wasn't quite as sophisticated, and didn't include authentication against the LDAP, just the synchronization of users and groups.At that time I was asking for synchronization support for dynamic groups as well as static groups in LDAP. One of the big advantages of LDAP being the support for dynamic groups ( e.g.: the group Department_23 is dynamic if it is defined as all the LDAP entries who have a department number of 23 ). This is the optimal way to define groups in LDAP, and it would be best if Livelink LDAP integration supported this, by creating and managing those groups in Livelink to correspond to the results of the LDAP dynamic group query. When we investigated, only statically defined and maintained LDAP groups were being handled. Is the version you have now handling dynamic LDAP groups? Is the synchronization process that puts a heavy load on the server preventing people from using Livelink while it occurs?

Robert_Davies_(unlondonadmin_-_(deleted))

As someone considering the LDAP integration module these questions resonated with me.If you don't mind, can I ask whether you meant that your Livelink or LDAP server was heavily loaded, hence causing long update times? Or that doing the updates caused heavy loading on either Livelink or LDAP server. (And on which)It would also be helpful in trying to establish what kind of loads we are talking about if you could indicate what kind of hardware configuration you have, and what your normal LDAP loading is like.Many thanks for any information you can give us.Best regards/matt.

Mike_Zettler_(hoffmanadmin_-_(deleted))

The possibility to define dynamic groups, based on user attributes, exists in our current Livelink implementation. It is defined by a LLQuery attribute which is defined in the group. The grooup is not dynamic, once imported into Livelink, and you need to wait for the next synchronisation before it is updated.We are not using this feature, simply because the attributes in our LDAP are not coherent enough (for example department names are not standardized accross the company). Again, start with a good LDAP and then use it for LL...

Mike_Zettler_(hoffmanadmin_-_(deleted))

We have a Compaq dual processor, 400 MHz, 512 RAM. The performances are good, but during synchronisation the system is loaded 60% on average which slows down the usage. The synch process runs on a separate machine (as well as indexing nd viewing), and we still have some performance loss due to the database updates, but nothing too bad.

Sjaak_van_den_Akker_(originuser2_-_(deleted))

What kind of options are possible in the described tool for synchronisation of LDAP users for removing users?Are the users removed from LL immediately?If so: What happens with all the documents they own within the LL environment?Is it possible to have the removed users marked as removed (for a week or so) within LL in order to see for projects f.i. that this person is not known anymore and that somebody else has to take his / her responsibility.Is it possible to inform the LL administrator of all the work the removed user owned in order to give this administrator the possibility to change the permissions on this work in order to have somebody else taking over the responsibility of it.These are items we are interested in. Do you agree on needing these kind of functionality and is it implemented?Thanks and regards,Richard.

Mike_Zettler_(hoffmanadmin_-_(deleted))

> What kind of options are possible in the described tool> for synchronization of LDAP users for removing users?When a user is removed from Livelink, he can be either disabled or deleted from LL, depending on what option you select in the synchronization. We use the disabled option because the synch tool does not make a distinction between a deleted user and a user removed from all LL groups. We do not know if the person will not be reassigned to another group in which case she should have access to all previous permissions and to her personal workspace.When a user is deleted from a group, he is automatically removed from that group in Livelink, except if it is the last Livelink group he is a member of (not considering his base group). That means he will still be visible in this group although he cannot logon to LL anymore. Yet, you can edit this group and remove the user from it, and he then will only remain in the base group (you can never remove a user from his base group). *** This is the only case where anyone would have to edit groups within LL when using the LDAP integration ***> If so: What happens with all the documents they own > within the LL environment?The same as when you delete a person in Livelink. You can run LiveReports to reassign the documents to someone else.> These are items we are interested in. Do you agree on> needing these kind of functionality and is it implemented?Again, most of it has nothing to do with LDAP but with how LL handles the users.The synchronization tool itself has some not so nice behavior, for example it is difficult to rename or delete a group (renaming a group in LDAP deletes the original group in LL and creates a new one, so goodbye previously defined permissions :-( ). It is also largely undocumented and unspecified, because it is not a product yet. I would encourage you to register to the beta program and push OT to have a better defined product. In any case, this is no simple business to synchronize with LDAP, but the benefits still largely outweigh the problems (well, as long as we can keep coherence between LDAP and LL and we don't suffer from a major synchronization problem).