MQAUSX/MQSSX versus WMQ v7.1 CHLAUTH

Last week, there was a robust/lively discussion on the MQSeries List Server regarding Derek Hornby’s question of (see http://comments.gmane.org/gmane.network.mq.devel/13985):

In the MQ V7.1 base install, a channel authentication record is created which is a “block user list” for all channels, and the block is on a User List of *MQADMIN

So I created a User Map record which allows the following:

– Channel Profile: MON.CHANNEL Address: 10.123.99.99 Client User: “monitor” MCAUser: “mqm”
– so I could allow my monitor program running on a client box to have “mqm” privileges against the Queue Manager
– but it gives me a 2035 (“MQ channel blah was blocked from address blah”) unless I remove the default block user list….

I thought the specific “allow” record which switches client ID “monitor” to MCAUser “mqm” would override the “block” record, but, unfortunately, it does not. (but it really should!)

And T.Rob Watt said:

Instead, keep the default rule and add another *blocking* rule to allow administrators on your specific channel:

set chlauth(MON.CHANNEL) TYPE(BLOCKUSER) USERLIST('nobody')

The final solution as given by T.Rob Watt was to add the following channel authentication records:

SET CHLAUTH('MON.CHANNEL') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) WARN(NO) ACTION(ADD)
SET CHLAUTH('MON.CHANNEL') TYPE(ADDRESSMAP) ADDRESS('10.123.99.99') USERSRC(CHANNEL) ACTION(ADD)

And T.Rob Watt commented:

So, yes, if somebody deletes the default *MQADMIN rule or defines a rule that overrides it to allow admin access AND DOES NOTHING ELSE then I suppose you are correct “the nobody rule opens a big security hole.” But I think it’s pretty clear that the intent was NEVER to define that rule without some kind of strong authentication. If any doubt remains, I’ll temporarily switch to HTML so I can write it in 80-point red letters:

ADMIN ACCESS MUST BE STRONGLY AUTHENTICATED

Here are my thoughts: if you need to implement authentication (or some filtering mechanism via an exit) with WMQ v7.1 channel authentication records then why not just use one solution?

How can you accomplish this (answering Derek’s question) with either MQAUSX or MQSSX? Simple, just use the following IniFile keywords with MQAUSX or MQSSX:

UseAllowIP = Y
AllowIP = 10.123.99.99;10.123.99.111
UseAllowUserID = Y
AllowUserID = monitor
Allowmqm = N
UseProxy = Y
ProxyFile=C:\Capialware\MQAUSX\proxy.txt

And in the proxy.txt file you would have:

monitor = mqm

Lines 1 & 2 of the IniFile define what incoming IP addresses will be allowed (the user can also use wildcards). Lines 3, 4 & 5 of the IniFile define what UserID is to be allowed. Lines 6 & 7 of the IniFile define that a Proxy file is to be used and the name and location of the Proxy file.

Hence, these simple, clear and easy keywords totally lock down the channel without requiring any MQ rules or other 3rd party products.

What is the difference between MQAUSX and MQSSX? MQAUSX provides full UserID and Password authentication whereas MQSSX is a filtering mechanism (no authentication).

Regards,
Roger Lacroix
Capitalware Inc.

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

Comments are closed.