MQRC 2035: Not authorized

What it means

Several different checks can return 2035, and the fix depends on which one failed. On MQCONN or MQCONNX the user may lack connect authority, the user ID or password may be wrong, or the queue manager may require credentials the application didn't send. On MQOPEN, MQPUT1 or MQSUB the user lacks authority for the options requested, such as put, get, browse or inquire. Commands fail with 2035 when the user can't issue them or can't touch the object named.

For client connections on distributed MQ, two layers run before any object check. Channel authentication records (CHLAUTH) can block the connection outright. New queue managers ship with a rule that blocks privileged administrator IDs on client channels, which is why an admin user often gets 2035 from a remote client. Connection authentication (CONNAUTH) then checks any user ID and password. On a new queue manager the default object SYSTEM.DEFAULT.AUTHINFO.IDPWOS sets CHCKCLNT(REQDADM), so administrators must send a valid password. When either layer refuses, the application sees only 2035. The queue manager error log says which check failed.

On IBM MQ for z/OS, object and connection security is done by RACF or another external security manager, through classes such as MQCONN, MQQUEUE, MQADMIN and MQCMDS. A refusal there usually comes with an ICH408I message in the queue manager's job log. z/OS also supports CHLAUTH and connection authentication for channels. CICS applications on z/OS that aren't allowed to connect get 2217 (MQRC_CONNECTION_NOT_AUTHORIZED) instead of 2035.

Common causes

• A CHLAUTH rule blocks the connection. The most common case is an administrator user ID connecting over a client channel, which the default backstop rule blocks.
• Connection authentication failed. The password is wrong or expired, the user ID doesn't exist on the queue manager's host or LDAP, or no credentials were sent when CHCKCLNT requires them.
• The user ID that reaches the queue manager has no authority on the queue. For clients this is the channel's MCAUSER, a CHLAUTH-mapped ID or, with MCAUSER blank, the ID the client asserted.
• The user lacks authority on the cluster transmission queue when putting to a cluster queue. The queue itself is fine.
• On z/OS, a RACF profile in MQCONN, MQQUEUE, MQADMIN or MQCMDS denies access, or a new profile wasn't refreshed.
• Java and JMS clients in compatibility mode sending a user ID longer than 12 characters, or authentication behavior changing after an upgrade to MQ 9.3 or later.

How to find the problem

1. Read the queue manager error log (AMQERR01.LOG on distributed MQ) at the time of the failure. It names the check that failed, such as a channel blocked by a CHLAUTH rule, a rejected user ID and password, or a missing authority with the user ID and object.
2. Test CHLAUTH rules with DISPLAY CHLAUTH(APP.SVRCONN) MATCH(RUNCHECK) ADDRESS('10.1.2.3') CLNTUSER('ordapp'). It shows which rule would apply.
3. Check the authentication setup with DISPLAY QMGR CONNAUTH and DISPLAY AUTHINFO(...) CHCKCLNT CHCKLOCL ADOPTCTX.
4. On distributed MQ, list authority with dspmqaut -m QM1 -t q -n ORDERS.IN -p ordapp. The environment variables MQS_REPORT_NOAUTH and MQSAUTHERRORS add more detail to the logs.
5. Turn on authority events (ALTER QMGR AUTHOREV(ENABLED)). Each refusal then puts a Not Authorized event on SYSTEM.ADMIN.QMGR.EVENT with the user ID.
6. On z/OS, look for ICH408I in the queue manager or channel initiator job log. It names the class, the profile and the user ID that was refused.

How to fix it

• Don't connect remote applications as an administrator. Use a non-privileged user ID, set by MCAUSER or a CHLAUTH USERMAP or ADDRESSMAP rule, and grant only what it needs.
• If a CHLAUTH rule blocks a legitimate user, change or add a specific rule rather than turning CHLAUTH off. New rules apply to new connections without a restart.
• Send valid credentials from the application in MQCSP or the connection factory, and run REFRESH SECURITY TYPE(CONNAUTH) after changing the AUTHINFO object.
• Grant object authority on distributed MQ with setmqaut -m QM1 -t q -n ORDERS.IN -p ordapp +put +inq (or SET AUTHREC), then REFRESH SECURITY if you changed group membership.
• On z/OS, permit the user to the right RACF profile, refresh the class with SETROPTS RACLIST(MQQUEUE) REFRESH, then issue REFRESH SECURITY on the queue manager.

What it looks like

JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.