Use MQGem tools with IBM MQ on IBM Cloud

You may have seen the recent announcement from IBM about the experimental IBM MQ service running on IBM Cloud.
IBM Cloud

You can learn more with these resources:-

When you read the description of this new service in the Bluemix catalog, you’ll see it says the following:-

Manage MQ your way

Manage your cloud-based queue managers with the tools you know and love – including MQ Explorer, the MQ Console, or via MQ Script Commands (MQSC).

This blog post is here to assure you that the tools you know and love from MQGem Software; MO71, MQSCX, MQEdit and QLOAD can all also be used with IBM MQ running on IBM Cloud.

Once you have created your MQ on IBM Cloud Service and Queue Manager, as shown in the above video, and your queue manager is up and running, you’ll have a view something like this.

IBM Cloud QM List

A list showing my Running queue manager

Click on the three vertical dots on the right of your queue manager to “Download Connection info”, or alternatively view the details of your queue manager and then there is a button there too which allows you to download the “Connection Information”. Either way, you’ll be presented with a pop-up which allows you to download a plain text file which contains the queue manager name, hostname, port number and a couple of channel names, one called an Application Channel and one called an Administration Channel.

IBM Cloud Download Connection info

IBM Cloud Download Connection info

In order to remotely connect to your IBM Cloud queue manager you will also need to be able to log in. As the MQ on IBM Cloud documentation describes here, you need the API key as your password to go with the user id ‘admin’. Follow the instructions on that page to obtain your API key.

Now you have all the pieces of information you need to set up any of the MQGem Software tools to administer your queue manager on IBM Cloud. As a reminder, these are the things you will need.

Item From where
Queue Manager Name You invented it when you created the queue manager. If you’ve forgotten it, it’s also in the text file you downloaded with the connection information.
Channel Name The “Administration channel name” can be found in the text file you downloaded with the connection information.
Connection Name This is built by concatenating the “Hostname” and “Listener port” details (with brackets round the port number) that can be found in the text file you downloaded with the connection information.
User ID This is ‘admin’
Password This is the API Key that you created by following the linked instructions.

On the pages that follow, we cover how to use the above information you have gathered in your table to configure each of our tools to connect to your IBM MQ in IBM Cloud Queue Manager. Go directly to the page for the tool you want to use, or page through each one in turn.

  1. MO71
  2. MQEdit
  3. MQSCX
  4. QLOAD

If you don’t have a licence and would like to try out any of our tools then send an email, noting which tool you’d like to try, to support@mqgem.com and a 1-month trial licence will be sent to you.

Advertisements

Behaviour changes in MQ V9.0.4 – CONNAUTH/CHLAUTH

UserID and PasswordIBM recently released it’s latest Continuous Delivery release (MQ V9.0.4). This has made some changes to the default behaviours for CONNAUTH and CHLAUTH. You can read all the new changes in V9.0.4 here, but I wanted to highlight a few I thought were very important.

Adopt Context is YES by default

From the introduction of Connection Authentication in IBM MQ V8, the default value of ADOPTCTX was NO. I am delighted to see that the default has now been changed to YES. This is probably the most common configuration problem we help customers with around the use of Connection Authentication. It’ll take a while to percolate through, because there are plenty of existing queue managers out there with ADOPTCTX(NO) but it will definitely improve things.

qm.ini ChlauthEarlyAdopt=Y is now the default

The qm.ini ChlauthEarlyAdopt attribute was added in IBM MQ V8 FixPack 5 to allow users to revert the behaviour back to the way it was prior to another change that was made – i.e. back to the designed IBM MQ V8 GA behaviour. I am very happy to see that IBM has now reverted this behaviour to be there by default for everyone.

Java clients use user ID and password in the same way as ‘C’ clients

Due to the historical use by the Java client of the FAP flow to send a user ID and password (as described in this blog post) a compatibility setting had to be provided at MQ V8 GA in case any Java Client connections into queue managers were relying on this behaviour for their security exits. This meant that Java clients and ‘C’ Clients operated differently by default. Now, as of V9.0.4, the Java client uses the MQCSP to send its user ID and password just as the ‘C’ client does and they both work the same way. This is very good news.

Using User ID and Password with a ‘C’ Application

“… but it works from MQ Explorer”

UserID and Password without V8It seems that the introduction of User id and Password checking in IBM MQ V8 is prompting many people to start looking at using User id and Password checking, even though they are not yet at V8. I’m sure this is a positive trend – unless of course it’s because people are throwing out SSL/TLS in favour of passwords – but that’s a story for a different time.

We’ve seen lots of discussions on this topic recently, with one common statement, “… but it works from MQ Explorer”.

‘C’ Applications vs Java Applications in IBM MQ

In the releases prior to IBM MQ V8 there are patchy mechanisms for using User id and Password checking, which can give you the same support as you get built-in at IBM MQ V8; but you need to be careful because they don’t all work the same way.

Used by Delivery Protocol QMgr-side Checks Examples
Java Client Historic FAP fields Security Exit pulling fields from the MQCD structure, RemoteUserIdentifier and RemotePassword CSQ4BCX3 Sample security exit shipped on z/OS
The MQAUSX Security Exit
‘C’ Client MQCSP across client channel Security Exit pulling fields from the MQCSP structure The MQAUSX Security Exit
Local Apps (dist) MQCSP across IPC Custom Authorization Service plug-in I’m not sure any vendor made one of these
Local Apps (z/OS) Nothing Nothing Nothing

One issue with the above that catches a lot of people out, is that they get a solution that works for the Java Client, for example the MQ Explorer, and then they find it doesn’t work with any ‘C’ Client applications, for example MO71. The sample exit, CSQ4BCX3 that is shipped with WebSphere MQ for z/OS is one such example.

User ID and password checking with IBM MQ V8

Lots has been written about Connection Authentication in other blog posts so I won’t reiterate all that here. You can read more by following these links:-

What I wanted to put in this section was the same table as above, but with the IBM MQ V8 Support, showing some of reasons why the Connection Authentication feature was needed.

Used by Delivery Protocol QMgr-side Checks
Java Client in Compatibility Mode Historic FAP fields Converted into MQCSP by the SVRCONN and driven through CONNAUTH
Java Client not in Compatibility Mode MQCSP across client channel MQCSP given to CONNAUTH
‘C’ Client MQCSP across client channel MQCSP given to CONNAUTH
Local Apps (dist) MQCSP across IPC MQCSP given to CONNAUTH
Local Apps (z/OS) MQCSP across PC call MQCSP given to CONNAUTH

As you can see the local applications on z/OS get provision in V8 where there was no prior solution, and there is a common solution between Java Clients and ‘C’ clients removing all that confusion in earlier releases.

Common solution without IBM MQ V8 everywhere

As you may notice from the above table, the architected delivery protocol for user id and passwords that can be common everywhere is the MQCSP. The way to get a common solution that can work for both Java and ‘C’ clients, and also future-proof you for when you move up to IBM MQ V8 in the future, is to base your solution on MQCSP.

The MQCSP structure was introduced into WebSphere MQ V6, so as long as your client and queue manager have that level as a minimum you can take advantage of that.

So you need something at the client side which can send an MQCSP for you. Your choices are:-

  • Use a WebSphere MQ V6 or above ‘C’ Client application
  • Use an IBM MQ V8 Java Client application with Compatibility Mode turned off
  • Use a client-side security exit, such as the mqccred exit shipped with IBM MQ V8 which you can use with older versions of the client. Some of the vendors that process MQCSP in a security exit on the queue manager side can also provide a client side exit to send an MQCSP – ask your vendor.

And you’ll also need something at the queue manager side which can receive and process an MQCSP for you. Your choices are:-

  • An IBM MQ V8 Queue Manager
  • One of the example Security Exits shown in the first table of this article, that process an MQCSP – so that rules out CSQ4BCX3, just to be clear.

You can mix and match these two lists as you need to.

Of course, there is one other thing to think about as you enable your user ID and password to flow from your client to your queue manager and that is to protect it as it flows across the network. Your choices are:-

  • Have a fully trust-worthy network!
  • Encrypt the connection, say with client-anonymous, one-way authenticated SSL/TLS
  • Have a pair of exits both sending and processing the MQCSP which also encrypt what they send – some vendor solutions offer this capability
  • Have IBM MQ V8 as the minimum at both ends, and the password will not be sent in the clear

Additional Resources


If you’re an exit vendor and would like your security exits listed in the above table, please get in touch, or leave a comment below and I’ll add you in.

What’s in Command Levels 801 and 802

MQ 801 Goody Bag

IBM MQ V8.0.0 Fix Pack 2 introduces a new Command Level, 801, and Fix Pack 3 introduces Command Level 802. Read What is an 801 Queue Manager? for details on how to enable these new Commmand Levels.

This post captures the changes that are available once you have an 801 or 802 Queue Manager.

LDAP Authorization

The V8.0.0 Connection Authentication feature which checked your user ID and password has been extended in V8.0.0.2 to allow LDAP authorization as well. The new fields that allow you to configure this on an AUTHTYPE(IDPWLDAP) Authentication Information object are protected by the 801 Command Level.

New Attribute MQSC name
See DEF AUTHINFO
Look for KC 8002 indicator
PCF constant and values
See Create Authentication Information
Look for KC 8002 indicator
LDAP Auth Method

AUTHORMD

  • OS
  • SEARCHGRP
  • SEARCHUSR

MQIA_LDAP_AUTHORMD (263)

  • MQLDAP_AUTHORMD_OS (0)
  • MQLDAP_AUTHORMD_SEARCHGRP (1)
  • MQLDAP_AUTHORMD_SEARCHUSR (2)
LDAP Group Object Class CLASSGRP

MQCA_LDAP_GROUP_OBJECT_CLASS (2133)

  • String of length MQ_LDAP_CLASS_LENGTH (128)
LDAP Base DN Group BASEDNG

MQCA_LDAP_BASE_DN_GROUPS (2132)

  • String of length MQ_LDAP_BASE_DN_LENGTH (1024)
LDAP Group Attr Field GRPFIELD

MQCA_LDAP_GROUP_ATTR_FIELD (2134)

  • String of length MQ_LDAP_FIELD_LENGTH (128)
LDAP Find Group FINDGRP

MQCA_LDAP_FIND_GROUP_FIELD (2135)

  • String of length MQ_LDAP_FIELD_LENGTH (128)
LDAP Group Nesting

NESTGRP

  • NO
  • YES

MQIA_LDAP_NESTGRP (264)

  • MQLDAP_NESTGRP_NO (0)
  • MQLDAP_NESTGRP_YES (1)

PAM Authentication

The V8.0.0 Connection Authentication feature which checked your user ID and password has been extended in V8.0.0.3 to allow PAM authentication as a choice. The new field that allows you to configure this on an AUTHTYPE(IDPWOS) Authentication Information object is protected by the 802 Command Level.

New Attribute MQSC name
See DEF AUTHINFO
Look for KC 8003 indicator
PCF constant and values
See Create Authentication Information
Look for KC 8003 indicator
Authentication Method

AUTHENMD

  • OS
  • PAM

MQIA_AUTHENTICATION_METHOD (266)

  • MQAUTHENTICATE_OS (0)
  • MQAUTHENTICATE_PAM (1)

Channel Status

Channels now show the security protocol in use – helping those people who were unsure how to answer the oft-asked question after the POODLE vulnerability, “are you still using an SSL CipherSpec?” Now instead of looking up your CipherSpec in the table in Knowledge Center, you can instead see this information output in the channel status display. Read more about this in Know your protocol.

New Attribute MQSC name
See DIS CHSTATUS
Look for KC 8002 indicator
PCF constant and values
See Inquire Channel Status
Look for KC 8002 indicator
Security Protocol

SECPROT

  • NONE
  • SSLV3
  • TLSV1
  • TLSV12

MQIACH_SECURITY_PROTOCOL (1645)

  • MQSECPROT_NONE (0)
  • MQSECPROT_SSLV30 (1)
  • MQSECPROT_TLSV10 (2)
  • MQSECPROT_TLSV12 (4)

AMQP Channel

In support of the MQLight in IBM MQ Beta, there is a whole new channel type with an associated set of channel attributes added. This is not yet documented in Knowledge Center but is visible when operating a queue manager at Command Level 801, and in the header files for PCF applications. Along with the Beta download that enables some of these attributes, there is a PDF of instructions on how to use the attributes available at the above link for the Beta. Be aware that although you can view and set all these attributes, not all of them are implemented by the current Beta. Get involved with the Beta program and read the PDF file mentioned above to see which attributes are currently usable.

New Attribute MQSC name PCF constant and values
Channel Type

CHLTYPE

  • AMQP

MQIACH_CHANNEL_TYPE (1511)

  • MQCHT_AMQP (11)
Description DESCR

MQCACH_DESC (3502)

  • String of length MQ_CHANNEL_DESC_LENGTH
Port PORT

MQIACH_PORT (1522)

  • Value in the range 1 – 65335
Local Address LOCLADDR

MQCACH_LOCAL_ADDRESS (3520)

  • String of length MQ_LOCAL_ADDRESS_LENGTH
SSL/TLS Certificate Label CERTLABL

MQCA_CERT_LABEL (2121)

  • String of length MQ_CERT_LABEL_LENGTH
SSL/TLS Cipher Spec SSLCIPH

MQCACH_SSL_CIPHER_SPEC (3544)

  • String of length MQ_SSL_CIPHER_SPEC_LENGTH
SSL/TLS Client Auth SSLCAUTH

MQIACH_SSL_CLIENT_AUTH (1568)

  • String of length MQ_SSL_CIPHER_SPEC_LENGTH
SSL/TLS Peer Name SSLPEER

MQCACH_SSL_PEER_NAME (3545)

  • String of length MQ_SSL_PEER_NAME_LENGTH
Alteration Date ALTDATE

MQCA_ALTERATION_DATE (2027)

  • String of length MQ_DATE_LENGTH
Alteration Time ALTTIME

MQCA_ALTERATION_TIME (2028)

  • String of length MQ_TIME_LENGTH
AMQP Keep Alive AMQPKA

MQIACH_AMQP_KEEP_ALIVE (1644)

  • Values in the range 0 – 99 999
  • MQKAI_AUTO
Use Client Identifier

USECLTID

  • YES
  • NO

MQIACH_USE_CLIENT_ID (1629)

  • MQUCI_YES (1)
  • MQUCI_NO (0)
Max Message Length MAXMSGL

MQIACH_MAX_MSG_LENGTH (1510)

  • Values in the range 0 – 100MB
MCA UserId MCAUSER

MQCACH_MCA_USER_ID (3527)

  • String of length MQ_MCA_USER_ID_LENGTH
Max Instances MAXINST

MQIACH_MAX_INSTANCES (1618)

  • Values in the range 0 – 999 999 999

Display Connection

With the introduction of the AMQP channel in CommandLevel 801, there is also a new attribute returned when you display application connections.

New Attribute MQSC name
See DIS CONN
Look for KC 8002 indicator
PCF constant and values
AMQP Client ID CLIENTID

MQCACF_AMQP_CLIENT_ID (3207)

  • String of length MQ_AMQP_CLIENT_ID_LENGTH (256)

Queue Manager Object

With the introduction of the AMQP channel in CommandLevel 801, there is also a new attribute on the queue manager object.

New Attribute MQSC name PCF constant and values
AMQP Capability

AMQPCAP

  • NO
  • YES

MQIA_AMQP_CAPABILITY (265)

  • MQCAP_NOT_SUPPORTED (0)
  • MQCAP_SUPPORTED (1)

You can get the equivalent information for earlier Command Levels from these posts.


IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson   Twitter: https://twitter.com/MoragHughson   SlideShare: http://www.slideshare.net/moraghughson

MQGem tools can use Connection Authentication

When MQGem Software announced support for IBM MQ V8, one of the features included was:-

Both MO71 and MQSCX allow the provision of a user ID and password which can be validated by an MQ V8 queue manager.

In this post more detail about that support will be described.

MO71 supports Connection Authentication

When you manage a queue manager with the MO71 GUI Administrator, you make a connection to that queue manager. This connection is subject to the same rules as any other connection to a queue manager, so if the queue manager requires a password, you need to provide one. To do so in MO71, you specify this in the location dialog for the queue manager. Open the location dialog, either with Ctrl+O or by selecting the right-mouse context menu and choosing Open Location… for the selected queue manager.

MO71 Location Security

The Security tab on the Location dialog is where you configure MO71 to send a password

In the location dialog, switch to the Security tab and ensure that:-

  • Userid and Password is ticked
  • Security Exit Only is unticked
  • and make a choice about whether you want the password to be cached for you to save typing it in every time by ticking Store in cache file

MO71 PasswordFrom this dialog you can also choose to Set Password right away, thus caching it for use next time you connect to the queue manager. If you don’t do this, you’ll get the same dialog as a pop-up the next time you try to connect to the queue manager at which point you can type in the password then. Once you have successfully connected, the password will be saved to stop you having to type it in every time. This will be remembered until MO71 is restarted, or for longer if you enable the password cache file.

Password Cache File

To enable use of the password cache, open the Preferences dialog, either with Ctrl+P or by choosing menu File->Preferences… The settings you want are on the Connection tab. To use it, simply make sure that Use Cache File is ticked.

MO71 Password Cache File

The preferences dialog, Connection tab, allows the configuration of the password cache file

The password cache file is by default called MQMON.PWC and is created in the same directory as the MO71 config file, MQMON.CFG. If you need to change this then you can nominate a new password cache file somewhere else. If your config file for MO71 is shared, but you want separate password cache files, then you can make use of an environment variable to vary the location for the file, for example %USERPROFILE%. Whichever way you choose to dictate the location of the file, the actual file location will be shown in the preferences dialog. On first use of the cache file it will be created and you will be requested to create a password for the file. This will be the only password you need to type to allow MO71 to use passwords that it has saved for all your queue managers.

The queue manager’s password from the cache will be used until such time as it fails, and then you will be prompted to provide the password anew. You can reset it at any time before it fails from the location dialog.

MQSCX supports Connection Authentication

When you configure a queue manager with the MQSCX command line tool, you make a connection to that queue manager. This connection is subject to the same rules as any other connection to a queue manager, so if the queue manager requires a password, you need to provide one. To do so in MQSCX you include a user, and optionally a password, on the =conn command. If you provide the password it will be used, but alternatively, if you use pwd(*) then you will instead be prompted for the password which will keep the string you type obscured and not visible in the command stream.

MQSCX Extended MQSC Program – Version 8.0.0

Licenced to Paul Clarke

> =conn qm(MQGEM) user(Paul) pwd(*)

MQSCX Extended MQSC Program – Version 8.0.0

Licenced to Paul Clarke

QM(MQGEM) User(Paul) password > ********

MQSCX Extended MQSC Program – Version 8.0.0

Licenced to Paul Clarke

[14:05:31] =conn qm(MQGEM) user(Paul) pwd(*)

Connected to 'MQGEM'

MQGEM>

Using pwd(*) also means the MQSCX will remember the password for future =conn commands to the same queue manager until MQSCX is restarted.

If you’d like to try out either of these products, and you are not currently a licence holder, you may email support@mqgem.com to request a trial licence.


For more information about IBM MQ and the Connection Authentication feature, read IBM MQ V8 Connection Authentication – More Information.