I’ve always envied the PC world, with its screen savers and workstation locks. I’ve spent many hours at the local computer retailer trying to crack the screen saver password to access the latest “giga-machine” without overzealous attention from a pimply teenage wannabe computer nerd! I began to investigate whether the AS/400, one of the most secure platforms in the world, could manage the simple problem of unattended terminals and found both good and bad news.

First, the bad news: There’s no easy way to display flying stars or morphing images of Lou Gerstner on a dumb terminal. (This could actually be considered good news.) Also, the AS/400 interface provided to handle unattended workstations is uninspiring to say the least.

Now, the good news: AS/400 inactivity system values do allow user-written programs to process inactivity timeouts on the terminal. The Lock Workstation (LOCK) utility provides a way to secure a workstation manually before leaving it unattended and also allows a monitor to lock a workstation after a specified period of inactivity.

In this article, I present a tool that allows the user to lock a terminal manually and show you how to set the system to lock automatically based on inactivity. You can download the source code for these objects at www.midrangecomputing.com/mc/99/08 or download the entire object library at www.acsltd.com.

The Manual Session Lock

Figure 1 lists the objects that compose the LOCK utility. The LOCK command requires no parameters and is entered from a command line to place the session in a locked state. LOCK controls the pop-up window that allows the user to enter an AS/400 password to unlock the session. Specifying the nondisplay attribute in the DDS prevents the password from being seen as it is entered. Check Password (CHKPWD) verifies that the password entered is correct. If the password is incorrectly entered the maximum number of times (as determined by system value QMAXSIGN), the program issues a message to the system operator message queue and system history log indicating that an intruder has been detected at the workstation. This message is also issued to the user signed on to the workstation at the time. The session then ends, generating a job log using the SIGNOFF LOG(*LIST) command. To make manual locking of the workstation easier, the LOCK command can

also be associated with the Attn key by using command SETATNPGM PGM(mylib/LOCK) MODE(*ON).

Ignore System Request (IGNSYSR) sends a status message if a system request function is attempted while the terminal is locked. This status message prevents passersby from canceling the process or obtaining a command line via the System Request 3/option 16/F9 sequence of keystrokes. The LOCK program creates a temporary message file in library QTEMP with the same name as system message file QCPFMSG and overrides message processing to the new message file. All system request function commands except System Request 1 (Transfer to Secondary Job) are stored in message description CPX2313. In the temporary message file, you create a message description CPX2313 that replaces all the commands that IBM provides with IGNSYSR, rendering original system request functions unavailable. The Transfer to Secondary Job function is hardwired, but you can control its exposure by requiring a sign-on or, if a user is already signed on, requesting a separate lock. Unlike other types of override, overriding a message file really happens at the message description level. If the system needs to access any other message from QCPFMSG, the new message file is searched and, if no match is found for the required message description, IBM-supplied QCPFMSG is used.

If you have an Attn key-handling program (for example, to summon a group jobs menu), temporary reassignment of the Attn key prevents return to any group jobs menu. The original Attn key setting is reactivated upon unlocking the terminal; a setting of “Previous Invocation Level” is available to return the Attn key setting to its previous value.

The LOCK command is similar to IBM’s Disconnect Job (DSCJOB) but has the added advantage of being clear that the session is still alive behind the scenes. Disconnecting a job usually prompts a system sign-on screen indistinguishable from the normal sign-on screen. I have frequently witnessed users go to lunch and return to see this sign-on screen and assume incorrectly that they are signed off. They either power off their terminals or let the Disconnected Job Interval (QDSCJOBITV) system value expire, forcibly ending their sessions. Ending sessions in the middle of processes in this way can have serious repercussions on data integrity.

The Automatic Session Lock

The ability of the system to lock a session automatically comes ultimately from the manual session lock. The automatic lock allows the system to issue the LOCK command after a specified period of inactivity without user intervention. Figure 2 lists the objects that “upgrade” the functionality of the LOCK utility. The system provides two system values to allow you to process inactivity. System value Inactivity Interval (QINACTITV) allows you to select how much time passes before a session is considered inactive. Values range from *NONE (which is never considered inactive) to 5 minutes through 300 minutes of inactivity. After the system value is set to a value other than *NONE, the system performs the function designated by the second system value, Inactive Message Queue (QINACTMSGQ). QINACTMSGQ accepts three values: *ENDJOB (which ends the job if it is inactive), *DSCJOB (which disconnects the job if it is inactive), or the name of a message queue to be sent a message that contains the name of the session that has been inactive. This is where you step in.

By running a never-ending program that awaits arrivals in the designated message queue, you can extract the name of the inactive workstation sessions. The challenge is to get the lock request to a process that can interrupt a session and perform a function. The AS/400 assigns message queues to device descriptions as well as to individuals. If you set a session’s message queue to run in *BREAK mode, it can interrupt the operation being performed at the workstation. Displaying a message won’t help you with the task at hand, but, fortunately, the message queue allows a user-written program to be executed when a message arrives in the queue. Therefore, you need only extract the name of the session

from the timeout message sent by the system and forward to the session message queue a special message instructing a custom “break message handler” to lock the session.

Nonetheless, that’s all theory; this is the reality. Executing Start Lock Workstation Server (STRLWSSVR) creates a runtime environment consisting of a subsystem (LWSSBSD), job queue (LWSJOBQ), and inactivity message queue (LWSMSGQ). STRLWSSVR has three parameters that allow you to select how the server is started:

• Server library (LIB) serves as starting point for runtime environment objects, such as the subsystem.

• Create server objects (CRTSVR) controls whether server objects are created if they don’t exist (or re-created if they do exist).

• Inactivity interval (INACTITV) controls how long a session is inactive before it is The two inactive session system values discussed earlier are set with a specified inactivity interval and inactivity message queue name (LWSMSGQ), and the continuous server job (LWSSERVER) starts.

LWSSERVER waits for arrivals in the LWSMGSQ message queue. When a message is received that indicates a session has been inactive, the system uses RPG program Retrieve Lock Workstation Information (RTVLWSINF) to see if the session is currently being monitored. If it is being monitored, a second RPG program, Retrieve Lock Workstation Status (RTVLWSSTS), is called to tell the server if the session is already locked. If the session is not locked, a lock request is forwarded to the session’s message queue, and the server job waits for the next inactive message to arrive.

By using Start Lock Workstation Monitor (STRLWSMTR), you can set a session to handle the incoming lock request. The command sets the session message queue to break mode and assigns a user-written break-handling program (LWSBREAK) to activate upon arrival of a message in the queue. LWSBREAK retrieves and checks incoming message text for a fixed message from the server job. If the message is not from the server job, Display Message (DSPMSG) is processed to allow the user to see the message as if the default message handler (*DSPMSG) were assigned to the message queue.

I recommend starting the subsystem and server job during an IPL by issuing STRLWSSVR from within the QSTRUP program. IBM does not provide the source for this program but allows its retrieval via the Retrieve CL Source (RTVCLSRC) command. Make changes to start the server job and recompile QSTRUP into a library. (Never replace the original IBM-supplied version in QSYS.) Change the system value for the startup program (QSTRUPPGM) to point to your version of the program. I have included in my source a copy of QSTRUP as of V4R3 for you to see a sample of how to integrate the command into your environment. Because STRLWSSVR changes the two inactivity system values, which are Security (*SEC) values, the program is set to run under the adopted authority of the system Security Officer (QSECOFR).

RTVLWSINF allows programs to detect the status of the server job as well as the status of a specific workstation monitor. When passing special value *SERVER, the program knows to retrieve status information about the server job. The program determines the status via two APIs. API List Jobs (QUSLJOB) initially provides the program with a list of active jobs with the name LWSSERVER. If any jobs are found with this name, a second API, Retrieve Job Information (QUSRJOBI), is called to see if any of the jobs are running in the Lock Workstation Subsystem (LWSSBSD). This second API also allows you to retrieve the name of the library that contains the server objects. If a specific workstation session is being requested, API Retrieve Non-program Message Queue Attributes (QMHRMQAT) allows you to retrieve the current break-handling program assigned to the session message queue. If the queue has the application break-handling program (LWSBREAK) assigned, you can indicate that the session is ready to process incoming lock requests.

To prevent multiple lock requests from queuing up in the workstation message queue during an extended period of inactivity, you need a means of detecting whether a

locked.

session is currently locked. RTVLWSSTS uses another system API, List Object Locks (QWCLOBJL), to list object locks currently in effect on the locked workstation’s pop-up window. When a session is locked either manually or via inactivity, it displays the pop-up password window, locking the display file. Using this information within the server job, you can ignore inactivity messages for sessions that have already been secured.

Each user profile has an initial program that is called when the user signs on to the system. By issuing Start Lock Workstation Monitor (STRLWSMTR) in the initial program, it is possible to set up the workstation message queue for timeout without user intervention.

To end monitoring for a session, use End Lock Workstation Monitor (ENDLWSMTR) to change the workstation message queue to display incoming break messages without invoking the break-handling program. To prevent someone from ending the monitor, ENDLWSMTR can be made to run only by a profile that has Security Administration (*SECADM) special authority.

To shut down the server job (for example, prior to a backup or nightly process), issue End Lock Workstation Server (ENDLWSSVR). The command processor requires that it be run by a profile that has Security Administration (*SECADM) and All Object (*ALLOBJ) special authorities. Shutdown changes the system value for QINACTITV to *NONE and also sends a message to LWSMSGQ that is received by LWSSERVER, which then ends normally. LWSSBSD ends subsequently. By specifying *YES on the Delete server objects (DLTSVR) parameter, you can optionally delete all server objects after the server has been shut down.

Am I Still Exposed?

Like most programs, however, this process has its limitations.

• If you are running multiple sessions, each session is independent. That is, if a session is locked, other active sessions at that workstation do not lock automatically.

• If you are using a PC and that PC is set to “bypass sign-on” by using a user name and password entered for an AS/400 connection, any user who knows how to start an additional session can access the system. You can reduce this exposure by keeping your device descriptions cleaned up and Auto Configure turned off during normal operations.

• PCs provide various ways to enter commands without going through the 5250 interface. CA/400’s Remote Command function and FTP can both run OS/400 commands. For environments that use PCs with additional functionality, consider the Windows screen saver approach. Modify the LOCK command to detect the type of device the user is attempting to lock, and for PCs, issue Run Remote Command (RUNRMTCMD) to initiate a Windows screen saver .SCR file that is configured to require a password for entry. This approach prevents unauthorized access to the entire PC workstation.

• All object and data locks stay in effect while the session is locked. For example, suppose a user is looking up open accounts receivable on a customer and presses Attn to lock the session before going to lunch or lets the session timeout from inactivity. The customer record and any associated records required for the application remain unavailable to other users until the lock is released and the process is completed.

• Any use of Change Message Queue (CHGMSGQ) can reset the break-handling program back to *DSPMSG, having an effect equivalent to running ENDLWSMTR. Use EDTOBJAUT to restrict user access to CHGMSGQ. Alternatively, create your own CHGMSGQ command that retrieves the current break-handling program for the session and reassigns it after processing IBM’s CHGMSGQ command. I have retrieved for you a version of IBM’s CRTMSGQ command definition to assist in this.

Note that all the above limitations (except the last) are also true when using the Disconnect Job (*DSCJOB) option on the QINACTMSGQ system value. However, by using the LOCK command, the session stays active and, therefore, is not ended until the interactive job is ended.

Locking Things Out, Locking Things In

As industries continue to connect e-business servers to the Web at a phenomenal rate, I applaud those companies that are assessing their exposure to the outside world. I must remind people, though, that the greatest threat can sometimes come from within. Unattended terminals present a danger to any company that uses an AS/400 as its business solution. They potentially expose payroll, account receivable, sales, or revenue information to anyone who happens to walk by. Even worse, a system can be rendered inoperable by a console left signed on by a security officer who says he’ll be “back in a minute.”

I hope this application has provided you with not only a tool for locking down terminals but also an idea of how the basic concept can be enhanced to provide a more complete lockdown environment for PCs.

Object name Type Description

LOCK Command Lock workstation LOCK CL program Lock workstation command processing program
LOCK Display file Pop-up window to unlock workstation IGNSYSR Command Ignore system request
IGNSYSR CL program Ignore system request command processing program
IGNATTNKEY CL program Ignore attention key

Figure 1: The LOCK utility consists of these objects.

Object Type Description

STRLWSSVR Command Start Lock Workstation Server ENDLWSSVR Command Stop Lock Workstation Server STRLWSMTR Command Start Lock Workstation Session Monitor ENDLWSMTR Command Stop Lock Workstation Session Monitor LWSSERVER CL program Lock Workstation Server Job

(never-ending program) LWSBREAK CL program Lock Workstation Break Message Queue

Handling Program RTVLWSINF RPG IV program Retrieve Lock Workstation Information RTVLWSSTS RPG IV Retrieve Lock Workstation Status

Note: These commands all consist of a command definition (*CMD), a command processing program (*PGM), and a panel group (*PNLGRP) for help text. Each component has the name of the command.

Figure 2: You need these additional objects for automatic locking.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails