Solutions | Kinsey & Kinsey

Frequently Asked Questions

These terms are used throughout the questions and answers:

Term	Definition
LAUA	Lawson User Administration – Lawson security tool that’s been controlling Token access for many years, and which can continue to be used with LSF9.
LSF9 or LSF	Lawson System Foundation – this replaces the previously named Lawson Environment or Universe, and manages Lawson Application Programs, Security, Advanced Technology, and everything else needed for Lawson Software to operate.
LS9	Lawson Security 9 – the new security configuration that allows Lawson clients to use the advantages of a Role-based security model.
Listener	Kinsey’s tool that “listens” to the system and reports on WHEN and HOW users are actually accessing the Lawson Tokens they are authorized to use.
SMP	Kinsey’s Security Migration Process – a collection of procedures and software that automates the tedious up-front analysis and the laborious mouse clicks required to build the thousands of objects needed in LS9.

I understand that specific Table access is required in order for Selection Lists and Drill-Arounds (and Microsoft Add-Ins) to work. How difficult is it to figure out which tables we should include?

It’s incredibly time-consuming, in either LAUA or LS9, to determine field-by-field in each token the tables needed for this. The Kinsey SMP automatically generates this table access. Otherwise, you are welcome to use the free Kinsey web site tool to figure them out – from www.kinsey.com, click on the Machensoft section, then click on the Drill/Select Table Information link on the left, enter your token such as ap10.1, and hit enter. Click here to try it.

How does your Listener SPEED UP the process of moving to LS9 from LAUA?

The listening process takes the place of the tedious task of trying to figure out exactly what tokens a user requires in order to do their job. Depending on the length of time you decide to 'listen', this process may not speed up the migration, but it makes it EASIER to analyze the LS9 build and helps produce a much more accurate LS9 configuration.

What’s involved in LOADING THE FUNCTION CODES for each token – do we have to know every function code in order to grant full access?

LS9’s default configuration is “ALL ACCESS”, which pays NO attention to function codes. In order to dis-allow specific function codes (or to grant inquiry-only access), you have to painstakingly REMOVE function codes one-by-one with at least 2 mouse clicks for each function code you’re removing.

What about granting inquiry-only access? Lawson provides an easy way to do that, right?

No – Lawson says this is the MOST DIFFICULT thing to configure in LS9. We saw this as a huge issue, and we wrote a Kinsey tool included in the SMP (called the Read-Only Task Generator) that automatically builds read-only access for any set of tokens desired.

We don’t trust our LAUA. We have many Security Classes that were cloned and changed in a variety of ways, which has become a maintenance problem. Since we don’t want to use LAUA to start with, CAN YOU HELP US at all?

Absolutely. We suggest using our Correlation tool to see how your Security Classes relate to each other, if at all. The Listener shows which Security Classes are even used, how heavily they are used, etc. THAT provides the information you need to either enhance LAUA so you can use the SMP, or to use as input that shows what to build into LS9. Then, the LAUA/LS9 Comparison tool shows how, user by user, their access will change when moving them from LAUA to LS9.

We’ve committed to setting up LS9 BY OURSELVES or with another consulting company (without using your SMP). Do you have anything that can assist us with that?

Of course. First, pay close attention to your custom programs, if you have some, to be sure they get included somehow. You will probably hear that BLANKET access to tables is recommended for drills, selects and add-ins. If you’d like to be more accurate than that, you’re welcome to use the free tool on our web site, or we can generate the table access needed for your Roles.

These are the Kinsey tools we recommend for this situation (black for LAUA, blue for LS9, red for both):

LAUA Listener – you configured LAUA with the best knowledge available, but how is the access you granted being used? This tool shows you HOW your security configuration is actually being used – by User, Security Class, Token, System Code, etc., with interactive reports that allow you to drill into details or view summarized totals. Note that we also have the LS9 Listener so you can continue to monitor usage after migrating to LS9.
LAUA Access Analyzer – report showing the items you choose, such as, “Who can access HR11, and what Function Codes can they use?”, or “Show me all Tokens this user can see”.
Security Class Comparisons (also called LAUA Class Correlations) compares any or all of your LAUA Security Classes with each other to highlight commonalities and differences between them.
Report of Tokens NOT Used – shows tokens users can access but did not touch during the listening period.
LS9 Read-only Generator – a handy tool to use while setting up LS9 to create inquiry-only tasks (Lawson says read-only tasks are extremely difficult to create manually).
LS9 Access Analyzer – easy-to-use spreadsheet showing all Rules, their Tasks and the Roles they’re attached to.
LS9/LAUA Differences Report – interactive reports showing the Token access, by user, that they had in LAUA but which is now different or gone in LS9.

You said the SMProcess can be completed within 2 months. How many of our personnel are needed, and must they be dedicated to this for the entire time?

You absolutely do NOT need to have anyone dedicated throughout the process. This is detailed in our project plan, but since most of the process is automated, we’ll have initial meetings with your personnel and various checkpoints while going through the process. More time from your personnel will be needed toward the end as we work with you to validate and test the results.

Do you do all of this SMP work on our Production system?

The majority of the work is done on your Test system. The "Listening" phase of the project, for obvious reasons, must be done on Production. From there we’ve found that the best method is to copy security from production to test (that’s easy to do), and we run the BUILD processes on your TEST box. Once you decide that it’s complete and ready, we help you easily copy the LS9 setup from TEST to Production. It STILL doesn’t affect security in production at that point – you can or we can help you switch users over to LS9 in groups or singly, so the production roll-out is as gradual or as fast as you desire.

How does the migration affect our Corporate LDAP?

The Resource Management (RM) part of Lawson Security 9 (LS9) manages users, passwords, single sign-on, etc., and THAT is the part of LS9 that works with the corporate LDAP (via the LDAP Bind). It gets configured when migrating to LSF9, usually separately from setting up the Roles, Tasks and Rules which can be done afterward by the SMP.

Can we continue to use LID after migrating to LS9?

You can use LID for certain Lawson utilities such as the Recurring Job Scheduler (RECDEF), but once you switch a user from LAUA to LS9, the security prevents them from accessing application tokens through LID. You can, though, switch them back to LAUA in a heartbeat if desired.

When using Process Level security, would the SMP create different tasks even if the tokens and tables are identical?

You hit on some of the power of LS9 and the SMP. The SMP would create a single Task for this even though it comes from two different LAUA Security Classes. This single task can be shared among different groups of users, while using Process Level security to keep each group restricted to seeing only their own data.

Will the Listener work for LID users?

Yes. The Listener will pick up usage information for Portal, LID, or Self Service users.