EMSS with LSF 9 Security

There's plusses and minuses to moving to LSF9 security for Self-Service and anything else too.

The plusses are that you have many more options for setting up and configuring security as compared with LAUA. Example (just one example): you can set up ROLES in LSF9. I would check out the document "Lawson Administration: Resources and Security" for a good explanation of some of the particulars on LSF9 security. Also the auditing and reporting capabilities are much much better.

Minuses (just a few): The learning curve you will have to spend time with understanding LSF9 security, and how to set it up for ESS/MSS for your employees. But once you understand it and are comfortable with it, I think you should find it much better than old LAUA/RD30 websecurity.

We had no problems with the "inherited" ESS/MSS security while on 8.03, but when we moved to LSF9 our LAUA security classes started overriding the priviledged identity and Finance application users who did not have full access to the HR suite started getting security violations in ESS. When we called Lawson they said this is the way it should have bahaved all along which was no consolation and the work around was to define 2 seperate user id's. Does anyone know if this is still an issue in LSF security?

Interesting... what do you mean "LAUA security classes started overriding the priviledged identity ..."?

Did you set up and connect the privileged identity to users correctly? BTW there is a limit on how many user IDs you can connect to a privileged Identity. I think that limit is 1000 users. So if you have, for example, 1500 users, you would need two separate privileged identities, the 1st one for the 1st 1000 users, and the 2nd one for the other 500 users (plus future new hires, etc.).

As I understand it, a particular login id will use either the assigned security, or the priviledged identity.  They are not merged or combined if that's what was expected.

The limit of 1000 users for a privileged identity was removed in one of the environment service packs some time back.

Lawson didn't explain it this way, but I'm thinking the problem lies with the fact that on Env 8.03 we had no bind to AD for Portal users. Our users were all LID and the RD30 record for ESS/MSS users (whether they were application users or not) was set to use the priviledged identity. When we moved to LSF9 and bound it to AD, the users actual identity was imported to their environment key in Manage Identities so ESS is appllying their LAUA security rather than that of the Priviledged Identity. Our non application users of ESS have no value in the environment key in Manage Identities.

Joe, going back to what you mentioned that LAUA security is being used instead of LSF9 security, in the user security records within Security Administrator, is the CheckLS button = Y or blank? It's got to = Y to use LSF9 security.

Sorry Roger, maybe I didn't explain it clearly. We're not using LSF security and everyone's Checkls flag is set to N. It's just the behavior of LAUA security for application users in ESS that changed since the move from 803 to LSF9. I'm pretty sure my last post about the environment key in Manage Identities is the reason why, but if anyone has a different theory I'd be interested in hearing about it.

Your application and non-application users of ESS, if those two groups both log into Portal, must have an identity for the Environment service. If any of those users are using a Priveliged identity for anything, then that Privileged identiy must also have an Environment key.