Most System i administrators have left the system value QLMTDEVSSN(Limit Device Sessions) as it was shipped by IBM. This system value, as it is shipped, specifies that a user profile can be signed on to multiple concurrent workstation sessions. Prior to i/OS 6.1 the only other option was to limit a user to one workstation session at a time.

From a security standpoint, this ability to have the same user profile signed on concurrently at multiple workstations is a real problem. It allows for password sharing and disregards the accountability required to tie a particular person to an action. (e.g. Who updated that record? or Who deleted that file?) Those of you that have worked with your internal and external auditors know that they do not like these 'generic' user profiles or shared passwords.

It has always been a sound security practice to set this system value to limit users to one workstation session at a time. But, if you are like me, there are many times when you need to have multiple concurrent sessions to the same system. This is not uncommon for programmers and other IT technical staff. It has always been possible to override the QLMTDEVSSN system value at the User Profile level, so that you could set the system value to be restrictive, and then set individual user profiles that need multiple concurrent sessions to be non-restrictive.

In i/OS 6.1 the system value has been modified so that now you can choose another option. Now you can specify how many concurrent sessions a user can have. You can also use this new option at the user profile level when you need to override the system value for an individual user.

The allowable values for the system value are:

• 0 – No limitation on the number of sessions (Default)
• 1 – Users are limited to one session at a time
• 2-9 – Specify the maximum number of workstation sessions from 2 sessions to 9 sessions

So, now you can limit a programmer or other IT staff to 2 or 3 concurrent sessions, without opening up the system value for an unlimited number of sessions.

I suggest setting the system value to 1, to limit all users to one session at a time, and then, when there are exceptions, handle those at the user profile level by overriding the system value.