Using cwbrxd without an AS/400

I am developing a soluting using RUNRMTJOB command in conjunction with cwbrxd.  The question has arisen about where the cwbrxd service should be running.  My choices are either running it on a central Windows 2003 server OR running on the PC's that will actually be requesting the application.  

I have a concern about running it on a Windows 2003 server from a security perspective.  I think there is less chance of a security hole if the service is run on the workstation.  My manager is of the opinion that is more efficient to run it on the server as you only have to install it once instead of on several workstations.  In essence, I agree.  However, the security aspect concerns me.

Is it possible to send a command to the server running this service without using the AS/400 runrmtjob command.  Can any computer send a remote command to this service and if so, how?  I would like to do a benign test to show my manager the vulnerability of running it on the server.

I would like to send a command from a PC to that server without using the AS/400 (such as copying a file).  Can this be done?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Gary PattersonVP Technology / Senior Consultant Commented:
Server or workstation?  

Well, my answer is "neither".

There is a reason that Microsoft doesn't supply a native Remote Execution Daemon (rexecd - that's what cwbrxd is) service.  It is an inherently insecure service.  I avoid designing it into my applications, flag it as a possible vulnerability when I find it in a security audit, and take it out when practical.  It is a prohibited service in many shops due to the exposure it creates.  

Can you send a command to the service without RUNRMTCMD?  


You can use any rexec client to send a command to the service.  Rexec clients exist for just about every OS you can imagine (Google "rexec client xxxx" where xxxx is your OS of choice.).  There are also lots of rexec components available, and of course you can always write a program that speaks rexec protocol (

Can any computer send a remote command to this service?  

Yes, unless you filter somehow, like with a firewall or Windows IP filtering.  Plus you need to maintain this on every system that runs the service, creating quite a bit of admin overhead.


Open a command prompt on your XP machine and type "rexec".  Every unix/linux derivative I've ever encountered has a rexec client.  Open up a 5250 session on any of your AS/400 / iSeries / System i systems and try "rexec" [F4].

If not rexecd, then what?

Ok, now that we know that rexecd is evil (ok that may be a bit harsh), what is a poor AS/400 technician to do when faced with the need to make Windows do something for you?

There are a lot of approaches that will work, but I'll confine myself to one suggestion here:  AS/400 Data Queue's

Use an AS/400 Data Queue (*DTAQ object) to pass command requests to a custom Windows (or Java) application that monitors the data queue, inspects the incoming request, and either executes it or rejects it based on whatever rules you choose to implement regarding "safe" commands.  If you want to get fancy, you can externalize the "rules", so that adding another permitted command or set of commands only requires a settings file change, and not a code change.  (I use regular expressions syntax for this, but that is another post.)

As long as you secure the AS/400 data queue object, and only allow specific processes to place entries on the queue, you can dramatically limit the exposure of unauthorized commands getting executed on your server or workstation.  The client-side code can provide significant further protection by stringently limiting the commands that can be executed to a "safe" subset.  

I select using a data queue for several reasons (although there are a plethora of other approaches that can be made to work just fine):

1) By securing access to write to the data queue, you can very strictly limit the AS/400 applications and user profiles that can cause remote commands to be executed on the Windows side.  This is much more difficult to do securely with Rexecd.

2) Reading and writing to and from data queues is very easy in native RPG, COBOL, and CL, .as well as on the client side in NET, legacy Microsoft languages, and Java.   Google "iseries data queue (language of your choice)" and you will find plenty of examples.  Here's one in .NET:

3) The receiving Windows application can inspect and validate incoming requests, and only execute those that it deems to be valid or permitted.  You can't do that with Rexecd, you have to trust the sender to only send permitted commands (or you have to run under a Windows profile that only has permission to certain commands, and that can be a real admin challenge, especially if you are running on a bunch of workstations).  There is also no easy way to inspect or filter commands based on parameters in Rexecd, where you can easily do this in your own application.

4) iSeries Data queue service can be (probably should be) configured to run over SSL, so messages are encrypted.  Rexec service can also do this, so it is not a specific advantage, but I mention it because it is a great practice, especially if there is any chance now or in the future that commands containing user id, passwords, or confidential data will be exchanged.

5) If you need to receive incoming requests from multiple systems, you can either monitor multiple queues, or you can set up remote data queues on the additional systems that feed the master data queue on the central system.

Again, there are many, many approaches that will work, but I like this one from a security, stability, and ease-of implementation standpoint.  You can deploy it to servers or to workstations without creating the exposure created with Rexecd.

- Gary Patterson


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cosmitAuthor Commented:

Thank you for your thoughtful answer.  You have answered several of my AS/400 questions in the past and without fail have been extraordinarily helpful.

Gary PattersonVP Technology / Senior Consultant Commented:
Recognize your handle.  Always happy to help.  Glad you find it useful.

- Gary
5) If you need to receive incoming requests from multiple systems, you can either monitor multiple queues, or you can set up remote data queues on the additional systems that feed the master data queue on the central system.

Just a minor comment (Gary has it handled fine)... Keep in mind that data queues can be "keyed" also. This can be used to identify targets if necessary -- multiple PC clients could watch for entries directed at them. Or used to identify sources, although the SenderId attribute could also be handy.

Design of the format of the entries can make data queues very flexible. And once in place, the extensibility is great.


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.