Comments on: Lawson SSO…or SOS?

By: Claude

Claude — Thu, 08 Dec 2011 16:23:57 +0000

SB,
You need to setup a privileged identity for Online if you have not done so already.

By: SB

SB — Fri, 25 Mar 2011 20:31:42 +0000

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?

By: Stuart

Stuart — Wed, 12 Aug 2009 22:44:07 +0000

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…

By: Joe Fanuke

Joe Fanuke — Thu, 21 May 2009 16:54:18 +0000

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

By: Shannon Wm. Fleming

Shannon Wm. Fleming — Wed, 01 Apr 2009 15:03:10 +0000

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 9.0.0.4+

By: The Creeper

The Creeper — Sat, 20 Oct 2007 04:05:37 +0000

This is all very scary stuff

By: John Henley

John Henley — Wed, 09 May 2007 14:15:22 +0000

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:
http://www.danalytics.com/guru/letter/archive/2007-05.htm

By: Christos Toyas

Christos Toyas — Wed, 09 May 2007 14:14:58 +0000

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.

By: John Henley

John Henley — Tue, 27 Mar 2007 14:14:31 +0000

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.

By: Alex Wolff

Alex Wolff — Tue, 27 Mar 2007 14:14:10 +0000

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.