Pointing Lawson to an LDAP server with a different Root DN -

Name	Points
Greg Moeller	4184
David Williams	3349
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1377
Roger French	1315
mark.cook	1244
Chris Martin	825

Jonathan Lake

New Member

Posts: 2

10/18/2012 4:11 PM

LDAP is AD bound.

We had implemented our production lawson environment to point to an LDAP that has o=lawsonprd,dc=company,dc=org as the root DN.
Our DR lawson environment was created pointing to an LDAP server that has o=lawsonprddr,dc=companyp,dc=org as the root DN.

We are trying to reconfigure our DR environment to use a replicated LDAP server which is identical to prod. using o=lawsonprd,dc=company,dc=org as the root DN.

Here is what I have done:
ssoconfig -c option 3 and reconfigure this to point to the different ldap server. lase fails to start.
I edited $LAWDIR/system/RMApiInit.properties and updated all the hard coded LDAP DN's to reflect what it should look like to make this work. Lase now starts, however smoke tests fail with:
Error: Failed to authenticate user lawson
Message: com.lawson.lawsec.authen.LSFSecurityAuthenException:Message:javax.crypto.BadPaddingException: pad block corrupted. This is where I am stuck.

It is my understanding there is some encryption mismatch. I did an ssoconfig -c to export the services and identities, and the items causing problems are put in the lase_server log. The services export fine, the identities provide a huge list of what could not be exported. I am stuck and not sure what to do next.

I don't know if re-doing an ldap bind would help (I wouldn't think so but could be worth a try).
If deleting and recreating users in ldap would help any.

I'm hoping to get this resolved for our DR test this weekend.

Jonathan Lake

New Member

Posts: 2

10/18/2012 6:56 PM

I have found that if I do an ldapbind on our DR server, ssosmoketest works and I can bring up the environment. However, this breaks our prod environment, giving the cell padding errors with the ssosmoketest.

Is there a way to move our DR server to use the same LDAP instance as our prod server without breaking either environment?

Roger French

Veteran Member

Posts: 549

New Poster

10/18/2012 9:04 PM

I think you're going down a path that will give you more headaches. It sounds great in theory, but I don't think it's going to work.

One Lawson environment requires one Lawson LDAP.

Another Lawson environment requires another, separate Lawson LDAP.

Not recommend and most likely not doable (I've never done it) to have a single Lawson LDAP for two separate Lawson environments.

Both Lawson environments can be bound to your organization's AD (used for sso passwords) using the ldapbind tool.

John Henley

Posts: 3364

New Poster

Engaged Reader

Avid Reader

10/19/2012 11:50 AM

I'm trying to understand what you're attempting, but it's confusing to mix "ldapbind" with "ldap repository", as the two are different.
As simply as I can explain:
- "ldapbind" (when referring to LSF) is the authentication mechanism used by Portal (the SSOP service) to authenticate a user. Where it gets confusing is that LSF also uses an ldapbind internally against it's own repository in addition to the SSOP authentication. So in the $LAWDIR/system/install.cfg, the LDAPBINDDN parameter is the internal ldapbind --- not the SSOP service's ldapbind. So you have to be very specific about which ldapbind you're talking about. For some clients, ldapbind for SSOP is done against the Lawson internal LDAP repository (i.e. LSF manages SSOP passwords); for others SSOP is bound to a corporate LDAP, typically Active Directory.

- "ldap repository" is the container used by LSF to store security-related data (i.e. users, their identities, security classes, roles/rules).

For your DR test, I'm assuming you have a separate DR LSF environment, on a separate server, on a separate network.
Are you trying to point that environment, which contains it's own LDAP repository, to a different AD for ldapbind for SSOP ?
Or are you trying to copy the production LDAP repository to update/replace the DR LDAP repository so that you have a refreshed copy of the users, security rules, etc.?