TOKENDEF Custom Menus

Can anyone on Lawson v10 confirm that TOKENDEF custom menus and user defined options are still available in LID? My reading of the documentation is that they are as long as no Lawson forms are called. We want to continue using LID to run UNIX scripts via TOKENDEF menus and user defined options.

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

sean-howlin

Good morning cjandrle - yes, TOKENDEF user tokens are still available in LID. Even better, they are very easy to migrate from one system to another (dmpunivtkns ldunivtkns). If you are migrating from a Unix to Unix platform, I'm guessing these will work just fine for you.

Our business relies heavily on jobs that call user defined tokens, which in turn call custom scripts process business transactions. All of our AP upload interfaces, GL upload interfaces, and AP ACH processing is completed when users submit a multi step job that includes a call to our user tokens. It's a really big deal around here.

We are migrating from Unix to Windows, with an LDAP bind to corporate AD. Our user tokens don't work in 10x.

Jobs that call user tokens go into needs recovery with the error "Unable to log in user ADusername." This is turning into critical project blocker for our 10x upgrade. Jobs submitted calling native Lawson tokens work fine, so lajs is not our issue.

We have had a case open with Infor support since December 16 (3 months now), with no resolution as of yet.

Here's the deal - in LS9 & LS10, users' environment identities must have their password in sync with their AD password in order to consume user defined tokens.

First, this is an issue in the number of help desk calls we get. Business user phone call: "I changed my password in AD, but now I can't process AP or GL transactions". This is hard on our users and our IT support teams, and gives the Lawson system a bad rap. I hate that because I really like the Lawson apps and I'm the 'face of Lawson' for my company.

Second, Infor does have a workaround in place for this (KB 1198183) that makes use of the sso/useratts.htm program. This is a link that users can call to reset their environment password to sync with their AD password. When I tell my users that this is how they will need to get their jobs to work, their response is "really"? They didn't have to do this in 9x Unix. I have to admit I agree with this. There are some ssoconfig updates to make to get this to work, and we have the useratts.htm configured, but it's not working just yet, so we cannot deliver this workaround to our business.

We are still waiting on a resolution that will allow our users to successfully run user tokens and complete their 10x test scripts so I can get my project sponsor to sign off on go live in May. My fingers are crossed.

unknown

Thanks so much for the response. Yes, we also depend heavily on user defined tokens that call UNIX scripts for a lot of business processes. Fortunately, we are migrating from UNIX to UNIX.

When we switched our users to new security (CheckLS=YES) which prevented their use of LID, we created a second UNIX user ID for those who needed to run scripts. They use their AD user ID for Portal and this second ID in LID gets them to an initial custom tokendef menu with their custom tokens.

sean-howlin

The two ids is a great process - use are doing the same in our current 9x unix system. Wishing you a successful 10x upgrade....

todd-brown

We too use custom tokens, but Im a little confused when you say, "...users' environment identities must have their password in sync with their AD password in order to consume user defined tokens. " Are you saying that the OS account password must match the AD account passwords.

We are in the process of binding our Production system to AD in the next several weeks.

Are setup is at little different. We have 'batch job users' if you will. Users setup to run our scheduled jobs and thats really it. They do not log into Portal for anything. For example we have a user 'MMJOBS' to run all our material management jobs/scripts. So these users are LS=no users. So we do not have these users in our AD system.

unknown

We also have similar batch job users to run all our scheduled jobs. They are never used to log into Portal or LID and are not in AD, however they are CheckLS=YES. This is in addition to the users which log into LID to run UNIX scripts from TOKENDEF custom menus. They also are not in AD.

sean-howlin

Hi, Todd. No, not the OS account password; the environment identity password is not quite the same as an OS password. In fact, non of our users have an OS password as we don't setup app users with an OS login. Similar to your MMJOBS login, we have a batch privileged user setup on the server that is configured to run lajs batch jobs (defined in the latm.cfg file). This is most likely what we are all using as that is what is supported for 9x & 10x installations).

In 10x, we now use the ISS security tool for user provisioning. Within ISS, you setup your user account with an environment identity, and supply a password for that account. It looks pretty similar to how we do it using the LSA tool in 9x. (in 9x you open LSA > users maintenance> right click on 'manage identities' - see that password there? Yep, that's the one. We now manage that in 10x using ISS. That env identity passwd is the one that needs to be synced to the AD passwd to run user tokens.

Hope this helps!

sean-howlin

he he...I said latm.cfg. I meant lajs.cfg.

todd-brown

Yes, that helps. You said that in your 9 Unix environment you don't have unix accounts for your apps users?

VID004_ICZSU_Simple Setup with Custom Calls.zip

sean-howlin

Sorry if I was not clear...

We have OS local unix accounts setup for users in our 9x unix system.
In Windows 10x, we do not have local OS user accounts.

todd-brown

Ah, okay. Thanks

unknown

Marilyn,

I've been using LS9 for some time now, But I don't understand how the PRODENV passwd can be synced with AD, when the User changes it (in our case that's every 60 days); our Users will be very 'LOATHE' to give us their passwords to update manually - or is this automatic in 10/ISS?

sean-howlin

Unfortunately, it's not a true sync from a technical perspective. The useratts.htm is a manual process driven by the user as a secondary password change when they have to change their AD password.

So, every 60 days, I would have to change my AD password, then also click a link to the useratts.htm program and set that password to be the same as my new AD password. This prevents us Lawson admins from having to know their AD password. I'm loathe to know their AD login info, too.

mbozenik

On the unix side you should be able to bind the unix logins to AD using PAM-Pluggable Authentication Modules. I know it works for 90 Lawson LID accounts. That way both your Lawson and Unix accounts authenticate to AD. Just something to consider.

asztudenyak

Marilyn, I find it interesting that you can even get the manual synch to work. We have had this problem ever since we went to 9.0. Any user that submits a job that calls a script (a few payroll jobs that submit check or dist files to our city server via FTP) fails, with that same login error. We have had them come to our desks, and manually change their identity password in Lawson Secuity to match their AD password. Doesn't matter...still get the error. We simply have to run the jobs for them, and have been having to do this for years now. It is very frustrating, and I wish there WAS a way around it. But changing their password does not work for us.

[Updated on 3/13/2015 12:10 PM]

sean-howlin

C. Brunelle - that is interesting. It makes me wonder if env identity management works better in LS10 using ISS than it does in LS9 using LSA.

asztudenyak

Well, we still are on LAUA for security classes - we've not migrated to LSA yet (other than the required RMID and identities). So I was hoping this issue would be resolved when we get there.

sean-howlin

Quick update on user tokens in 10x:

We have been unable to get the useratts.htm program to work in our 10x test/prod environment. At this point, none of our user tokens migrated from 9x to 10x will work for our users. This has turned into a critical block for our 10x upgrade project.

Infor has confirmed there is an issue with using the sso/useratts.htm after federating LSF with Landmark.

There is a JT submitted for this issue - JT-751295 (P2). If you are interested, please see KB# 1605716 for more info.

Regards,
MCS

Copyright © 2025 Infor. All rights reserved.