As400 practice for concurrent session per userid

In our as400 hardening doc, we currently allow 3 concurrent sessions per userid but our HQ new generic security policy recommends 1 session per Id

Was told that a user will require to run different types of jobs concurrently and often the jobs can take a while to complete even in our upgraded faster system I os400 v7 r2

What’s the practices out there?

CIS does not publish any hardening guide for os400
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Gary PattersonVP Technology / Senior Consultant Commented:
Here are general thought behind the "one interactive session per user" rule:

  • Allowing unlimited concurrent sessions per user certainly poses additional security risk - for example, once compromised, a large number of sessions could be used to launch a denial of service attack.
  • If a user is only allowed a single session, chances of unauthorized profile use is reduced, since unauthorized access if more likely to be detected by the user.

Is an exception to general security policies warranted in this case?  Perhaps.

It is a bad system's management practice to allow users to run long-running jobs like this interactively.  Big jobs should be designed to be submitted to run in batch, where they don't lock up a user's interactive session (and can run in an environment that is tuned for large batch jobs, instead of small interactive workloads).   But maybe these applications, for some reason, don't t support batch submission.  If that's the case, it sounds like the business cost of enforcing a standard "only one session for everybody" rule could be fairly high, and have an impact on the ability for the employee to do their work in a timely fashion.  

If I was the security administrator, and the business need was adequately documented and approved by management, I would have no qualms allowing selected users to have more than one session when it was justified - with a recommendation that alternate methods of running the jobs in question be explored to see if the need could be eliminated in the future.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sunhuxAuthor Commented:
thanks very much Gary.

I did discuss with our AS400 lead admin the possibility of granting only selected users 3 sessions per AS400 ID but we currently have about 80 such users and there will be more to come ie there is overhead on the AS400 admins part:  I guess to balance it off between security and overheads, I might need to opt for this rather than the current setting which globally permit 3 sessions per ID.  We have about 500 AS400 users currently.

You're right that the applications don't allow batch jobs to be submitted.

I also asked that for those users who need to run different types of jobs concurrently, can we create 3 different AS400 IDs : what's your view on this?    Say if user John needs 3 sessions, he will login to JohnID1, JohnID2, JohnID3 and this will probably enable unauthorized accounts use to be detected better?
Gary PattersonVP Technology / Senior Consultant Commented:
I'd think that managing multiple user identities for a group of users would be much, much worse than than managing multiple device access.  

Best security practice is for each user to have one and only one unique identity (with the possible exception of system administrators, to provide a less privileged "daily use" user ID, plus and admin identity).  Once you create all the extra users, you have to manage them.  You may have to add these users to application menu systems or internal application authority tables.  Each user now has 3 passwords to track.  If an employee terminates or changes jobs, you have to somehow know that this is a special "3 profile' user so that you can take appropriate actions.  If you restrict storage utilization on a per user basis, what do you do with these people?  Allow them to use triple the storage of other users, or divide the storage allocation in three parts (which could cause problems with jobs that might need to temporarily use a larger chunk of storage?  Spooled file output is now going to be spread out over three profiles - a significant inconvenience to the user, who now has to remember which profile was used to create a particular report in order to find it and view it.   Applications may log user activity, and it might be confusing to others to see the same person represented by three different profiles - or, if it is occasionally necessary to search in an application by employee - again, confusing and complex to have to know that you have to do three searches if it is a member of this group of users.  Finally, your applications simply may not support the idea of one user utilizing multiple IDs.  For example, some applications save temporary tables, data, or documents based on the user who created them, and trying to access these resources in another session only works if the user is signed on with the same profile.  Even if none of these are restrictions today, they could be tomorrow.  Sometimes an IBM i user profile is associated (formally or informally) with a profile on another system (though EIM or just through naming convention) for folder sharing or other data interchange purposes.

Not sure how the "3 device" limit is currently enforced, but the most common approach would probably be to use the telnet exit point program (or a package that manages exit points, like HelpSystem's Network Security tool).  If that is the case, it shouldn't be very hard to set up a group that needs multiple device access, and to manage users by simply adding them to that group.  I've written code to enforce session limits for telnet connections in the past, and it wasn't very hard to implement or manage.

That said, since you have a significant population that needs multiple device access, my vote is to simply acknowledge that the "one session per user" rule is good general security advice, but that in this case, since a significant % of users require multiple device access due to the architecture of the current application and due to business requirements (document specific requirements), that restricting concurrent access to three sessions is the most secure option that can be implemented without significant changes to the application or to existing business practices.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.