Why do I get MQJE001: Completion Code '2', Reason '2035' after upgrading from java client 6.0.2.2 to 9.3.1.0? - ibm-mq

Question

I work on a Java application which uses com.ibm.mqjms version 6.0.2.2. I just upgraded to com.ibm.mq.allclient version 9.3.1.0.
After the upgrade, all attempts to put a message on the queue results the following error :
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
The error message given by queue manager is :
AMQ9557E: Queue Manager User ID initialization failed for '[username]'.
EXPLANATION:
The call to initialize the User ID '[username]' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a
userID flow was used, the User ID in the UID header was '' and any CHLAUTH
rules applied prior to user adoption were evaluated case-sensitively against
this value.
ACTION:
Correct the error and try again.
I've tried to add the following in the java application to disable MQCSP, but this did not help.
Hashtable props = new Hashtable();
props.put(MQConstants.USER_ID_PROPERTY, false);
props.put(MQConstants.PASSWORD_PROPERTY, false);
props.put(MQConstants.USE_MQCSP_AUTHENTICATION_PROPERTY, Boolean.FALSE);
this.queueManager = new MQQueueManager(getManager(), props);
What can I do to troubleshoot this issue? Since the issue only exists with the more recent version of the MQ java client, I'd think the issue is caused by the client?
AMQERR01.LOG
2023-01-03 13:28:41 - Process(2838.71) User(mqm) Program(amqrmppa)
Host([HOSTNAME]) Installation(Installation1)
VRMF(9.2.5.0) QMgr(TSTMQ01)
Time(2023-01-03T12:28:41.959Z)
ArithInsert1(2) ArithInsert2(2035)
CommentInsert1([USERNAME])
AMQ9557E: Queue Manager User ID initialization failed for '[USERNAME]'.
EXPLANATION:
The call to initialize the User ID '[USERNAME]' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a
userID flow was used, the User ID in the UID header was '' and any CHLAUTH
rules applied prior to user adoption were evaluated case-sensitively against
this value.
ACTION:
Correct the error and try again.

Answer 1

To get the prior v6 behavior set the java system property user.name to an empty value, for example on the command line add this:
-Duser.name=
or in your program add this:
System.setProperty("user.name", "")
Background:
The IBM MQ classes for Java and IBM MQ classes for JMS are the only libraries where IBM allows you to set the username that is passed to MQ in the protocol field called RemoteUserIdentifier. This has been in place since the Java and JMS classes were released. IBM has stated this is because a java app does not have direct access to the user the process runs under only the java system property user.name which will be filled in by the JVM with a username but can be overridden as a java system property. On the other hand C, C++, .NET and XMS MQ client APIs all pass the user that the process is running as in the RemoteUserIdentifier field and you cannot override this and specify an arbitrary value.
Java and JMS also were the only APIs to allow you to specify a password value and this would be sent to the queue manager in the RemotePassword field. The RemoteUserIdentifier/RemotePassword fields are part of the MQCD (MQ channel defination) that the client sends to the queue manager when connecting.
Prior to v8 the queue manager had no built in functionality to authenticate any username or password value that was provided, you would need a security exit to get any additional validation. If you configure your MQ SVRCONN channel to allow connections as any ID with no protection (Blank MCAUSER and no security exits or SSLCIPH/SSLPEER to restrict access, then anyone can write a simple Java or JMS MQ application to assert any user value and get access to what that user would have access to on MQ, even without java someone with admin rights on there own desktop or server can just create a local user with the right name and run a C program and get similar access. It is never a good idea to accept an arbitrary asserted ID without some form of validation.
Prior to CHLAUTH which was added in MQ v7.1 the default configuration of a new queue manger was to allow the asserted id to be administrative unless you protected against this, this could be as simple as passing the value "mqm" to a linux queue manager or simply passing a blank value, if the MCAUSER was also blank on the SVRCONN channel the channel would run under the authority of the process running the listener which would be the "mqm" user.
With 7.1 and higher a new queue manager is created by default with CHLAUTH(ENABLED) and a few default CHLAUTH rules, one restricts access to all channels that start with "SYSTEM" and another denies connections to SVRCONN channels from any user MQ determines has administrative authority. Note that if a queue manager was created at a version prior to 7.1, then later upgraded to 7.1 or higher the default is to leave CHLAUTH(DISABLED), so unless you alter it to set it to ENABLED at some point you do not have these protections.
On the Java/JMS client side prior to 7.1, if you did not set the username a blank value would be passed in the RemoteUserIdentifier, after 7.1, if you do not set the username then the client defaults to sending the value of the java system property user.name, if you do set the username it is still sent in favor to the user.name value.
Since MQ v7.0 non-java APIs have had the ability to send an additional structure to the queue manager during the channel connection called the MQCSP which has fields for a username and password and AuthenticationType, but similar to what I said about RemoteUserIdentifier/RemotePassword prior to v8 there was no built in functionality to actually authenticate or do anything with these values, you would need to use a security exit to get this functionality. Note the MQCSP.AuthenticationType field has two possible values, MQCSP_AUTH_NONE (indicating that you do not want authentication performed) or MQCSP_AUTH_USER_ID_AND_PWD (indicate that you want authentication performed).
Since MQ v8.0 the Java and JMS APIs now also have the ability to send the username and password values in the MQCSP instead of the MQCD RemoteUserIdentifier/RemotePassword fields, but for all versions of MQ v8.0, MQ v9.0.0.x (LTS) and 9.0.x (CD), 9.1.0.x (LTS), and 9.1.x (CD) the default is to send the username and password in compatibility mode still using the RemoteUserIdentifier/RemotePassword fields of the MQCD. To have Java and JMS use the MQCSP, you have to specifically set a property. When the specified username and password is sent in the MQCSP the RemoteUserIdentifier is filled in with the java system property user.name by default. Note that in 9.3 it seems the default is now send the username and password in the MQCSP structure instead of in compatibility mode.
At v8.0 and later the queue manager now has the feature called CONNAUTH which can authenticate a username and password that is sent via either MQCSP or RemoteUserIdentifier/RemotePassword. There are various configuration options around how this is configured, but by default at v8 or later if a username and password (note the password could be empty in this case) are sent to the queue manager and MQCSP.AuthenticationType is set to MQCSP_AUTH_USER_ID_AND_PWD, they will be validated to be correct, and if an administrative user is sent to the queue manager it must provide a password and be correct.
For Java/JMS APIs, if no MQCSP is sent by the client but RemoteUserIdentifier and RemotePassword both have a value, the queue manager will build a MQCSP with MQCSP.AuthenticationType set to MQCSP_AUTH_USER_ID_AND_PWD and validate it the same way, note in this case if RemotePassword is empty a MQCSP structure is not built.
Conclusion:
Based on the description of how you state that the Java app with v6 jars is functioning, this means that anyone that has access to connect the MQ listener port of your queue manager can specify any username that has access to MQ including the queue manager admin user. It would be much better to send a username and password that will be validated, or use client TLS certificates to assert identity (When combined with setting the channels SSLPEER and a MCAUSER (or a CHLAUTH SSLPEERMAP rule) you can greatly restrict who can connect to your channel, and you eliminate the ability for them to assert any arbitrary username.