July 26, 2019.
This week we’ll look at how we can improve the security of a queue manager by using MQ channel authentication records.
Introduction
Many MQ admins think that channel authentication is complicated to setup and requires a lot of micro-management. I am going to show you that channel authentication is a great MQ security feature and doesn’t require anything special to configure or administer.
Channel authentication was introduced back in MQ version 7.1. Its security model is similar to opening ports on a UNIX system: first, you lock everything down, then you open the ports one by one as they become needed. Same is true for channel authentication. First, you create records to deny all connections to the queue manager, then you create records to allow those connections that you need to allow. Channel authentication records follow the general rule that more specific records take precedence over more generic ones. For example, if you deny connections from *.untrusted-domain.com (all hosts from this untrusted domain), but then a create a record to allow connections from trusted-host.untrusted-domain.com, then the queue manager will allow connections from that one specific host in the entire domain.
Second thing to remember is that you don’t have to refresh security after changing channel authentication records. It will be picked up immediately by the queue manager after you create, edit, or delete one.
In order to deny all connections, you want to forbid three specific things:
- Access by admin users, such as mqm
- Access from all hosts (blanket restriction)
- Access over SYSTEM.ADMIN.SVRCONN channel
Technical Steps
These steps have been tested on MQ v8 and v9.
1. Create a rule to block privileged user access:
SET CHLAUTH(‘‘) TYPE(BLOCKUSER) USERLIST(‘MQADMIN’) WARN(NO) ACTION(ADD)
*MQADMIN is a special designation for MQ admin users which are different on different platforms (e.g., mqm on Linux).
2. Create a rule to block all incoming connections:
SET CHLAUTH(‘‘) TYPE(ADDRESSMAP) ADDRESS(‘‘) USERSRC(NOACCESS) WARN(NO) ACTION(ADD)
Those two rules will block all incoming connections and no users or applications will be able to connect as an admin, meaning each user ID will be evaluated by the queue manager for level of access to grant using OAM (Object Authority Manager).
3. Remove access via a SYSTEM channel
By default, a new queue manager gets created with a channel authentication rule that allows connections over the SYSTEM.ADMIN.SVRCONN channel. You want to remove that rule, because that channel name is widely known and any attempts to gain unauthorized access to your queue manager will use that channel name (along with SYSTEM.AUTO.SVRCONN and other channels auto-created by MQ):
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
4. Create a rule for administrators
Next, you want to enable connections for administrators, such as yourself, so you can access the queue manager using MQ Explorer or RFH Utility:
SET CHLAUTH(‘ADMIN_CHANNEL’) TYPE(ADDRESSMAP) ADDRESS(‘workstation1.mydomain.com’) USERSRC(CHANNEL) CHCKCLNT(REQUIRED) ACTION(ADD)
ADMIN_CHANNEL is the name of the channel this administrator will be allowed to connect on. The name of the workstation, that the connection has to come from, needs to be workstation1 in domain mydomain.com. The user name will be adopted from the channel: it will be set to whatever user passes from the application. CHCKCLNT(REQUIRED) is a setting that forces the user to send a valid password together with the user name and this pair will be checked for validity. If no password is sent or the password for this user is invalid, connection will be denied.
You want to enable this rule for each specific workstation of each administrator. What if you’re using a VPN connection from mobile devices or from a home laptop? In these cases, you need to VPN to a virtual desktop which will have a DNS name inside a trusted network which, in turn, will establish a connection to MQ; or you can RDP over VPN to a physical workstation in your office that will also have a DNS name inside a trusted network and you can connect to MQ from there. You can also set ADDRESS(‘*’), but that defeats the whole purpose of securing channels with channel authentication records.
Another important point to make here is that you can specify a user ID instead of using USERSRC(CHANNEL). Use USERSRC(MAP), and then specify the user ID in the option MCAUSER, such as MCAUSER(‘legacy_user’).
A rule will look like this:
SET CHLAUTH(‘LEGACY_CHANNEL’) TYPE(ADDRESSMAP) ADDRESS(‘legacy-host.mydomain.com’) USERSRC(MAP) MCAUSER(‘legacy_user’) ACTION(ADD)
This will map all incoming connections from legacy-host.mydomain.com host over LEGACY_CHANNEL channel to user ID legacy_user. No matter what the application would send from the other side, the queue manager receiving the connection would map it to legacy_user. This might be useful in situations where you have old, legacy applications not capable of passing a user ID. Then you assign them a user ID and grant that user permissions only to the objects they need access to.
Note that if an application cannot pass a user ID, it is probable that it cannot send a password either. That is why CHCKCLNT parameter is missing from the rule above. The rule will look at the setting on the queue manager. Make sure to set it to CHCKCLNT(OPTIONAL) on the queue manager level. Then by specifying CHCKCLNT(REQUIRED) on individual rules, you will override the queue manager setting and force applications to send user ID and password, and by omitting CHCKCLNT from individual rules, they will be able to connect without a user ID or password. You, as an MQ admin, will control this behavior.
5. Create a rule to allow connections from queue managers in the cluster
An important rule, to create next, is to allow connections from queue managers in the cluster:
SET CHLAUTH(‘CLUSTER_CHANNEL’) TYPE(ADDRESSMAP) ADDRESS(‘*.mydomain.com’) USERSRC(CHANNEL) ACTION(ADD)
This rule will allow connections over the cluster channels from anywhere within the trusted domain and no user ID or password will be queried. You can also create a separate rule for each queue manager in the cluster with their respective host names in the ADDRESS parameter, but if you have tens of queue managers in your clusters, that might just not be feasible.
If you have more than one queue manager running on the same host (e.g. a full cluster repository and a partial cluster repository), sometimes DNS resolves the host name differently than if they were on different hosts. Remember that MQ uses reverse DNS lookup to determine the host names of connecting clients. In my practice, I have seen that a host name resolves to host1.mydomain.com to outside hosts and to host1.msad.msroot.com on the same machine. Is it a peculiar DNS configuration on the network level? There could be a number of reasons, but you need to account for these cases when using channel authentication records.
This covers all the necessary rules. Next, as applications request connections to your queue manager, you create the rules for them.
6. Create a rule to allow an application to connect
For example, an application APP1 wants to connect. You ask them what host they will be connecting from and what user ID they will be using to connect, then you create a rule for this application:
SET CHLAUTH(‘APP1_CHANNEL’) TYPE(USERMAP) CLNTUSER(‘app1_user’) USERSRC(CHANNEL) ADDRESS(‘app1-host.mydomain.com’) CHCKCLNT(REQUIRED) ACTION(ADD)
7. Create a rule to allow a user to connect
Another example is when a user Rachel requests access to monitor her queues using MQ Explorer and RFH Utility. You ask her what the host name of her workstation is and what her username is:
SET CHLAUTH(‘SUPPORT_CHANNEL’) TYPE(USERMAP) CLNTUSER(‘RACHEL’) USERSRC(CHANNEL) ADDRESS(‘rachels-workstation.mydomain.com’) CHCKCLNT(REQUIRED) ACTION(ADD)
Important to note here is that each application might get their own dedicated channel, but users should be grouped and assigned a channel by their role. For example, if there is a team that supports MQ and they are all administrators, you would want to create a channel ADMIN_CHANNEL just for this group. If Rachel is an elevated user who has permissions to drain queues and increase their depth but is not a full admin, you would want to create a separate channel for these folks and call it something like SUPPORT_CHANNEL. Finally, if you have a group of users who want to look at queues and messages but don’t have permissions to do anything else, then you might want to create a channel USER_CHANNEL or READ_ONLY_CHANNEL for that group.
8. Create a rule to allow another queue manager to connect
Another important example is queue manager to queue manager communication. There is a special type of channel authentication record that will allow you to do that. Here is an example:
SET CHLAUTH(‘ANOTHER_QMGR_CHANNEL’) TYPE(QMGRMAP) QMNAME(‘ANOTHER_QMGR’) USERSRC(CHANNEL) ADDRESS(‘another-qmgr-host.mydomain.com’) ACTION(ADD)
It looks similar and follows the same logic. Don’t specify CHCKCLNT(REQUIRED), because queue managers don’t know and are incapable of sending across passwords.
9. Modify the queue manager
Next we need to do some manipulations on the queue manager to enable channel authentication and set it to work. Modify the queue manager to enable channel authentication:
ALTER QMGR CHLAUTH(ENABLED)
If you’re using the default authentication object SYSTEM.DEFAULT.AUTHINFO.IDPWOS provided for newly created queue managers, you need to change it to set the check client connection user ID and password parameter to optional.
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS)
CHCKCLNT(OPTIONAL) CHCKLOCL(NONE)
REFRESH SECURITY TYPE(CONNAUTH)
The particulars about connection authentication is subject for another blog post.
And the last thing you need to do is define permissions for various groups accessing your queue manager using the setmqaut commands (also subject for another blog post).
Stay tuned for more!
Thanks Igor. Your page was really helpful to me