WAS连接MQ出现2035 MQRC_NOT_AUTHORIZED问题的解决

56 阅读 0 评论 37 点赞

我是靠谱客的博主高挑小虾米，最近开发中收集的这篇文章主要介绍WAS连接MQ出现2035 MQRC_NOT_AUTHORIZED问题的解决，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Question

You create a new queue manager in WebSphere MQ 7.1 or 7.5 or later and you try to use a user id that is an MQ Administrator to remotely access the queue manager via a client connection. You get an error with reason code 2035:

2035 MQRC_NOT_AUTHORIZED

The MQ Administrator can remotely access without problems other MQ queue managers at version 6 or 7.0.x.

Cause

You created a new queue manager in MQ 7.1 or in 7.5 or later. The default value for the new feature introduced in 7.1, "Channel Authentication Records" (CHLAUTH) is ENABLED. You can see the value by using runmqsc:

$ runmqsc QmgrName
DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) CHLAUTH(ENABLED)

By default, the following 3 channel authentication records are generated when a new queue manager is created in 7.1 or upgraded to 7.1:

DISPLAY CHLAUTH(*)
1 : DISPLAY CHLAUTH(*)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN)

The last record blocks all remote channel access to any MQ Administrator. The effect is that non-administrative users can still connect if suitably authorized to do so, but administrative connections and anonymous connections are disallowed regardless of any Object Authority Manager (OAM) authorization settings. This means that new queue managers in V7.1 are much more secure by default than in previous versions, but with the trade off that administrative access must be explicitly defined.

+++ Additional notes:

a) If you upgraded a queue manager to MQ 7.1 this new feature is NOT enabled by default.

$ runmqsc QmgrName
DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) CHLAUTH(DISABLED)

However, this new feature can be enabled by issuing the following command in runmqsc:
ALTER QMGR CHLAUTH(ENABLED)

b) You use the MQ Explorer to remotely access the newly created 7.1 queue manager and get the following errors:

Text inside the dialog box:
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.

After closing the above dialog, the next one appears:

Text inside the dialog box:
An error occurred connecting to queue manager 'QM_71 on 'host.x.com(14xx)''. Are you sure that you want to show this queue manager in the folder anyway? (AMQ4027)
Severity: 10 (Warning)
Explanation: A connection could not be made to the specified remote queue manager.
Response: Ensure that the named queue manager is running on the host and port specified, and has a channel corresponding to the specified name. Ensure that you have the authority to connect to the remote queue manager, and ensure that the network is running. Select Yes if you believe that the problem can be resolved later. Select No if you want to correct the problem now and try again.

c) In the error log for the queue manager you see either the error AMQ9776 or AMQ9777, followed by AMQ9999

c.1) AMQ9776: Channel was blocked by userid
EXPLANATION: The inbound channel 'SYSTEM.ADMIN.SVRCONN' was blocked from address
'9.49.x.x' because the active values of the channel were mapped to a userid which should be blocked. The active values of the channel were 'MCAUSER(rivera) CLNTUSER(rivera)'.
ACTION: Contact the systems administrator, who should examine the channel authentication records to ensure that the correct settings have been configured. The ALTER QMGR CHLAUTH switch is used to control whether channel authentication records are used. The command DISPLAY CHLAUTH can be used to query the channel authentication records.

c.2) AMQ9777: Channel was blocked
EXPLANATION:The inbound channel 'SYSTEM.DEF.SVRCONN' was blocked from address '127.0.0.1'
because the active values of the channel matched a record configured with USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER()'.
ACTION: Contact the systems administrator, who should examine the channel authentication records to ensure that the correct settings have been configured. The ALTER QMGR CHLAUTH switch is used to control whether channel authentication records are used. The command DISPLAY CHLAUTH can be used to query the channel authentication records.

c.3) Either of the above errors is followed by:

AMQ9999: Channel 'SYSTEM.ADMIN.SVRCONN' to host 'x (9.49.x.x)' ended abnormally.

Answer

1) If this is a production queue manager, then you could stop trying to use a userid that is an MQ Administrator and instead, use a non-administrator userid to access the queue manager.

2) If you really want the MQ Administrator to be able to access the queue manager via client channels, you could do one of the following actions.

2.a) You can add the following two Channel Authentication Records discussed in the following presentation:

What's New in WebSphere MQ v7.1 Security?
T.Rob Wyatt
Page 10: User ID blocking

The first rule blocks administrative users and the MCAUSER "nobody" (which prevents someone from creating a user ID "nobody" and putting it into an authorized group).
$ runmqsc QmgrName
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody','*MQADMIN')

The second rule provides a reduced blacklist for SYSTEM.ADMIN channels that allows administrators to use these. It is assumed here that some other CHLAUTH rule such as an SSLPEERMAP has validated the administrator’s connection or than an exit has done so.
SET CHLAUTH(SYSTEM.ADMIN.*) TYPE(BLOCKUSER) USERLIST('nobody')

The above rules apply to SYSTEM.ADMIN.SVRCONN which is used by the MQ Explorer.

If you are using another user-defined channel, such as MY.ADMIN.SVRCONN, then you need to add the following two records:
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')

Note: it is not advisable to use SYSTEM.DEF.* channels for active connections. The system default channels are the objects from which all user-defined channels inherit properties. The recommended practice is that SYSTEM.DEF.* and SYSTEM.AUTO.* channels should NOT be configured to be usable.

2.b) This is a variation of (2.a) but allowing the MQ Administrator to only use a particular host.

The first rule blocks MCAUSER "nobody".
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')

The second rule removes all access to SYSTEM.ADMIN.SVRCONN ...
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)

... and the third rule adds an entry for the server that needs access.
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(9.27.4x.7y) USERSRC(CHANNEL)

2.c) Disable the Channel Authentication Records feature:

ALTER QMGR CHLAUTH(DISABLED)

WARNING: Disabling this new feature is not recommended for MQ 7.1 production queue managers due to security implications.
Note that disabling CHLAUTH results in a policy that accepts administrative connections by default. The administrative effort to lock down administrative access with CHLAUTH(DISABLED) is much greater than to do so with CHLAUTH(ENABLED). It is therefore recommended to leave CHLAUTH(ENABLED) and use the other security features of WebSphere MQ V7.1 to authenticate administrator connections.