Tweet
As I see it, your problem is that you are using the menu restriction as a band aid approach to correctly setting up user profiles. Menu restriction works fine in your case until you go beyond that, which is what has happened. I would define one or more group profiles that have the correct authority based on job functionality. Then I would assign those priorities to the objects that need to be secured. Finally, remove the global profile from the individual user profiles, and replace those with the correct group profile based on their job function. Another alternative would be to add a green screen menu item that performed the file transfer. You can set up a CL program that will establish a FTP session with a PC and have the files transmitted that way -- the 400 will "push" the data to the PC and remain in control. The data transfer application will not be needed, and you can keep your "security" intact. But I'd still recommend you set up the group profiles based on job function and get rid of the global authority. If it doesn't cause problems now, it'll always be lurking down the road. However, beware: If you set up the profiles and the job functions require a profile to have access to a file in order to delete and create it (i.e. if they can submit a job that includes a REORG), then the file transfer program may allow the user to delete the file. I have used a PC based FTP package. It allowed the user to click on the file to transfer. If the file was highlighted and they hit the delete key on the keyboard, or right clicked and selected the delete option, the file was gone. So, if possible, I recommend setting up the menu option, but realize that is not always possible. Hope this helps. Doug.
-
-
Client Access data transfer Security / normal as400 sign on
our user profiles all reference a global authority profile that has all rights to all libraries. this is great when a user is restricted to menus. however when useing client access data xfr they have all rights to all libaries. if we create a profile with restricted rights to use for data transfer, how do we keep the user from logging into the data transfer application with their normal profile that has all rights? we are looking for a solution that allows users to use their green screen apps but not have global library authority when using data xfr. what about not using the global profile reference in their profiles and just change all the programs to USRPRF(*OWNER)? -
Client Access data transfer Security / normal as400 sign on
You could also write an exit program to verify the user ID etc. before letting the transfer take place. Thisis another bandaid (like cycleman points out), but it's what we did. We can specify a hiearchy of userID/library/object/read/write attributes to allow/dis-allow access.Comment
Comment