Tweet
Usually admin's set too many people with too high authority for one of these reasons. 1. People feel important if they have secadm or feel they have been slighted if they don't. 2. People are having problems not being authorized to certain objects, sometimes ones that the system creates or processes create in the background. The admin, not having the time, or maybe not the knowledge, fixes it the easy way: give everyone *secadm.[*]*********** To fix this: You should duplicate a profile to test with. Remove *secadm. Then see what blows up. Then you start the possibly long process of straightening out object owners, adopt authorities, authorization lists, etc. -dan
-
-
Looking for limiting users authority...
If all you do is change their user class then your users will still be authorized to do what ever they could do before the change. The thing that really matters is the special authorities of each user. By default a user profile with *SECADM user class will have *ALLOBJ and *SECADM special authority, but that authority does not need to match the user class. Any user with *ALLOBJ and *SECADM can directly change any user profile (including QSECOFR) and its password. Any user with *ALLOBJ can also do that but they may need to do it from a program or a submitted job. Ed Fishel -
Looking for limiting users authority...
Before making any changes, I would recommend creating some sort of security plan, and getting approval from management. All the way up to the top if possible. Speaking from experience, as soon as you remove *SECADM, you will be getting calls from users who "Cannot do my job!". You will probably have to create programs which adopt authority to satisfy them. Also, depending on the system level, make sure users do not have authority to profiles with *SECADM or *ALLOBJ. Otherwise if they have the command line (programmers!) they can simply submit a job under that profile and do whatever they want. Good Luck!Comment
-
Looking for limiting users authority...
Thank you guys. I have been reading some documentation and I will go slow, just in case.Comment
-
Looking for limiting users authority...
Please pay attention to what Ed Fishel stated earlier. It is not the user class that gives users the capability to do something - it is their special authorities The user class is used for two things - defaulting the special authorities when the profile is created and determining what menu options are displayed on IBM menus only (not application menus - IBM menus.) You can have a user be in the *SECADM user class with no special authorties. Or a user in the *USER class with all special authorities. Your concern should lie in what special authorities they have, not what user class they are in.Comment
-
Looking for limiting users authority...
I've been reading replies to questions regarding user security ,and you mentioned *ALLJOB authority ,that programmers can submit a job under that profile , did you mean anyone's profile ? WE had a problem on our AS400 where users were not able to view JDE menus after logging in ,a message appeared "The QJDF data area is in error" and will revert back to the login screen .We found out that a JdEdwards group profile {JDEGRP} was disabled .WE enabled the group profile but that did not fix the problem until we added special authority *ALLJOB to the group profile . Is there another way to give user access to their menus without giving the group this special authority *ALLJOB ? Also could a user in a group with *ALLJOB and not have *SECADM disable a profile ,is this user invisible to auditing ? ALL response is welcome , ThanksComment
-
Looking for limiting users authority...
We recently had a problem with JDEdwards, users could not view menus. We found that a group profile JDEGRP was disable .We enabled the profile but still users could not view their menus . We then added special authority *ALLOBJ to the group profile , this worked . Our concern is can anyone submit a job under any profile in that group and do whatever they want ? We are not sure if this profile,JDEGRP had always been configured this way . ThanksComment
-
Looking for limiting users authority...
It's common for ANY Group Profile to be disabled. This does not affect your ability to assign that Group to Users. It only prevents Users from signing on with that Profile.... Something that you wouldn't want them to do, since they have their own individual User Profile. We also have JD Edwards and our Users are a member of a Group as well. The Group is also disabled and neither the Users nor the Group nor their Supplemental Groups have *ALLOBJ Authorities. So I think the source of your problem lies elsewhere and you should continue looking into this. I don't think giving *ALLOBJ to your Users is a good alternative. And when you say that they cannot view their Menus, do you mean JDE Menus or other menus? I don't think that JDE specific security has anything to do with this problem. But if you're new to JDE Admin I do have some Documentation that might help. While we're on the topic of JDE.... I'd like to see an ERP/JDE Forum. Anybody out there interested? How does a new Forum get started?Comment
-
Looking for limiting users authority...
A user that has *ALLOBJ special authority from one of their group profiles or from their own user profile will be able to submit a job that can run under any user profile on the system. This includes user profiles that are disabled, but does not include a few system supplied user profiles like QSYS or QSPL. You should be very careful who you allow to have *ALLOBJ special authority. Ed FishelComment
-
Looking for limiting users authority...
Must have missed the original post. This is how QJDF is setup at our shop. JDEUSERS is a Group Profile used as a supplemental Group for our users. Try giving your JDEGRP *USE Authority and see what happens.
CodeComment
-
Looking for limiting users authority...
I recently "inherited" iSeries administration tasks and while reviewing the existing user profiles I found that a significant quantity of them have User Class of *SECADM. I do not think that any "regular" user should have a class greater than just *USER but I am afraid that if I start changing them to *USER class, problems will start to surface. I would like to change all "regular" users to *USER class. Here are my questions: Can anyone advise me on the possible consequences of doing such change before it take me unprepared? Is there any valid reason for the previous administrator to set them with *SECADM? Thanks!Comment
-
Looking for limiting users authority...
Just disabling a Group Profile is risky at best. To ensure these profiles are NOT used to sign on with, set the password to *none, Init. Program to *none and Init. Menu to *signoff.Comment
Comment