Many of us know of the system value QLMTDEVSSN. You can read about it at https://www.ibm.com/docs/en/i/7.5?topic=values-limit-device-sessions-qlmtdevssn
The original intent of that was to stop a user from sharing their logon credentials and having people log on to multiple sessions. However I believe it's been obsolete since the day the first twinax terminal capable of multiple sessions, or the first PC with a 5250 emulator which allowed multiple sessions. I see no need to block someone from being to be in order entry on one session and item lookup on another.
What I am more concerned about is people logging in from multiple IP addresses. Sure there are legitimate exceptions. Receiver logs into a 5250 session on a PC, hits Windows-L and locks his PC. Grabs his 5250 handheld scanner and does that. Returns to his PC, unlocks his PC and returns to work.
But I've discovered people logging into four different IP addresses, and none of these were in the subnet range for our scanners. These need to be evaluated. To find these people is quite easy. Here is some sample code:
-- category: IT Audits
-- description: List 5250 sessions of users logged on to multiple IP addresses
-- T1 summarizes by user and IP address.
-- Multiple sessions with a single IP address are ok. That is
-- just multiple sessions on a single PC.
with t1 as (
select a.job_user,A.CLIENT_IP_ADDRESS
from table(qsys2.active_job_info(
RESET_STATISTICS => 'NO',
SUBSYSTEM_LIST_FILTER => 'QINTER' ,
JOB_NAME_FILTER => '*ALL',
CURRENT_USER_LIST_FILTER => '',
DETAILED_INFO => 'ALL'
)) A
group by A.JOB_USER, A.CLIENT_IP_ADDRESS
order by A.JOB_USER, A.CLIENT_IP_ADDRESS
),
-- T2 summarizes T1 by user so we can limit to only
-- those signed on to multiple IP addresses.
T2 as (
select t1.job_user, count(*) as ip_count
from t1
group by t1.job_user
having count(*) > 1
order by ip_count desc, t1.job_user
),
-- T3 Gets the IP address back but now just for those
-- accessing from multiple IP addresses: where ... in...
t3 as (
select b.job_user, b.CLIENT_IP_ADDRESS
from table(qsys2.active_job_info(
RESET_STATISTICS => 'NO',
SUBSYSTEM_LIST_FILTER => 'QINTER' ,
JOB_NAME_FILTER => '*ALL',
CURRENT_USER_LIST_FILTER => '',
DETAILED_INFO => 'ALL'
)) b
where b.job_user in (select t2.job_user from t2)
group by b.JOB_USER, b.CLIENT_IP_ADDRESS
order by b.JOB_USER, b.CLIENT_IP_ADDRESS
)
-- Final also pulls in the nslookup of the IP address.
-- However many of these are dhcp so the nslookup fails to work.
select t3.job_user, t3.client_ip_address, qsys2.dns_lookup_ip(t3.client_ip_address) as ip_name
from t3
order by t3.job_user, t3.client_ip_address
;
Now, once you have weeded these out and can grow this to handle your exceptions you can take this to the next level. And that level would be stopping them from logging into multiple IP addresses in the first place. One way might be to write a telnet exit point program. This could
- Stop a user from logging in to one IP address when then already have a session at another IP address.
- Simply log this happening to your SEIM so you can follow other procedures.
See also: https://www.ibm.com/docs/en/i/7.5?topic=server-using-telnet-exit-point-programs
#IBMChampion