LawsonGuru Blog

One of the highly touted new LSF9 features is Lawson Single-Sign-On (SSO).
In LSF9, each user is assigned a resource record, which stores basic user information, such as first and last name, default product line, whether the new LS (Lawson Security) is enabled or not, whether a user is a Portal Administrator, etc. Each resource record is also associated with one or more identities. Identities store user-specific information–used by Lawson SSO–to interact with a particular service.

Identity records minimally include the SSO Primary (SSOP) for your Lawson Portal username, and possibly your (encrypted) password. Identity records are also used for the OS/Lawson Environment as well as additional products such as LBI, PSA, etc. Finally, identity records store Lawson self-service information, such as Company number and employee ID associated with Employee/Manager Self-Service:

Single Sign On Primary (SSOP) acts as the “master” password for a user, and is used to “unlock” the other passwords for the given user, which are all stored in the LDAP repository. When you sign onto Portal, you are using the SSOP password. From there, Lawson SSO takes care of signing you into other modules.

The SSOP password for the lawson installation user (i.e. ‘lawson’) is set when you install LSF9, and can either be changed via ssoconfig or from Lawson Security Administrator.

If you decide to bind Lawson Portal to another LDAP (for example, Active Directory), the password for each user’s SSOP is the one which is verified via ldapbind. This means that–for Portal users–their password is the same as the one from Active Directory.

Now for the Tricky Part

For batch/LID users, there is an additional required identity-which can be an Active Directory user if you’re running LSF9 on Windows-for the OS/environment. The password for this identity is stored in Lawson’s LDAP-but cannot be bound to Active Directory. That is because, in order to perform LDAP binding, Lawson needs to know the actual value of the password so it can login that user “behind the scenes” into Windows. During batch job submission, a user does not specify his/her password anywhere; hence, Lawson needs to get it from somewhere.

The 8.x Environment handled this problem in a rather elegant way-by capturing your password when you logged in via LID and storing it-encrypted, of course-in the registry. Which explains why you would always have to login via LID before running a batch job. In addition, the 8.x Environment also provided an override for Portal-only users who needed to run batch jobs: the RUNALL/RUNUSER/RUNPWD feature in lajs.cfg. The administrator used this feature to specify a default username/password to be used for running batch jobs if the user’s login failed when submitting the batch job.

Now, fast-forward to LSF9, where this feature does not exist, and for a Windows environment it is a step backwards. Since the usernames/passwords for the Environment/OS service (required for LID users and batch jobs to run) are stored in Lawson’s LDAP, they somehow need to be maintained and synchronized.

Although the SSOP service can be bound to Active Directory for authentication, there is a SIGNIFICANT maintenance (and of course, security) issue for updating the Environment/OS service usernames/passwords in Lawson’s LDAP, particularly if your organization uses stringent Windows-based password expiration.

Some Workarounds

• The users themselves can update the passwords, using the Lawson-provided SSO ‘User Attributes’ pages:
• One solution Lawson recommended is to use ProcessFlow to synchronize the passwords. It simply doesn’t work. I’ve tried it, and when I opened a case with Lawson, the response was “Password is not an available attribute for a Resource Query. Remove the password from your Resource Query and try it again.”  Uh, thanks.
• Another Lawson-provided alternative include perhaps loading .xml files (via ssoconfig) or .ldif files (via ldapmodify) from a client’s AD-not a solution for Active Directory, because you can’t extract passwords. For other LDAPs, perhaps it’s still a solution–but it’s still high maintenance.
• You could set up user accounts-to be used only for batch jobs-on the local machine (or Active Directory) with non-expiring passwords. Only the Lawson administrator(s) would know about the accounts and manage the passwords, and it would require no involvement on the part of the users. Still doesn’t solve the problem for LID users.

A Plea for a Solution

To borrow one of my pet phrases: “The world does NOT revolve around Lawson”.  Active Directory is the industry standard, and for Lawson to “force” the clients to use Lawson’s LDAP for anything other than LAWSON resources is a recipe for failure.  Try telling any IT professional that they have to store their users’ OS passwords in Lawson’s LDAP, and it’s a serious “showstopper”.

I realize that this is a tough problem.  I had originally hoped that Lawson could somehow solve this by allowing you to use ‘ldapbind’ for services beyond SSOP (e.g. so that you can bind the Environment service to AD for authentication), but I don’t think that’s possible.  Maybe they could prompt for a password when you submit a batch job and store it in the registry.  Maybe the answer is to bring back the RUNALL/RUNUSER parameters.

All I know is that this is a serious issue and it needs a solution.