Error '2035' ('MQRC_NOT_AUTHORIZED') While Connecting to MQ

Question

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.

score 10 · Answer 1 · answered Feb 26 '11 at 03:50

10

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.

answered Feb 26 '11 at 03:50

T.Rob

31,522
9
59
103

OMG! What an awful Technote! I will contact IBM and see if I can get them to fix it. Note that the defect listed is with IBM FTM and not with MQ itself. My advice was to properly authorize the user attempting to connect. IBM's is to disable `CONNAUTH`. Since `CONNAUTH` is horribly broken that's good advice but assuming someone follows it they still need the ID that is connecting to be properly authorized at MQ. Thanks for the link! – T.Rob Dec 29 '17 at 04:27

score 5 · Answer 2 · edited May 01 '11 at 01:14

5

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.

edited May 01 '11 at 01:14

T.Rob

31,522
9
59
103

answered Apr 30 '11 at 19:28

mqrus

325
2
10

2

Do you have a link that describes how to do this? – Nathan Lee Aug 22 '11 at 22:02

Digital Alchemist · Answer 3 · 2014-06-18T21:30:18.417

2

You can also resolve this By setting mcauser('mqm') .. i was able to overcome 2035 error.

Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)

Esp thanx to my SENIOR Bilal Ahmad (PSE)

edited Jun 18 '14 at 21:30

answered Mar 03 '14 at 10:58

Digital Alchemist

2,324
1
15
17

The suggestion in this answer not a good one to use. You would be giving the application full MQ administrative permission by setting `MCAUSER('mqm')`. Also note that on MQ v7.1 and later by default CHLAUTH rules will block this connection from working anyway. – JoshMc Aug 23 '17 at 07:32

Rudy · Answer 4 · 2016-12-06T03:32:29.943

0

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.

edited Dec 06 '16 at 03:32

answered Dec 05 '16 at 11:27

Rudy

7,008
12
50
85

1

A restart of the queue manager is not required after adding new OAM rules. – JoshMc Aug 23 '17 at 07:27
Unless you are using MQ on Windows or MQv8 or later with `SecurityPolicy=user` on Unix/Linux, granting permission with the `-p` flag is not recommended. This is because on Unix/Linux prior to v8 and by default in v8 and later the resulting OAM rule is actually granted to the primary group of the user specified not to the user itself. Many situations make this bad for example if by default a large number of users have the same primary group (ex: group `users`). – JoshMc Aug 23 '17 at 07:29

score 0 · Answer 5 · answered Feb 24 '11 at 08:11

0

You have to check the privileges with an MQ administrator.

answered Feb 24 '11 at 08:11

DaeMoohn

1,087
13
27

score 0 · Answer 6 · answered Aug 28 '18 at 16:10

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

score 0 · Answer 7 · answered Mar 17 '22 at 10:13

On this topic if you are using MQSeries 9.1 in a test or development environment you can disable channel authentication with the following approach : . Launch MQ command line utility with the following : runmqsc (for example runmqsc QM1) . Disable authentication for all channels with the following command ALTER QMGR CHLAUTH (DISABLED)

score -1 · Answer 8 · answered Jul 19 '12 at 11:46

-1

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.

answered Jul 19 '12 at 11:46

david.barkhuizen

5,239
4
36
38

By adding the user to the mqm group you are giving that user full MQ administrative authority which is not recommended, the application should be granted the least permission require to perform its function. Also note that on MQ v7.1 and later by default CHLAUTH rules will block connections from working that resolve to MQ Admin users. – JoshMc Aug 23 '17 at 07:34
@JoshMc What is the recommended resolution, then ? – david.barkhuizen Aug 23 '17 at 08:53
On windows you can grant the authority directly to the user. On unix prior to v8 you would could add the user to a group other than mqm and grant the authority to that group. On v8 and later on unix you can set `SecurityPolicy=user` in the qm.ini and grant the authority directly to the user. – JoshMc Aug 23 '17 at 09:05

score -1 · Answer 9 · edited Jun 04 '22 at 05:30

Error MQRC 2035 basically means that your application has been able to connect to the queue manager, however due to certain absence of permissions/authorizations, it was unable to put/get/publish/subscribe messages.

To resolve this, at first, try these steps in order to disable the authorizations from queue manager and channel. Use this only if it isn't a production queue manager.

Always check the queue manager logs. It tells you exactly where you need to look into, and resolve the issue.
In this case, generally, you can issue the following commands after doing a runmqsc on the queue manager :
```
ALTER QMGR CHLAUTH(DISABLED)
```

Then set the chckclnt object(under authinfo) to optional

DISPLAY QMGR CONNAUTH
DISPLAY AUTHINFO(name-from-above) ALL  //name from the first commands

ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) ADOPTCTX(YES)

ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)

REFRESH SECURITY TYPE(CONNAUTH)

SET CHLAUTH('*') TYPE(BLOCKUSER) ACTION(REMOVEALL)

This helps remove any blocks that the channel is creating against any user.
```
 SET CHLAUTH(your channel name) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL)
```

This should resolve your issue, since we have disabled every authorization that an application has to pass in order to do anything on a queue manager.

Now, in case you are using a production queue manager, NEVER remove authorizations. Go, and right click on any QM that you have configured in your MQ explorer. Go to the QM authority, and authority records. Click on create new user, and give the same name as the username your application is using. Select all the checkboxes, then copy from the space below all the commands that are given. Namely, setmqaut. Edit with your queue manager name, and issue them!

----Never give up, the answer is where you have not looked yet--------

Error '2035' ('MQRC_NOT_AUTHORIZED') While Connecting to MQ

9 Answers9

Linked