Securing Development Utilities LSF9 Security

Check out the ENV (Environment) security profile. Most if not all of the tools and utilities are included there.

Also remember that if user's security profile has that CheckLS=Y, then they cannot use LID for application program access, i.e. they cannot use LAPM. That's why you are seeing that message...That is the reason for using LS Security is so that they have to use Portal (not LID) for program access such as HR11, AP10, PO20, etc. Remember too that system admins with CheckLS=Y, yes they still can use LID to do system-related tasks.

tmcontrol is not in there.  Can it be added to a group like development utilities?

Sure try it out and let us know how it goes.

It worked, but I was not sure what other issues to expect.

Silly question: How did you add it? I'm trying to do the same thing here.

tokendef

There are several utilities that have historically not been added to GEN\EXECUTABLE (aka 'tokendef') that should be for security reasons.
Depending on your release level, you may find that ssoconfig isn't there.

I'll see if I can dig out my full listing over the weekend.

We are using LS 9.0.1.11 for users but not developers and I am trying to move developers in preparation for Infor 10 upgrade.

When using CheckLS=Yes for a developer, we can add a new pgm using pgmdef, but as soon as we leave pgmdef and then return, we get a security violation.  Is there anyway around this or do we have to grant access for each custom program we develop immediately?

In laua, the creator and those members of their security class automatically have access? 

LAUA security model is 180 degrees from LS. LAUA you get default access to everything and have to take things away that you don't want the users to have access to, whereas in LS you have to add things that you want the user(s) to have access to... by default they do not have access to anything.