*ALLOBJ and *SECADM

[BeatrixKiddo]

Checking a system for other users besides QSECOFR that would have the authorities *ALLOBJ and/or *SECADM I found these accounts:


MANTUSER *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL

ORO *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL

QEJBSVR *ALLOBJ *SECADM

QLPAUTO *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM

QLPINSTALL *ALLOBJ *IOSYSCFG *JOBCTL *SAVSYS *SECADM

QOTHPRDOWN *ALLOBJ *SECADM

QPGMR *ALLOBJ *JOBCTL *SAVSYS *SPLCTL

QSYS *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL

QTIVROOT *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL

RBTADMIN *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL

Should I consider it a security concern?

 

[tcsbiz]

Anything starting with a Q is usually an IBM object. I'll check our system for those and tell you what we have. RBTADMIN may be for a product called Robot by Help Systems. here's their link

http://www.helpsystems.com/

. If it is that, I wouldn't be concerned.

MANTUSR and ORO: It depends on who they are. Are they real people? Do they log in, and, if so, should they have the rights.

 

[jmd0252]

the RBTADMIN is for the "robot" software,, all the userids listed have the potential for problems, if someone is smart enough to logon using them, what menu do they take you to, and what do they allow you to do. Like Qsecofr if someone uses that,, you have to evaluate, why they use it, how password security is defined, ie length of password, expiration, all the factors that goes into it. Security starts simply,, and gets very complicated.

 

[tcsbiz]

I checked our system and we have all of the Q users. I don't know that you have to be concerned with them.

 

[BeatrixKiddo]

My concern cames from the fact that some of the accounts couldn´t need to have authority over all objects just group of libraries and that somebody forgot to remove the permissions after the system was installed, making them a potential security risk.

In case the accounts are disabled or set *NONE password; could they still being a potential problem?

 

[jmd0252]

If they are disabled,, then they cannot be used to signon, until "enabled". It all depends on who knows hows to enabled the userid. Not many people should know how to get to a command line and do a wrkusrprf *all,, if they can do that,, then they can change anything.

 

[tcsbiz]

There are two other parameters you can look at on a user profile. They are INLPGM and INLMNU. If INLPGM is blank and INLMNU is set to *SIGNOFF, no one can log on with that profile.

Your concerns about forgetting to reset or disable a profile are valid. The AS400/iSeries/System i/i5 grew up in an environment of small shops where few people were available for admin purposes. The security environment in some of these shops can be pretty lax. The platform has poor built-in security management, too.

I remember working at a company that literally had all terminals set up to log in without a password with QSECOFR rights. The owner stated that he trusted his people and there was no need to lock it down.

 

[BeatrixKiddo]

Is it possible to sing on with an account and then change to another user like in unix?

 

[tcsbiz]

No. Once you sign on as one user, you can start another session and sign on as someone else if you know the password. But, you can't sign on and then look like you're another user in one session.

 

[BeatrixKiddo]

In case that an account will be only used to change passwords for users with access problems, I understand that it needs *SECADM but does't need also *ALLOBJ?

 

[jmd0252]

no not necessarily,, depends on what the userid is used for.

 

[BeatrixKiddo]

Only to reset/change passwords,

 

[jmd0252]

you should be fine,, maske the change and test bada-boon,, bada-bing.