Manage Learn to apply best practices and optimize your operations.

Controlling remote command processing

Remote command processing could give users commandline access. Find out how to close this loophole.

One of the cardinal rules of securing your iSeries-AS/400 system is to prevent users from having open access to the OS/400 command line unless absolutely necessary. Typically, access to the command line is limited to operators, programmers and other IT staff users who need it to get their jobs done. Users in general should never be granted use of the command line.

A knowledgeable PC user, using PC-based software tools such as iSeries Access (Client Access), can run commands on your system without obtaining a sign-on screen and command line. Also, when a user submits a remote command, OS/400 does not honor the Limit Capability (LMTCPB) setting for the user profile in use. In my book, that is a significant security exposure. Granted, the user must be knowledgeable, but it can be done.

There are several ways that can be accomplished. View the following:

  • Using Distributed Data Management (DDM), a user can open a file and use the remote command function to run any command on the remote system.

  • Using the iSeries Access optimized client, or other similar PC software, a user can issue a command through Distributed Program Call (DPC) APIs without even using DDM.

  • Using remote SQL and ODBC, some software can provide a remote command function without using either DDM or DPC.

What's a security officer to do?

Deal with the DDM issue. One easy way to control that is to simply turn DDM access off completely for your system. You should first verify that no current applications running on your system require DDM, Distributed Relational Database Architecture (DRDA) or DB2. To shut DDM off, simply run the following command:


This step is pretty drastic and obviously will not work for many shops where DDM, DRDA and/or DB2 are in use on a regular basis. For those shops, your best defense is an aggressive security policy that protects your critical data assets.

If you want to take a more active approach to this issue, then you'll have to look into coding an exit point program, or you can purchase a third-party software package that implements exit point processing. The easiest approach when creating your own exit program is to limit the use of remote commands to a list of known user profiles. That allows you to grant permission to process remote commands for known and trusted user profiles, while denying permission to all others. In the exit point process, you can set a flag that returns a failure status to the PC software issuing the remote command process, so your user will know why his attempt failed. You can find more information about exit point programming in several manuals, such as the following:

  • Implementation Guide for iSeries Security and Auditing -- GG24-4200
  • iSeries Security Reference - SC41-5302
  • iSeries System API Reference book

If you have any questions about this topic, you can reach me at, I'll give it my best shot. All e-mail messages will be answered.

About the author: Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.