Worked Example: Solving MQRC_NOT_AUTHORIZED

MQRC_NOT_AUTHORIZED (2035) can result from a number of different causes (CHLAUTH rules, CONNAUTH settings, and missing Authorities). This post is going to provide a worked example of solving your MQRC_NOT_AUTHORIZED failure when missing authorities are the reason.

You might guess that it’s missing authorities because you have disabled CHLAUTH and CONNAUTH (please don’t – read this for another worked example for leaving those security features on), or because you have looked in the AMQERR01.LOG and seen a message like the following. If the latter, well done, you are already well on your way to solving the issue.

AMQ8077W: Entity 'mqgusr1' has insufficient authority to access object MQG2 [qmgr].

EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against the required object, or ensure that the entity is a member of a privileged group.

To fix this issue you are going to grant the missing authority. However, it is more appropriate to grant it using the group than the user id. So first, we should find out what group this user ID is in.

Discover group (Linux/Unix)

Issue a command like the following.

id -Gn mqgusr1

The output will be a list of the groups this user is a member of.

Discover group (Windows)

Issue a command like the following.

net user mqgusr1

You will see output like this.

Local Group Memberships      *mqgemadm             *Users

While the user may be a member of a number of groups, there should be one that is clearly the MQ related group name where these authorities should be granted. For the purposes of my example, this is a group called mqgemadm because I am trying to use this user id to connect to MQ and display some queues.

Now that we know the group name to use – all the other information we need to build up our authority granting command is available in the error message. Here is a table of the information we found and where we found it.

Required Info	Value	Source of Value
Entity Type	Group	Best practice decision
Entity	mqgemadm	Looking up reported users group membership
Object Type	Queue Manager	Error message title line “[qmgr]”
Object Name	MQG2	Error message title line “… object MQG2 …”
Authority required	connect	Error message EXPLANATION section

From this table we can build up an MQSC command to grant the missing authority. We either issue this command from a privileged user Id, or add it to our queue manager start-up script. I suggest doing the former as there are going to several of these commands needed. Once you’ve completed the exercise it might be appropriate to gather up the commands that were needed for future use to put into such a script.

You’ll notice that there is no need to mention the object name in the following command because it’s the queue manager object and there is only one. Some people add it in and some use OBJNAME(SELF) but it can simply be omitted.

SET AUTHREC OBJTYPE(QMGR) GROUP('mqgemadm') AUTHADD(CONNECT)

So now, we run the application again, and it fails again, with the same reason code. Nothing has changed!

Well actually something has changed. If you look in the AMQERR01.LOG file for the latest error it looks like this.

AMQ8245W: Entity 'mqgusr1' has insufficient authority to display object MQG2 [qmgr].

EXPLANATION:
The specified entity is not authorized to display the required object. The following requested permissions are unauthorized: dsp

So, something has changed. Rather than reporting that we don’t have connect authority it is now reporting that we don’t have display (dsp) authority. As before we can build up an MQSC command to grant the missing authority.

SET AUTHREC OBJTYPE(QMGR) GROUP('mqgemadm') AUTHADD(DSP)

So now, once more, we run the application again, and it fails again, with the same reason code again. However, we’re familiar with this now. It’s not the same issue, just the same reason code. So, again, we look in the AMQERR01.LOG file for the latest error. In my example, the next error looks like this.

AMQ8077W: Entity 'mqgusr1' has insufficient authority to access object SYSTEM.ADMIN.COMMAND.QUEUE [queue].

EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: put

Let’s build up a table of our pieces of information like we did earlier.

Required Info	Value	Source of Value
Entity Type	Group	Best practice decision
Entity	mqgemadm	Looking up reported users group membership
Object Type	Queue	Error message title line “[queue]”
Object Name	SYSTEM.ADMIN.COMMAND.QUEUE	Error message title line just before “[queue]”
Authority required	put	Error message EXPLANATION section

As before, we can use this information to build up an MQSC command to grant the missing authority. Now we also have an object name, so this command will look slightly longer than the previous ones you saw.

SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) GROUP('mqgemadm') AUTHADD(PUT)

I hope that is enough of an example to illustrate the technique. Just keep viewing the AMQERR01.LOG and finding the reported missing authority and fixing it with the appropriate MQSC AUTHREC command (or the equivalent setmqaut command if you prefer). Look at the error messages closely as all the information you need is in there.

MO71 version 9.0.3 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

You can now export Authority Records along with all your other objects

Export of AUTHREC in MQSC format

This was one of the most commonly requested features. You can now export AUTHREC definitions in MQSC format from the object and list dialogs as well as include AUTHRECs in the automatic Queue Manager export list.

API Exerciser enhancements

We are pleased to say that this version allows you to experiment with the MQCONNX, Message Handle and Message Property API calls. More information will be coming soon in another blog post.

Hostname display

When displaying a Channel Status output, MQ will send you the IP address eg.198.51.100.34. However, this is not hugely memorable. You can now ask MO71 to issue a gethostbyaddr() and display the result in a hostname field. You can go even further and put your own description of this in a dns file, MQMON.DNS, and have MO71 display that instead. Read more about this in Displaying host names in MO71.

User Commands

You can define your own commands which are then available in the Queue Manager context menu. Read more about this in Running User Commands in MO71.

Message Operations are now Message Token based

By basing message operations on Message Tokens the message operations such as browse, copy, mode and delete are much faster and more specific.

Can now invoke the MQEdit Message Editor directly

When you are browsing a message you can select ‘Edit…’ from the context menu and the MQEdit product will be started editing the same message, saving you having to re-navigate to that message in another tool. This is possible through the use of Message Tokens. You can also open the MQEdit product from a queue list and a single queue dialog and it will open with the messages from that queue already loaded into the list. Ensure you have MQEdit V9.0.1 (or higher) in order to do this. If you don’t have a licence for MQEdit, these options will not be available.

If you have the MQEdit product, you’ll get an Edit option

New Default Max. Column preference option

Some MQ fields can now be quite large, for example topic strings, subscription names and subscription selectors. This can mean that lists of objects can be have columns which are wider than you would like. You can now say how wide the column should be by default, and a new ‘…’ indicator shows if there is more to be seen than the column is currently displaying.

‘…’ indicator shows the column is truncated

‘…’ indicator shows the column has more to show

New Max Column and Field lengths for HTTP browser output

As above these large MQ fields can mean that the browser output is hard to read or it results in an output with a large horizontal scrollbar. You can now tell MO71 how much data to return in these situations.

More CipherSpecs considered weak

IBM recently updated the list of weak CipherSpecs to include those using the Triple DES algorithm, and so MO71 will not show you those CipherSpecs by default. You can ask MO71 to show you the weak ones in the Location dialog for the queue manager in question, but you will also need to enable them in MQ too if you want to use them. Read more about how in Deprecated CipherSpecs

Support for Command Level 902

UPDATE: With a minor update to MO71 after the release of IBM MQ Continuous Delivery Release 9.0.2, support for Command Level 902 has been added. Read more about the new command level in What’s in Command Levels 90x.

---

The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Translate from setmqaut to SET AUTHREC

IBM MQ on the distributed platforms have commands to grant authorities to groups and users, in order to allow them access to use resources on a queue manager. There are actually three exactly equivalent command interfaces to do this.

• setmqaut
  This was historically the first command interface. It is a control command, issued from the command line by a user who is a member of the mqm group.
• Set Authority Record
  Next the PCF flavour of the command was implemented allowing the MQ Explorer (and other remotely connected tools such as MO71) to be able to issue these commands.
• SET AUTHREC
  Finally, and most recently, the MQSC flavour of the command was implemented, allowing authority commands to co-exist in scripts along with object definitions.

When using a queue manager on the MQ Appliance, there is no setmqaut command. You are expected to either use a GUI with the PCF commands, or the MQSC scripting language and a SET AUTHREC command. In general the queue manager on the MQ Appliance is just like any other queue manager, and you may well be following some instructions to set up something on your appliance queue manager, but those instructions only provide examples with the setmqaut command.

This post is going to help you translate from an example setmqaut command to a SET AUTHREC command.

Here’s a couple of example commands that cover all the main switches you might see on a setmqaut command (although not all the values).

setmqaut -m QM1 -t qmgr -g mqgadm +connect

setmqaut -m QM1 -t queue -n WORK.Q -p mqgusr -all +put +get

Sometimes it’s easier to see this sort of thing diagrammatically. So first I show a picture and then below is a table to step through each switch.

setmqaut mapped to SET AUTHREC

Here’s a table to map from setmqaut to an MQSC SET AUTHREC.

setmqaut	→	SET AUTHREC	Notes
setmqaut	→	SET AUTHREC	Instead of using the setmqaut command, you’re going to use the SET AUTHREC command.
-m QM1	→	runmqsc QM1	MQSC commands are directed to the queue manager your MQSC issuing tool, such as runmqsc is connected to, so it’s not part of the SET AUTHREC command, instead it’s the direction to runmqsc to tell it which queue manager to connect to.
-t queue	→	OBJTYPE(QUEUE)	The -t switch becomes the OBJTYPE parameter and it’s value could be exactly the same, except for cases when setmqaut uses shortened forms. For example -t q is the same as -t queue. If you know your IBM MQ object names from other MQSC commands, then you’ll have no trouble figuring out which one is which.
-n WORK.Q	→	PROFILE(WORK.Q)	The -n switch becomes the PROFILE parameter. It’s called a profile rather than an object name since it could have wildcards in it. The value that went with the -n goes inside the brackets. One thing to remember though, MQSC will upper case anything that you don’t put inside quotes, so if your profile name is not upper case, add quotes around it. In the case of -t qmgr, there will be no -n switch, and you can omit the PROFILE parameter.
-g mqgadm	→	GROUP(‘mqgadm’)	The -g switch becomes the GROUP parameter and the value goes inside the brackets. Remember to use quotes.
-p mqgusr	→	PRINCIPAL(‘mqgusr’)	The -p switch becomes the PRINCIPAL parameter and the value goes inside the brackets. Remember to use quotes.
-all	→	AUTHRMV(ALL)	Any authority switches with a ‘-‘ sign are being removed. These should go in the comma-separated list in the AUTHRMV parameter. It is often seen that -all is used because adding a few authorities, in order to remove everything before adding new ones so you know where you are. Normally you wouldn’t combine AUTHRMV and AUTHADD parameters, but the use of ALL is one of the cases where it is allowed.
+put +get	→	AUTHADD(PUT,GET)	Any authority switches with a ‘+’ sign are being added. These should go in the comma-separated list in the AUTHADD parameter. The authority switches are spelled the same in both setmqaut and SET AUTHREC, just remove the ‘+’ (or ‘-‘) prefix.

If you come across a setmqaut command that you can’t translate into a SET AUTHREC with the above instructions, add it in the comments, and I’ll help you out. It’ll also improve this blog post for others.

---

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on:

Novel use of sorting

When writing an MQSCX script you can create arrays of data and then sort them. This is aptly demonstrated by a new example script, mqauthlist.mqsx, available in our Example Scripts bundle. This script generates a report, which is sorted into a very specific order before being written out to a file. The way this sorting is done is very novel, and so we thought it worth writing about for you to see.

This sorting of the results is done so that within each Entity (and each Entity Type), the Object Types are listed in a specific order. This is done by generating a field whose sole purpose is to be sorted.

This field starts with the character 0 or 1 to represent a Group or a Principal, resulting in all the groups being sorted together and then all the Principals being sorted together. Then it has the 12 byte padded entity name (be that a Group or a Principal). Here’s the first part of how the field was constructed.

** Create a special field that will be used to sort the authorization
** records into the order that we want them to appear in the report.
** Generate the SortField as a combination of EntityType, Entity, Objtype, Profile
delvar(@sortfld)
if( @a_enttype = "GROUP" )
  @sortfld = str(0)
else
  @sortfld = str(1)
endif
** pad the entity to 12 bytes
@sortfld = @sortfld + @a_entity + substr("                ", 1, 16 - strlen(@a_entity))

Following the entity name is a two-character value for each Object Type, with those two-characters assigned based on the order the report author wanted the objects to be listed in the report – within each user. Finally it has the profile name, so that within each Object Type, the objects are sorted too. Here’s the remainder of how the field was constructed.

** assign a numeric value to the object type so they sort
** in the order we want them to appear in the report
if(@a_objtype = "QUEUE") @sortfld = @sortfld + str(12); endif
if(@a_objtype = "TOPIC") @sortfld = @sortfld + str(13); endif
if(@a_objtype = "PROCESS") @sortfld = @sortfld + str(14); endif

** add the profile
@sortfld = @sortfld + @a_profile

** Add the authorization record into the array
@i = @i + 1
@auths[1, @i] = @sortfld

All the above code takes place in a for loop that goes through each authorization record returned by the DISPLAY AUTHREC. Once that loop is complete, then the array that was created is sorted very simply, using the sort function with the second parameter indicating with column to use to sort the array:-

** Sort the array by sortfld
sort(@auths, 1 )

As you can see, not only is MQSCX able to allow you to write reports to process the interrogations you make of the Queue Manager via the Command Server, the MQSCX Control language is also extremely flexible.

---

The best way to understand scripts is of course to have a go with them yourself. There are various examples in the download, so why not try them out yourself. If you are not currently an MQSCX licence holder, you may email support@mqgem.com to request a trial licence.

MQSCX feature – CommandLevel and Platform

In an early version of MQSCX, two features were introduced which allow you to discover the Command Level and Platform of the queue manager that the script is currently connected to.

The Command Level feature is aptly demonstrated by a new example script, mqauthlist.mqsx, available in our Example Scripts bundle. This script uses the DISPLAY AUTHREC command to interrogate the queue manager for the current authorisation settings for the queue manager. This command is only available at a command level of 710 or above, and the script utilises a new MQSCX system variable, _cmdlevel to check for this before attempting to issue any such commands. Here’s how:-

** QMgr must be at command level 710 or greater to use this script.
if( _cmdlevel < 710 )
   fprint @hf,"QMgr does not support authorization record queries."
   fprint @hf,"Command Level must be 710 or greater.",_nl
   continue
endif

Although not illustrated in this script, the other new MQSCX system variable which goes hand-in-hand with _cmdlevel is _platform which allows you to check the platform of the queue manager is as expected before doing something in a script that is dependent on a particular platform.

The values of _cmdlevel and _platform are the same values that you would see if you issued the MQSC command:-

DISPLAY QMGR CMDLEVEL PLATFORM

when the script is connected to a queue manager, and -1 and NOTCONNECTED respectively when the script is not connected to a queue manager.

---

The best way to understand scripts is of course to have a go with them yourself. There are various examples in the download, so why not try them out yourself. If you are not currently an MQSCX licence holder, you may email support@mqgem.com to request a trial licence.

A non-privileged MQ administrator

The developerWorks Connections platform, which hosted the AIM Support Blog, was sunset as of 31st December 2019. The blog post below was something I wrote previously on that platform, and since I consider it to still be useful, I am now hosting a copy here. I have retained the original posting date but in this case have been unable to retain the original comments as the post had already been deleted by early December. View all saved from sunset posts here.

With the new feature in WebSphere MQ V7.1 called Channel Authentication Records (or CHLAUTH for short) there is a lot of talk about privileged users and administrator access. In this post I want to discuss how to create a non-privileged MQ administrator.

Before I begin let me define what I mean by each of those terms.

Privileged user

A privileged user is a user that has authorization to do an operation without being explicitly granted access to do that operation. The users in the mqm group are examples of these privileged users, but of course this does differ a little from platform to platform, so rather than using the term ‘mqm user’ I will use the term privileged user.

MQ Administrator

A lot of people use the term ‘administrator’ to mean a privileged user. In this post, I am using it to mean a person who has a need to issue administrative commands against WebSphere MQ, such as DEFINE QLOCAL or START CHANNEL. This person does not have to be a privileged user, as we will see.

Now let’s see how we can put the two together.

Creating a non-privileged MQ Administrator

Here are some simple steps to get you to the point where you have a non-privileged MQ Administrator:

1. The first thing we need is a user ID on the queue manager machine that is not a privileged user. I will not show the commands to do this here as they are platform dependent. I will use the user ID ‘alice’ from the group ‘mqadmin’ for my example.
2. Now that we have this user, there is a very quick way to grant this new user authority to issue all MQ admin commands.
   • Start up the MQ Explorer using a privileged user.
   • Navigate to the Role Based Wizard from the queue manager → Object Authorities → Add Role Based Authorities…
   • In the wizard panel that pops up, enter the group name for the user or set of users that you wish to make into non-privileged MQ Administrators.
   • This wizard can set up two different types of access, read-only access or full administrative access. We want full administrative access for our purposes.
   • If you want to allow your non-privileged MQ Administrator to be able to browse messages on queues, also select that check box.
   • Review the commands in the preview panel at the bottom of the wizard. You can cut and paste these commands to build your own scripts. One reason you may prefer to do this with your own script is to reduce the amount of access you give to this user. Perhaps rather than granting access to all objects, you might prefer to only grant access to a certain group of objects. Pressing OK on the wizard will actually issue the commands as they are shown.
3. We assume the requirement for a non-privileged MQ Administrator is for remote access, so we’ll also want to set up some CHLAUTH rules to allow this remote access to use this user ID. We assume that we’re running with the recommendations made in CHLAUTH – the back-stop rule and that we just therefore need to add an enabling rule. The rule we create rather depends on how we choose to authenticate our remote MQ Administrators. Here are a couple of possibilities.
   1. If we are using password authentication (with an address check) then we might set up a CHLAUTH rule which looks like this:-

      SET CHLAUTH(admin-channel-name)
          TYPE(ADDRESSMAP) ADDRESS('1.2.3.4')
          USERSRC(MAP) MCAUSER('alice')
          CHCKCLNT(REQUIRED)
          DESCR('Admin Channel - Password authentication')

   2. If we are using SSL/TLS authentication then we might set up a CHLAUTH rule which looks like this:-

      SET CHLAUTH(admin-channel-name)
          TYPE(SSLPEERMAP) SSLPEER('CN=Alice') ADDRESS('1.2.3.4')
          USERSRC(MAP) MCAUSER('alice')
          DESCR('Admin Channel - SSL authentication')

So now when someone connects into the admin-channel-name (and matches the CHLAUTH rules) they will be able to issue commands under the user ID ‘alice’ on the queue manager, and so privileged remote access is not required.