Avoiding Unsanctioned 'Drive-By' Access to IBM i

By Dan Riehl

Most of us run IBM i Access for Windows. That's the newest name for what we used to call PC Support, Client Access and iSeries Access. You probably use the Personal Communications PC5250 emulation software to provide your workstation sessions. You may also use the IBM i Navigator (Operations Navigator, iSeries Navigator) portion of IBM i Access for Windows.

There are several IBM supplied applications that are installed on your PC when you install IBM i Access for Windows. Included in these additional applications are the Remote Command facility, the ODBC Driver and various File Transfer programs and Service utilities. One critical piece of software that is installed is the command interface to Set or Flush the Signon Server cached User IDs and Passwords, which is the topic of our discussion here.

When you run IBM i Access functions on your PC that require communications with the host, you must first authenticate to the host. To accomplish this authentication, IBM provides the Signon Server GUI window where you provide your credentials(i.e. UserID and Password) as shown here.

Once you have successfully authenticated, your PC provides an open session to access the IBM i   without any further authentication!   You can transfer files, run remote commands, examine spooled files, and more.. . without providing your logon credentials again.

So, do you shut down your PC, or flush your cached credentials when you leave your desk? Or, as most, do your leave the session open, thus allowing unsanctioned access to the IBM i for anyone that happens to 'Drive-by' your unattended PC?

The Mechanics of IBM i LOGON

When you enter your User ID and Password, they are passed to the IBM i Signon Server, or other service, and also cached on your PC for later use. Once the authentication information is cached on your PC, you do not need to supply the information again, until you reboot your PC (depending on your configuration.)

So, when you now need to run a remote command, or access a database using ODBC, or download a file with File Transfer, you are not required to manually authenticate again. The cached User ID and Password for that system can be automatically supplied to the service requested without any user action required. This is both a blessing and a curse. It's a blessing because you are not required to manually log-on for each action you want to initiate. It's a curse because your credentials are cached on your PC and can be used by anyone who can access your workstation. What you have, in essence is an open session allowing potentially unsanctioned access to the system, using YOUR credentials.

Even if you select the IBM i Access Log-on option to "Prompt Every Time", I have found that some services do not "Prompt Every Time." They instead use your cached credentials.

From a security perspective, this caching of User ID and Passwords on the local PC present exposures that need to be addressed.

The IBM PC Command CWBLOGON

When IBM i Access is installed on your system, one of the PC commands loaded is named CWBLOGON. This command can be used to store information for Log-on to a host, or to flush the cached User ID and Password for a particular system, or for all systems (if you log on to more than one).

The Syntax of the command can be seen by entering the following command at the Windows/DOS prompt:

CWBLOGON /?

Typing the command at a prompt shows the following information.

To add entries to the IBM i Access for Windows cache:

CWBLOGON systemName /u userID /p password

  systemName  - designates the IBM i system name to store user ID and
                password information for.
  /u userID   - designates the IBM i user ID to store in the IBM i Access
                for Windows password cache.
  /p password - designates the IBM i password to associate with the user ID
                provided. Enclose the password in double quotation marks if
                it contains embedded blanks.

To remove entries from the IBM i Access for Windows cache, use one of the follow
ing:

CWBLOGON systemName /u userID /c
CWBLOGON systemName /c
CWBLOGON /c

  /c - indicates to clear entries from the IBM i Access for Windows password cac
he.
       If no user ID is specified, all user ID's will be removed for the
       system. If no system name is specified, all entries will be removed.

Flushing the User ID and Password

As you can see in the command help text above, the /c switch can be used to clear the User ID and Password cached for a particular system, or for all systems, or for a particular user on a system. As you can see, we can clear the cache for all systems using the command:

CWBLOGON /c

When you then attempt to connect to the host again, through an IBM i Access facility, you will again be prompted by the GUI window to enter your User ID and Password.

Make a SIGNOFF.BAT file or a Windows Application for Log-Off

When a user is leaving for the day or going off to a meeting, we hope that the Windows session will be locked until they return. This may, or may not be the case at your office. Regardless, I want to encourage you to provide a .BAT file or a Windows application that allows a user to shut down the authenticated session when they are going to be away from their desk.

Here is a simple .BAT file I call SIGNOFF.BAT. Just enter the code below into notepad, and save the file to your desktop with the name SIGNOFF.bat

@ECHO OFF
CWBLOGON  /c
ECHO YOU ARE NOW LOGGED OFF
PAUSE

When a User runs the SIGNOFF.BAT file, by double-clicking the icon on the desktop, a pop-up window shows the following text:

IBM i Access for Windows
Version 7  Release 1  Level 0
Logon Utility
(C) Copyright IBM Corporation and Others 1984, 2010.  All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure
  restricted by GSA ADP Schedule Contract with IBM Corp.
Licensed Materials - Property of IBM

User ID and password information cleared from IBM i Access for Windows cache
YOU ARE NOW LOGGED OFF
Press any key to continue . . .

You have now shut down the connection and flushed the cache. You have avoided the possibility of "Drive-By" access, and you are a whole lot more secure.

About the Author

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn