I am adding a remote queue manager to my WebSphere MQ client.
I'm not at all sure what that means. MQ Explorer stores a list of queue manager definitions. MQ Client is just a library for creating connections.
If you meant that you added the remote queue manager to MQ Explorer, then that makes sense. In addition to defining a connection in Explorer, you will also need to establish a connection in the queue manager. This means defining the SYSTEM.ADMIN.SVRCONN channel or one with a name of your choice that defines and starts the listener. If you use a queue manager of 7.1 or higher (it is always useful to specify versions when requesting MQ), you also need to create a CHLAUTH rule to allow the connection, and another CHLAUTH rule to allow the connection with administrative privileges. either this or is generally prohibited by the CHLAUTH rules, but this is not recommended.
If I have a channel name, for example MY.CHANNEL.NAME , and this is a connection channel to the server with mqm as its MCAUSER , can I run some commands (MQSC or OS) through this channel on the server?
May be.
Out of the box, MQ rejects all client connections. There are CHLAUTH rules that prohibit 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 using the SET AUTHREC or setmqaut before they can use SYSTEM.ADMIN.SVRCONN , which is why MQ is considered "safe by default."
When you create MY.CHANNEL.NAME and connect as an administrator, and if CHLAUTH is enabled, the connection will be rejected. You will need to add a new CHLAUTH rule, for example ...
SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD)
... to allow an admin connection.
(Note: MQ CHLAUTH blocking rules use the blacklist methodology. The standard rule blocks *MQADMIN from all channels. The above rule overrides the default rule because the channel name is more specific and blocks *NOBODY - which is a list of user IDs that are not includes mqm or any other administrative user id. It's weird, but that's how it works.)
Additional information on this topic http://t-rob.net/links , and in particular the presentation of the Morag conference on the CHLAUTH rules is a compulsory reading.
20150506 Update
The answer to changes No. 1 and No. 2 in the original question is as follows:
The first edit says that QMgr is in version 7.0, and the second shows that QMgr has CHLAUTH entries. Since CHLAUTH was not available before version v7.1, these two statements are mutually exclusive - they cannot be true. When providing a version of an MQ server or client, it is best to insert dspmqver output. If the question is about GSKit, Java code, or other components behind the base code, then dspmqver -a will be even better.
The MQSC output specified in the question update fully 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, SYSTEM.ADMIN.SVRCONN cannot be used because it is not defined.
AMQ8878: Display channel authentication record details. CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS)
The auths error occurs because any connection to any SYSTEM.* SVRCONN channel that is not explicitly redefined is blocked by this rule. The CHLAUTH rule for SYSTEM.ADMIN.SVRCONN takes precedence because it is more explicit and allows non-administrator connections to this channel. The absence of a similar override rule for SYSTEM.AUTO.SVRCONN means that it is rejected by the existing rule for SYSTEM.* Channels, as indicated above.
As noted earlier, it is STRONGLY recommended to go to the linked website and read the presentation of the Morag MQ v7.1 security conference and CHLAUTH rules. It explains how the CHLAUTH rules are applied, how priority works, and perhaps most importantly, how to check them using the MATCH(RUNCHECK) parameter.
To fulfill the MQ Security right, you need at least the following:
- Define a channel with a name that does not start with
SYSTEM.* , And set MCAUSER('*NOBODY') . - Define a CHLAUTH rule to allow connections to this channel, matching MCAUSER as needed.
- If you want to connect to the channel using
mqm or administrator access, define CHLAUTH rules to authenticate the channel, preferably using TLS and certificates.
There are several things that you do not , for the reasons that are explained in Morag and my presentations. These include...
- Using
SYSTEM.AUTO.SVRCONN for any legitimate connections. - In this case, use
SYSTEM.* Anything (except SYSTEM.ADMIN.SVRCONN or SYSTEM.BROKER.* ) For legitimate connections. - Allow unauthenticated administrator connections.
- Disable CHLAUTH rules.
- Disabling OAM.
I want people to learn about MQ security and learn it very well. However, as a consultant who specializes in this, I must tell you that even the clients who hired me to give on-site lessons and help in their implementation make it difficult to block it. Two ideas can be obtained from this fact.
First, if you don’t have enough time to speed up MQ security, the implementation will not be safe. To study the topic from the point of view of understanding how all the parts fit together well enough to develop a decent security model, you need practical training with QMgr that you can build, hammer, demolish, build again, etc. devoted to practical study, or months or years of random study. My advice here is to get MQ Advanced for developers. It is fully functional, free and has a superset of the controls that you have on v7.1 or v7.5 QMgr that you are currently working on.
The second understanding is that there is no shortcut to learning MQ (or any other IT security). If you approach it, as if it were just a configuration issue, it is almost guaranteed that it will not be safe in its implementation. If it is accessed by studying all the various controls available for authentication, authorization, and enforcing rules, and then learning how they all interact, and if security is approached as a discipline of practice, then some significant security can be achieved.
Solving this second problem will require investment in education. Read the presentations and try out various real-time controls on the QMgr you are administering. Understand which errors appear in the error logs that generate event messages and what types of events are generated. Get some of the diagnostic tools in SupportPacs , like MS0P , which is one of my favorites, and check out them. Consider attending the MQ Tech Conference (where you can meet the many people who answer here at SO) for more in-depth training.
If you (or your employer) are not ready to complete a deep skill, or are trying to learn it as soon as possible, consider hiring MQ Security's deep skills as needed, because relying only on training on this topic at present is a recipe unprotected network.