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

Question

I'm having a hard time trying to connect to my institution's MQ v9.

I was provided connectivity info by the MQ team:-

String hostName = '...'
int port = ...
String queueManager = '...'
String channel = '...'
String userId = 'ABC123'
String password = '...'

Given the following code...

JmsConnectionFactory cf = JmsFactoryFactory.
        getInstance(WMQConstants.WMQ_PROVIDER).
        createConnectionFactory()

cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, hostName)
cf.setIntProperty(WMQConstants.WMQ_PORT, port)
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel)
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT)
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManager)
cf.setStringProperty(WMQConstants.USERID, userId)
cf.setStringProperty(WMQConstants.PASSWORD, password)
// tried with both `true` and `false`... same error
cf.setBooleanProperty(WMQConstants.USER_AUTHENTICATION_MQCSP, true)

Connection connection = cf.createConnection()
connection.start()
connection.close()

... I'm getting this error:-

Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSSecurityException: 
JMSWMQ2013: The security authentication was not valid 
that was supplied for queue manager '...' with connection 
mode 'Client' and host name '...'.
Please check if the supplied username and password 
are correct on the queue manager to which you are 
connecting.  
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM 
MQ call failed with compcode '2' ('MQCC_FAILED') reason 
'2035' ('MQRC_NOT_AUTHORIZED').

I was told by the MQ team that the log has something like this:-

----- amqzfuca.c : 4527 -------------------------------------------------------
04/17/2019 10:32:20 AM - Process(10468.40757) User(...) Program(...)
                    Host(...) Installation(Installation1)
                    VRMF(9.1.0.1) QMgr(...)
                    Time(2019-04-17T15:32:20.542Z)
                    RemoteHost(...)
                    CommentInsert1(...)
                    CommentInsert2(...)
                    CommentInsert3(CLNTUSER(XYZ) ADDRESS(...))

AMQ9777E: Channel was blocked

EXPLANATION:
The inbound channel '...' was blocked from address '...' 
because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were
'CLNTUSER(XYZ) ADDRESS(...)'.

... and it fails because it's using the wrong credential to connect.

While I passed in a different credential (user ID: ABC123), the MQ log sees the user ID I used to log into my machine (user ID: XYZ).

Why does the credential I explicitly passed in get omitted? How do I fix this?

I'm using this dependency:

<dependency>
    <groupId>com.ibm.mq</groupId>
    <artifactId>com.ibm.mq.allclient</artifactId>
    <version>9.1.2.0</version>
</dependency>

I'm not using IBM JRE... more precisely, I'm using Oracle JDK 1.8 on my Mac, if that helps.

Thank you.

UPDATE 2019-04-22

I was able to get more accurate logs from MQ team now since I'm trying too many things at the same time.

If I set USER_AUTHENTICATION_MQCSP to true, then my machine's user ID (XYZ) is passed in.

If I set USER_AUTHENTICATION_MQCSP to false, then I'm getting different error message now:-

04/22/2019 01:19:49 PM - Process(1147099.9759) User(...) Program(...)
            Host(rofesb911a) Installation(Installation1)
            VRMF(9.1.0.1) QMgr(...)
            Time(2019-04-22T18:19:49.323Z)
            RemoteHost(...)
            CommentInsert1(wa03598)
            CommentInsert2(REQUIRED)
            CommentInsert3(MCAUSER(ABC123) CLNTUSER(ABC123) ADDRESS(...))

AMQ9790I: The failed authentication check was caused by a CHLAUTH record with
CHCKCLNT(REQUIRED).

EXPLANATION:
The user ID 'ABC123' and its password were checked because the inbound
connection matched a channel authentication record with CHCKCLNT(REQUIRED).

The active values of the channel were 'MCAUSER(ABC123) CLNTUSER(ABC123)
ADDRESS(...)'. The MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH
MQSC command can be used to identify the relevant CHLAUTH record.

The good news is it's seeing the correct user ID (ABC123), but I was told the password is invalid. I don't believe it was a password problem because I was able to use that same credential to access other protected web services.

Answer 1

Your MQ team have given you the credentials to use (i.e. user id and password) so I would assume that they have turned on user id and password checking on the queue manager.

Queue Manager is not using ADOPTCTX(YES)

ADOPTCTX(YES) is a setting on the queue manager that indicates that once user id and password have been verified as being correct, the user id (in your case "ABC123") should then be used for all further security checks (e.g. am I allowed to use this queue). If this setting is NO, then after the password validation is complete, it will actually use the client machine logged on user id which is also sent up to the queue manager (in your case "XYZ"). It seems likely that this is the case on your queue manager.

USER_AUTHENTICATION_MQCSP mode

There are actually two ways that a user id and password can be sent from a Java client application to the queue manager.

1. The first (decades old) was in use prior to IBM MQ V8, and used a restricted length flow (12 chars max each field) that was originally there for DOS SNA clients to send the two fields to the QMgr. This flow across the network was also the way the client logged on user id got sent to the queue manager, and so only one could be sent.
2. The newer one, added in MQ V6, and made more useful with password checking natively in the queue manager in MQ V8, was the MQCSP structure, which allowed for variable length user id and password fields. This was a different network flow from the one that sends the client logged on user id, and so both are sent to the queue manager.

When you set USER_AUTHENTICATION_MQCSP to true, you were telling the Java client to use the second mode. This gives the opportunity to be tripped up by the ADOPTCTX(NO) setting. If you set it to false, the only user id that makes it to the queue manager is ABC123 (in your example) and will likely give you a different, perhaps successful result.

Try your application with USER_AUTHENTICATION_MQCSP set to false, and when it works, advise your MQ team that they should use ADOPTCTX(YES) which is also now the default value, then you can switch back to USER_AUTHENTICATION_MQCSP set to true.