I am getting this error while connecting to IBM MQ. I know that this is because of privileges, but is there any way just to check the connection with IBM MQ?
Please suggest.
7 Answers
8
votes
The 2035 suggests that your connection is getting to the QMgr. If you had the wrong channel name, host or port you would get back a 2059. The 2035 means that the connection made it to the listener, found a channel of the name that was requested and attempted a connection.
If you want to test past this point it will be necessary to either authorize the ID that you are using to connect or to put an authorized ID in the MCAUSER attribute of the channel.
For a detailed explanation of how the WMQ security works on client channels, see the WMQ Base Hardening presentation at http://t-rob.net/links.
5
votes
If you enable authorization messages then the 2035 will show up in the event queue. Then you can look at the message and see what ID was used to connect and what options were used too. The 2035 might be because you asked for set authority on the queue manager or something else you aren't supposed to have. The authorization messages wil show you that.
2
votes
0
votes
I have been struggling with this for ages too. Eventually I found this solution. (If you can call turning off authentication a solution.)
I am using version - IBM Websphere 9.1.0.201807091223
From IBM's website they advise turning connection authentication off!!!
Resolving the problem Disable channel authentication
You will need to disable connection authentication, at least temporarily. There are known issues in FTM for Check with regard to using MQ connection authorization. These problems are actively being addressed and fixes will appear in a future fix pack. The target is fixpack 3.0.0.8.
Steps to disable connection authentication: Open MQ command console and type runmqsc ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE) CHCKLOCL(NONE) Restart the queue manager for this change to take effect.
Source http://www-01.ibm.com/support/docview.wss?uid=swg21962081
-1
votes
For a Q/Q-manager running on Windows, you may have to create the user on the Q/Q-manager machine [i.e. create a user on the Q-machine to match the user on the Q-client machine], and then add that user to the 'mqm' group on that machine.
Steps:
Ensure that the domain user that is being used to create the Q CLIENT [i.e. the user that the Q-client app is running under] also exists on the box with the Q/Q-manager. You may be able to just create a local user on the Q/Q-manager box [, or you may have to do some more complicated creation of an Active Directory user - I can't help you there].
On the Q/Q-manager box, add the user you have just created [or the existing one, if it already exists] to the mqm group. [On a Windows server box you will need to use the Microsoft Management Console (1. 'mmc' from the command line, 2. File > Add/Remove SnapOn > Local Users & Groups, 3. add user to group)]. The 'mqm' group should already exist on the Q/Q-manager machine.
-1
votes
You can use dspmqaut to check the grant. Below is the sample to give user poc access to Queue Manager QM1 and Queue LQ1
# check the access right of user POC to QM1
dspmqaut -m QM1 -n LQ1 -t q -p poc
# if you want to give access, you should use
setmqaut -m QM1 -n LQ1 -t q -p poc <access Types>
# eg (put everything - in the real live scenario, choose only what you want to grant) :
setmqaut -m QM1 -n LQ1 -t q -p poc +put +get +browse +inq +set +crt +dlt +chg +dsp +passid +setid +setall +clr
Then dont forget to restart QM1 with
endmqm -i QM1
strmqm QM1
Finally, you should be able to proceed without error 2035.
