LawsonGuru Blog

Thought-Provoking Commentary for the Lawson Software Community

Lawson SSO…or SOS?

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.


12 responses to “Lawson SSO…or SOS?

  1. Eric March 18, 2007 at 10:08 am

    Perhaps Lawson should bundle software with the Windows based LSF9 solutions.

    This is not “simpler”, its more complicated!!

  2. Alex Wolff March 27, 2007 at 10:14 am

    I am not sure I understand the problem completely. For portal/batch users there is no need to provide an OS password on UNIX. A valid password is only required if the user intends to use ‘lawson terminal’ (the web enabled telnet client which in my opinion is useless). I simply create the UNIX account but leave it locked (i.e. do not specify a password).
    Then just create the OS identity in LS for each user but specify a dummy password.

    For LID users (we do not have any except admins) we stick to LAUA security. I am thinking the next major environment release will not support LID at all.

  3. John Henley March 27, 2007 at 10:14 am

    If you’re running on Windows, you need an OS identity to run batch jobs via Portal, or to use LID.

    Unlike Unix (where you can have an account the user doesn’t see with an unexpiring password), the OS identity must be a valid Windows account, either set up on the local machine or via AD.

    If it’s an local machine account, you’re duplicating each account (setting up the user in AD as well as on the local machine).

    If it’s an AD account it CANNOT be bound to AD, which requires that the security administrator KNOW THE USER’S PASSWORD.

    This is a step backwards for Window’s clients.

  4. Christos Toyas May 9, 2007 at 10:14 am

    Hi – i ve been looking to this article and i have some comments, the env identity password is retrieved by lawson and used to do a kind of runas on windows to do a jqsubmit (and only on windows). SSOP binding makes total sense because it picks up the password you enter in the login screen and uses it to use ldap binding mechanism – this is a strict ldap operation and encryption/decryption for comparison is performed by the target ldap itself. For Environment identity it is not a direct authentication process happening it is used as part of a command line utility so how would you want to use binding mechanisms ? unless lawson knows how to retrieve the password from a third party ldap and perform the decryption and use it in a command line i am not sure how this is possible. To do that Lawson would have to plug third party APIs and cert trust keys.

  5. John Henley May 9, 2007 at 10:15 am

    After studying this some more I realized that simply making ldapbind work for the env identity wasn’t the solution, since Lawson would have to still store the password *somewhere*. Particularly with AD, since you can’t reverse-encrypt the password except via a brute-force attempt (which obviously isn’t a solution!).

    Therefore I think the only feasible solution is to re-introduce the ‘runas’ parameters into lajs.cfg which where dropped in LSF9.

    I have an updated copy of this article:

  6. The Creeper October 20, 2007 at 12:05 am

    This is all very scary stuff

  7. Shannon Wm. Fleming April 1, 2009 at 10:03 am

    Check out KB articles 1098772 and 5224169. They talk about setting up a privileged identity for submitting batch jobs. This allows you to designate a single windows user (with a non-expiring password) to submit all batch jobs. The system administrator can enter this password into LSA. Ideally the password would be sufficiently complex to appease the auditors. Caveat: You must be on LSF

  8. Joe Fanuke May 21, 2009 at 11:54 am

    The Priviledged user is a great idea, just be careful with that one…

  9. Stuart August 12, 2009 at 5:44 pm

    I refined a batch job parameter control system for a payroll user who had a tight window and couldn’t afford mistakes. Jobs were setup with automatic parameter updates for such formula driven items as deduction cycle, check date and so forth.

    Part of this was a screen from which “submit” actions proceeded. This was a unix implementation, so the windows “id” issue wasn’t there, but a rejected proposal was to have a “submit” request update a database table, and have a dedicated batch user account execute requested jobs on a schedule…looking every couple of minutes for new requests. This was to allow a user to request a multi-step batch job for which they did not have individual program access for all of the programs in the job…which may have included file ftp steps and such other utility functions.

    This dedicated user would not necessarily need to ever log on, as job reports would be distributed to groups of interested users.

    Perhaps this could provide a framework around which to build a work-a-round…

  10. SB March 25, 2011 at 4:31 pm

    Newbie to this whole process of working with Lawson and Self-Service.

    Had a question about this LDAP bind and why some employees can log into their portal, but others can’t and have to change their passwords. I’ve been told that Lawson cannot ‘sync’ with the passwords used to access email or what’s on directories – can someone provide info on this?

  11. Dana March 1, 2013 at 10:13 am

    We are trying to integrate Siteminder for SSO with Lawson 9.

    Any information about the integration would be appreicated

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: