Posts

Security Violation for Activity Group

You may have tried to add a report or update a job recently in Lawson and received a “Security Violation for Activity Group <XXXXX>”

 

Your first solution may be to give the user full rights to the Activity Group form (AC00) and table, but you’ll find that this solution will heed the same results.

 

  1. Check the security class causing the error. It’s likely it was written as an ELM rule (element) based on the Company Element.
  2. If this is true, it’s checking the CompanyControl attribute on the user’s RM Admin setup.
  3. The AC system uses the Security Code as defined on the AC00 (Activity Group) setup and interprets that value as the Company for AC security. By default, the AC00 Security Code is 9999.
  4. Add Company 9999 on in the users attributes as a valid company in the CompanyControl settings.

 

Recap: Because the ELM rule checked the CompanyControl attribute values, this Security Code (Company) value of 9999 needs to be added to the CompanyControl values for the user.

Getting ahead of the EMSS Patch W4 Patch Security Violation

Infor KB 2096388 recently came out this year (2020) updating Employee Manager Self Service.  In doing so it brought with it an added table that users will not have access to. (Also, for that same KB, a recent notice came out on 3/26/2020 so revisit that article for latest info).

After you’ve applied the EMSS Patch for your version of Lawson. Table PRREGPARM will now be secured from ESS users when accessing their W-4 Tax Withholdings.

To fix this, go into your Lawson security Profile:

Locate your Employee File Table access class, most commonly named EmployeeSSFile.

 

Add a new rule to this class:

Choose “Files” under the “Securable Types” drop down. Expand the + sign next to the PR system code. Scroll down and locate PRREGPARM.  Now select  the check box next to the program, select conditional rule access and click edit as shown below

In the Expression builder editor, write the rule closely to the screenshot below (You may not have an Element Group named COMPEMP or may be using a different element group all together). This secures access to the employees own personal information and no one else. Click the Apply button to save the rule.

 

Security Violation – Using Environment Utilities in IPA

Many times, you will have a need to run environment utilities (such as importdb) using a system command node, or a batch job such as IMDBB.  If you are getting security violations when you attempt to use these tools, you will need to elevate the Lawson Security privileges of the user running IPA.  The reason for this is that the system user running the IPA service is who actually is running those system commands.  Windows took away the ability to do a “run as”, so there is no way to bypass that user.

If you don’t know which user is running IPA, you can find out by executing a “whoami” command in a system command node on your IPA server.

Next you need to find this user in Lawson Security so you can elevate his privileges.  Open up Lawson Security and go to Manage Identities.  Search for the service account that you discovered in your “whoami” command.

Make not of the RMID and use that to search for the user under User Management.  Set that user’s “CheckLS” to “YES” and give him the roles required to allow access to the necessary environment utilities.

Why is PR299 failing?

PR299 may not be creating the EFW2 file from a security violation.  The job log can provide more details.  The log in this example shows that it is trying to use cnvtape to create the EFW2 file.  Cnvtape may not be in a security class or even defined in the environment.  Tokendef can be used to add the utility to the list of environment executables in security.  Once the token is available, a rule to grant all access to cnvtape can be added to a  security class like AllENVAccess.  Ensure the class is on a role for the user running the job.  After adding this permission, the PR299 can run to completion.

 

Job log

 

tokendef

 

Security Administrator

Security Violation

When applying a patch to the LSF environment, we saw Security Violation errors on environment utilities even though security was turned off.  In the below example, the error was returned from trying to run ldunivtkns (to load environment tokens) and also on envrelease (to show the environment version.)  This issue was resolved after contacting the network team to replicate file system permissions from an older Lawson server.  While it was not shared exactly which permissions were changed that were not already in place, once the new permissions were applied, the Security Violations were replaced in the logs with the appropriate responses from the commands.

Initial Error

 

Error Resolved

 

Environment Security Settings