WebSphere MQ v7.1 and MQAUSX

Capitalware has begun testing MQAUSX with WebSphere MQ (WMQ) v7.1 and everything is working very well. There are 2 items that everyone needs to be aware of when using MQAUSX with WMQ v7.1.

1. WMQ v7.1 has a new feature called Channel Authentication Records. (A poor name as no authentication is actually taking place. IBM should have called it Channel Authorization Records)

When a new queue manager is created, the Channel Authentication Records feature is enabled ‘CHLAUTH(ENABLED)’ (it is disabled when you do an upgrade) and there is a ‘Per-Channel’ rule that blocks all access for MQAdmins.

   DESCR('Default rule to disallow privileged users') +

This rule needs to be deleted or you can disable the Channel Authentication Records feature.

To delete the CHLAUTH rule issue the following MQSC command via runmqsc:


To disable Channel Authentication Records, issue the following MQSC command via runmqsc:


2. I think IBM changed compilers on Windows. MQAUSX and its LDAP components worked fine with MQ v5.2, v5.3 and WMQ v6.0, v7.0 and v7.0.1. Something in how IBM built MQ v7.1 caused MQ to not like MQAUSX’s mqausxldap.dll module. Note: This is a Windows only issue.

MQAUSX LDAP calling sequence on Windows:
MQ/MCA –> mqausx.dll –> mqausxldap.dll –> ldapsdk.dll –> Remote LDAP server

MQ/MCA can load mqausx.dll without any issue. It was only when mqausx.dll tried to load mqausxldap.dll that the problem occurred (unable to load DLL : 487). After playing around with a bunch of Visual Studio linker options, I was able to get everything to load normally.

If you are running WMQ v7.1 and MQAUSX v1.5.0 on Windows and MQAUSX is using the LDAP authentication feature, then send an email to support@capitalware.biz for the latest build of MQAUSX for Windows.

Roger Lacroix
Capitalware Inc.

This entry was posted in Capitalware, IBM i (OS/400), Linux, MQ, Security, Unix, Windows.

7 Responses to WebSphere MQ v7.1 and MQAUSX

  1. Michael says:

    I disagree to disable the CHLAUTH or delete the rule!!!

    If you need *MQADMIN access on any specific channel, then overrule the generic block with a specific rule like

    SET CHLAUTH('MYADMIN.CHL') TYPE(BLOCKUSER) DESCR('My Administration Channel allow *MQADMIN') USERLIST('nobody')

    this rule lifts the ‘block’ on this channel (mis-using nobody), so you can get in with *MQADMIN priviliges…
    you can use Block Address or SSL PEER MAP to restrict other access to this channel as it ‘is’ open to *MQADMIN now…

    • Hello Michael,

      The title of the blog posting is “WebSphere MQ v7.1 and MQAUSX“. You do NOT need the rule because MQAUSX will handle the ‘nobody’ UserID and EVERY other UserID that a rogue user may attempt to connect to the queue manager with.

      Roger Lacroix
      Capitalware Inc.

      • Michael says:

        OK get your point, if you use MQAUSX already then it’s a valid option… otherwise I would not do it…

        remember this is the same trap how IBM once opened up the hole in the first place… cause java programmers complained about 2035 errors too much… 🙁

        • Hello Michael,

          remember this is the same trap how IBM once opened up the hole in the first place… cause java programmers complained about 2035 errors too much

          That’s not entirely true. IBM decided that in a JVM there is no guarantee that a JVM UserID will be set, so the MQ Java library code will not set an MQ UserID and leave it for the developer to set a MQ UserID. Which of course, they don’t.

          Also, the other giant security hole was deliberately opened up by IBM. Here can read an interview I did a couple of years ago about MQ security: http://www.itjungle.com/fhs/fhs032409-story01.html

          “When NT 5 was coming to market, there was a great fear at IBM because Microsoft was coming out with embedded MSMQ [Microsoft Message Queue],” Lacroix says. “So IBM turned around and basically said, ‘We’re going to make MQ Series the same way Microsoft makes Windows: Super easy. We’re not going to worry about security. You can add it after the fact.’ They had this great fear that Microsoft was going to eat their lunch.”

          I was at the 1998 MQ / CICS Conference in Washington DC and there was definite fear in the air regarding Microsoft and the forth coming Windows NT 5 (ultimately named Windows 2000) which would include MSMQ for free.

          Roger Lacroix
          Capitalware Inc.

  2. T.Rob says:

    Deleting the CHLAUTH rule opens remote administrative access on *all* channels. Wouldn’t it be better to leave it in and override it with a new rule to allow administrative access on the specific channel(s) where admins should actually be connecting?

    • Hello T.Rob,

      The rule duplicates functionality in MQAUSX. It is far, far better for an MQAdmin who is using MQAUSX to do all of the security settings (authentication & control) from one product (i.e. MQAUSX).

      First, MQAUSX will perform true authentication of the incoming UserID and Password against a target: local OS system, LDAP server, Microsoft’s Active Directory, Quest Authentication Services (QAS), Centrify’s DirectControl or an encrypted MQAUSX FBA file.

      Second, MQAUSX can then filter/control who is allowed or who should be disallowed:

      Allow (whitelist) features:
      – AllowIP – Allow or Restrict the Incoming IP Address
      – AllowHostname – Allow or Restrict the Incoming Hostname
      – AllowHostByName – Allow hosts by name
      – AllowSSLDN – Allow or Restrict the Incoming SSL DN
      – AllowUserID – Allow or Restrict the Incoming UserID
      – AllowADName – Allow or Restrict the Incoming Active Directory Server Name (Windows only)

      Reject (blacklist) features:
      – RejectIP – Reject the Incoming IP Address
      – RejectHostname – Reject by Hostname
      – RejectHostByName – Reject hosts by name
      – RejectSSLDN – Reject the Incoming SSL DN
      – RejectUserID – Reject the Incoming UserID
      – RejectADName – Reject the Incoming Active Directory Server Name (Windows only)

      An MQAdmin can use MQAUSX LDAP Search feature to restrict UserIDs based on ANY group in the LDAP server not just the mqm group.

      Roger Lacroix
      Capitalware Inc.

      • T.Rob says:

        OK, that makes sense. Use one or the other but generally don’t try to do half your security in one and half in the other since the potential interactions and added complexity may lead to problems.

        I would guess it’s possible to use MQAUSX solely for the ID and password validation and move the authorization aspects to the CHLAUTH rules. However in mixed environments it is often advisable to use the method which works across the entire environment. So I would expect many shops with MQAUSX might follow the advice in the post so that they could keep the configurations consistent.