Troubleshooting User Access Issues with Lawson Security: Overview

This section provides a general overview of the steps that you, as a security administrator, would perform to troubleshoot a problem.

User setup issues

When you receive a report of a problem with a user's access to the system, review the user's attributes and security policies to answer the following:

Does the user have access to all required services and agents. For example, if the user cannot access the Employee Self-Service application, does the user have an identity on the EMPLOYEE_ProductlineName agent?
Does the user have access to all roles he or she should?
Do any of the user's roles conflict?

If a user is assigned to multiple roles in which security classes conflict, the user might have access that he or she should not. For example, if one of the user's security classes denies access but another class grants it, the user will have access. (That the most lenient rule always wins is an underlying behavior of Lawson Security.)
Is the correct profile assigned to the data source?
Are any rule overrides in place for a security class that could conflict with other rules?

If the user has many roles and / or rule overrides so that it is time-consuming to review them all, try comparing the user's access against that of a similar user who is not having a problem. The differences between the two users could point to the problem.

Security system reports

Lawson Security system reports are useful tools in determining where a user access problem might have occurred. In particular, the User Security report provides some useful information. Depending on the problem, the RM User, Role-User Assignment, and other reports can also help.

For more information, see the section "Lawson Security Reports".

Server log file (lase_server_#.log)

Typically, setup errors and conflicting rules are the causes of user access problems. When you need to troubleshoot a problem, it is always best to start by reviewing a user's access through viewing it on-screen in the Administrator or by running a security report.

When you need to dig more deeply into a rule, the Lawson Security server log file can provide helpful information. Here is an example: Suppose a user has been denied access when he or she should have been granted access. In your troubleshooting, you have reviewed the securable objects that the user has been assigned; they are correct. Your review of the conditional rules that have been assigned to the user does not indicate a problem. In this situation, you can use the log file to go to a deeper level.

For more information, see the section "Working with the Lawson Security Server Log File (lase_server_#.log)".

Memory caching

Depending on your settings, caching can make security rules seem as if they are not functioning as intended.

When you make a change to a security policy (for example, create or edit a rule and assign it to a security class and role), because of caching, it takes a number of minutes for the change to take effect. Depending on the type of change you have made, the cache time can be configured.

Security problem examples

Following are the kinds of user access problems that you, as a security administrator, might need to troubleshoot.


Problem	Things to check
A user complains that he or she cannot access a Lawson form or other securable object.	Check the user's setup by reviewing the user's access via the Administrator or running the User Security report. Check the log file (lase_server_n.log); make sure the log file is set to track the user.
A manager complains that a user has been able to access a form or field that he or she should not have access to.	Same as above. In particular, look for rules that conflict. Remember that a rule that grants access always wins.
A change you made to a user's status, for example, assigned access to a security class, has not taken effect when you test the user.	Again, check the user's setup, and, if necessary, the log file. Also check how much time has elapsed since you made the change. Depending on how caching is configured at your site, the delay might be normal. (You can change caching parameters if you need to. )
A user is unable to access a specific securable object (product line, system code, program, form, or field).	Check the user's setup and rules specific to the securable object. You can do this by reviewing the user through the Administrator or by running the User Security report. Because access can be granted or denied at the field level and with conditions (for example, "grant access to this field if this condition is met, else deny"), a user could have access to a Lawson product but not to a specific part of the product he or she needs. Check the log file, if necessary.
A user reports that an online form denies him or her access to an action (inquire, next, add, change and so on).	Same as above.
A user reports that a drop-down field has no records to select from.	Same as above. Also, make sure the user has access to the required table.
A user cannot perform an add or a submit for a batch job.	Check the user's setup and, if necessary, the log file. Batch job users have additional requirements that do not apply to online-only users. In particular, make sure the user has a unique identity on the environment/OS service.
A Lawson Addins for Microsoft user cannot run the product.	Check the user's setup and, if necessary, the log file. Addins has additional setup requirements. For more information, see the section "Lawson Addins for Microsoft User Requirements".
A security administrator does not have access to the Lawson Security Administrator or actions within it.	Check the administrative user's setup and, if necessary, the log file. Security administrators can be designated as "sub-administrators" meaning that they can be denied access to functions of the Administrator or to the Administrator itself. For example, an administrator might be allowed access only to the Resource Management Administrator tool, not the Lawson Security Administrator. Or, an administrator might be able to create rules but not edit profiles or roles.