As of v8.0, MQ now can natively validate user IDs by checking the password against the Operating System or LDAP. Checking against Pluggable Authentication Module (PAM) was added in v184.108.40.206. Prior to v8.0 it was necessary to use a channel security exit to perform password-based authentication over SVRCONN channels. With MQ v8.0 and later, password-based validation is natively supported and integrated with CHLAUTH rules.
This has been a widely anticipated feature so it came as no surprise that implementing it was among the requirements on each of my several most recent consulting engagements. What was surprising however is that over time I noticed that techniques I’d used at one client for combining CHLAUTH with password based authentication didn’t seem to work at the next. The first time I noticed this I wrote it off as having taken poor notes. The second time though led me to undertake a comprehensive analysis on a per-version and per-fix-pack basis.
This post and accompanying materials are an executive overview of the findings and recommendations. More detailed findings will be posted shortly. My priority in this initial publication is to introduce the issues and outline the recommendations for safely using the new features.
The behavior of MQ password-based validation combined with CHLAUTH mapping rules has changed several times across the initial release of MQ v8.0 and subsequent Fix Packs. Core functionality is affected, sometimes in ways that break applications, and other times in ways that silently over-authorize. The best case is actually the one in which an outage occurs because at least there is some overt indication that the behavior has changed. Silent over-authorization is worse due to an expectation of security that does not actually exist.
Secondary effects of these changes follow on in the form of increased administrative and testing overhead after each patch release, or else relaxation or abandonment of patch management.
These recommendations all apply when password-based authentication is enabled. Unfortunately the proposed settings significantly restrict CHLAUTH functionality given the current MQ implementation, but there is no middle ground between this and what by most standards would be an unacceptable lack of security.
- If you are currently using an exit to perform password-based authentication, you might strongly consider sticking with it.
Assuming native MQ password authentication is going to be used, I consider the following to be mandatory:
- Enable the queue manager’s password protection policy and/or set up TLS on the client channels. This protects credential exchange on the network up to a point. It is still possible to send the ID and password in the clear but the queue manager will reject the connection.
- Use MQCSP authentication mode instead of Compatibility Mode. This is set at the client side.
- CHLAUTH must always be enabled.
- ADOPTCTX must always be set to YES.
- Use only USERMAP rules with USERSRC(CHANNEL). If address mapping is required, use the address function in the USERMAP rule in addition to specifying the CLNTUSER field.
- Under MQ v220.127.116.11 and MQ v9.0, enable ChlauthEearlyAdopt in all cases.
- Be prepared to spend more time testing Fix Packs, especially including negative cases that test for silent over-authorization failures.
As a strong proponent of timely patch management, the last recommendation pains me greatly to have to write but I don’t see an alternative. Standard 30/60/90 day targets may be impossible to meet given the volatility observed and the substantial nature of the changes to key behavior of these security controls across maintenance releases.
- If you are an auditor or QSA, consider that the changes over maintenance levels seen so far potentially require code changes and/or modifications to the security model significant enough to preclude timely patch management. I’m not suggesting abandoning the requirement altogether, just that some Fix Packs (v18.104.22.168 was one example) may need to be skipped altogether and some (v22.214.171.124 for example) may impose an exceptional resource impact requiring extended lead and implementation times.
Platforms and versions known to be affected
I tested Red Hat and SUSE Linux and Windows 10 against MQ Advanced for Developers. For Linux I have tested every version and Fix Pack between MQ v8.0 and MQ v9.0, inclusive. I am still testing Windows but have completed tests at MQ v9.0.
The tests in all cases used OS-based ID and password checking over SVRCONN channels with CHKCLNT(REQUIRED) set, using the installed MQ Explorer as the client. Variations included CHLAUTH enabled and disabled, channel Compatibility Mode on and off, and ADOPTCTX at both possible settings.
MQ has always had granular authorization provided by the Object Authority Manager. The problem introduced with client connections was that there was no authentication mechanism. Designing complex granular security models was of limited use when the client could assert the mqm User ID and the queue manager blindly accepted the assertion. Later CHLAUTH rules allowed the MQ administrator to map a source address, a certificate Distinguished Name, or an asserted User ID to some locally meaningful value. The certificate mapping was the closest any of these came to authentication.
The introduction of native password-based authentication to MQ finally changed all that. It is now possible to send an ID and password to MQ and have these authenticated against the local Operating System, against the Pluggable Authentication Module (PAM) in *nix platforms, or against an LDAP repository. The only problem is that by default there is no connection between the authentication and the authorization. The ID that was validated using the client-supplied password is not necessarily the ID the channel runs under and the configuration that decides that run-time behavior is at the client side of the connection.
The ADOPTCTX(YES) setting causes MQ to use the ID that goes with the password as the one the channel runs under. It binds the authentication to the authorization and gives most of the control back to the MQ admin. Unfortunately, it also removes all mapping functionality of the CHLAUTH rules. It is no longer possible to delegate authority by mapping an address, User ID, or certificate Distinguished Name to a target User ID.
Finally, the ID evaluated by the queue manager to match CHLAUTH rules changes across Fix Packs. In some cases it is the ID in the MQ Connection Data sent with the initial connection request. In some cases, it is the MQ Connection Security Parameters data sent later in the handshake. When these two data structures contain different user IDs the CHLAUTH behavior changes from Fix Pack to Fix Pack.
For complete details, please refer to the Google Sheet or PDF linked below.
The results were collected into a matrix. It is available as a Google Sheet, a PDF and an Excel spreadsheet. These are all downloadable from the Links page.
The scripts used in this research are published on GitHub. Originally I did not expect this project scope to explode the way it did so the testing is based on manually exercising of MQ Explorer against a local queue manager with a known set of channels and CHLAUTH rules. Likewise, monitoring of event messages is performed through manual inspection. The scripts switch the queue manager between combinations of ADOPTCTX, CHLAUTH rule types, and USERSRC(NOACCESS) for the different IDs presented by the client connections.
Over time I would like to generalize the scripts to eliminate hard-coded queue manager names and other dependencies, as well as automate the analysis of results. Pull requests are welcomed. Despite the lack of such features, the current implementation of these tools removes much of the heavy lifting from the testing process and provides consistency, repeatability, and speed.
My services are available directly through IoPT Consulting, or subcontracting through any of several resellers. I have over 20 years of experience focused exclusively in MQ. Although I’m focused strongly on security, I also cover architecture design, troubleshooting, clustering, high availability, and more, both as an instructor and on implementation/assessment projects.
I have made it my mission in life to improve the implementation of MQ both in the product itself and as it is practiced in the field. If you’d like to help me fulfill that mission, chances are I can help you achieve your MQ mission at the same time. Contact me by email or phone, on LinkedIn or as @tdotrob on Twitter.