Run Linux/MQSC commands from mq client

Question

Ok, I want to check if I can run some OS or MQSC commands in MQ server remotely. As long as I know, this could be done with SYSTEM.ADMIN.SVRCONN. In order to do that, I add a remote Queue Manager to my WebSphere MQ client. I put Queue Manager name on the server with proper IP, but when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel name not recognized (AMQ4871) error.

Also, if I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?

Thanks.

Edit1

---

I am using WebSphere MQ v.7.0

By "I add a remote Queue Manager to my WebSphere MQ client" I meant I added a remote queue manager to MQ Explorer.

Edit2

---

I want to explain my question more precisely in this edit. I want to connect to a remote Qmanager via MQ Explorer. I know Qmanager name and its IP ofcourse. Also, the remote Qmanager has both SYSTEM.ADMIN.SVRCONN and SYSTEM.AUTO.SVRCONN channel available. When I check CHLAUTH for these channels, I've got:

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
     6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.AUTO.SVRCONN)            CHLTYPE(SVRCONN)
   MCAUSER( )

As you can see here, I should be able to connect via these two channels and run some commands. But when I choose SYSTEM.ADMIN.SVRCONN as channel name in remote configuration I get : Channel name not recognized (AMQ4871) and when I choose SYSTEM.AUTO.SVRCONN as channel name, I get: You are not authorized to perform this operation (AMQ4036).

Any idea?

Answer 1

when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel name not recognized (AMQ4871) error.

Did you define the channel on the remote queue manager?

if I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?

Sure. And so can anyone else. You should read up on MQ security and not expose your queue manager to hackers.

Answer 2

I add a remote Queue Manager to my WebSphere MQ client.

I'm not at all sure what this means exactly. MQ Explorer keeps a list of queue manager definitions. MQ Client is just a library for making connections.

If you meant you added a remote queue manager to MQ Explorer, then it makes sense. In addition to defining the connection in Explorer, you will also have to provision the connection at the queue manager. This means defining the SYSTEM.ADMIN.SVRCONN channel or one with a name of your choosing, defining and starting a listener. If you are on a 7.1 or higher queue manager (it's always good to list versions when asking about MQ), then you will also need to create a CHLAUTH rule to allow the connection, and another CHLAUTH rule to allow the connection with administrative privileges. either that or disable CHLAUTH rules altogether, but this is not recommended.

If I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?

Maybe.

Out of the box, MQ denies all client connections. There are CHLAUTH rules to deny administrative connections, and other CHLAUTH rules to deny connections for any SYSTEM.* channel other than SYSTEM.ADMIN.SVRCONN. Since admin connections are denied, non-admin users must have access provisioned using SET AUTHREC or setmqaut commands before they can use SYSTEM.ADMIN.SVRCONN, hence MQ is said to be "secure by default."

When you create MY.CHANNEL.NAME and connect as an admin, and if CHLAUTH is enabled, the connection will be denied. You would have to add a new CHLAUTH rule such as...

SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD) 

...in order to allow the admin connection.

(Note: MQ CHLAUTH blocking rules use a blacklist methodology. The default rule blocks *MQADMIN from all channels. The rule I listed above overrides the default rule because the channel name is more specific, and it blocks *NOBODY - which is a list of user IDs that does not include mqm or any other administrative user ID. It's weird, but that's how it works.)

More on this topic at http://t-rob.net/links, and in particular Morag's conference presentation on CHLAUTH rules is a must-read.

20150506 Update
Response to edits #1 & #2 in the original question is as follows:

The first edit says that the QMgr is at v7.0 and the second shows that the QMgr had CHLAUTH records defined. Since CHLAUTH wasn't available until v7.1, these two statements are mutually exclusive - they cannot both be true. When providing the version of the MQ server or client, best to paste in the output of dspmqver. If the question pertains to GSKit, Java code or other components beyond the base code, then dspmqver -a would be even better.

The MQSC output provided in the question updates completely explains the errors.

dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.

As Morag notes, the SYSTEM.ADMIN.SVRCONN cannot be used because it has not been defined.

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)

The auths error happens because any connection to any SYSTEM.* SVRCONN channel that is not expressly overridden is blocked by this rule. The CHLAUTH rule for SYSTEM.ADMIN.SVRCONN takes precedence because it is more explicit, and allows non-admin connections to that channel. The lack of a similar overriding rule for SYSTEM.AUTO.SVRCONN means it is denied by the existing rule for SYSTEM.* channels as listed above.

As noted previously, it is STRONGLY recommended to go to the linked web site and read Morag's conference presentation on MQ v7.1 security and CHLAUTH rules. It explains how the CHLAUTH rules are applied, how the precedence works, and perhaps most importantly, how to verify them with the MATCH(RUNCHECK) parameter.

To do the MQ Security right, you need at least the following:

1. Define a channel with a name that does not begin with SYSTEM.* and set MCAUSER('*NOBODY').
2. Define a CHLAUTH rule to allow connections to that channel, mapping the MCAUSER as required.
3. If you wish to connect to the channel with mqm or admin access, define CHLAUTH rules to authenticate the channel, preferably using TLS and certificates.

There are several things that you do not want to do, for reasons that are explained in Morag's and my presentations. These include...

1. Using SYSTEM.AUTO.SVRCONN for any legitimate connections.
2. For that matter, using SYSTEM.* anything (except for SYSTEM.ADMIN.SVRCONN or SYSTEM.BROKER.*) for legitimate connections.
3. Allowing unauthenticated admin connections.
4. Disabling CHLAUTH rules.
5. Disabling OAM.

I want people to learn MQ security, and to learn it really well. However, as a consultant who specializes in it I must tell you that even customers who have hired me to give on-site classes and help with their implementation have trouble getting it locked down. There are two insights to be gleaned from this fact.

First, if you do not enough time to get up to speed on MQ security then the implementation will not be secure. To study the topic to the point of understanding how all the pieces fit together well enough to devise a decent security model requires hands-on training with a QMgr that you can build, hammer at, tear down, build again, etc. takes weeks of dedicated hands-on study, or months or years of casual study. My advice here is to go get MQ Advanced for Developers. It is fully functional, free, and has a superset of the controls you have on the v7.1 or v7.5 QMgr you are working on now.

Second insight is that there is no shortcut to learning MQ (or any other IT) security. If it is approached as though it were simply a matter of configuration, then it is almost guaranteed to not be secure when implemented. If it is approached as learning all the different controls available for authentication, authorization, and policy enforcement, and then learning how they all interact, and if security is approached as a discipline of practice, then it is possible to achieve some meaningful security.

Addressing that second issue will require an investment in education. Read through the presentations and try out the various controls live on a test QMgr that you administer. Understand which errors go to which error logs, which generate event messages and which type of events are generated. Obtain some of the diagnostic tools in the SupportPacs, such as MS0P which is one of my favorites, and get familiar with them. Consider attending the MQ Tech Conference (where you can meet many of the folks responding here on SO) for more in-depth training.

If you (or your employer) are not ready to commit to in-depth skill building or are trying to learn this for an imminent project deadline, then consider hiring deep MQ Security skills on an as-needed basis because reliance on just-in-time on-the-job training for this topic is a recipe for an unsecure network.