Closed BarDweller closed 5 years ago
It looks like the queue manager really does not like trying to authenticate a user with no password.
I worked through the stack and was able to check the actual authentication steps made to verify a password which is empty. And it fails with both of the possible authentication strategies that MQ can use with the OS. (If someone is insistent on trying to have a password-less user, then there's probably configuration via PAM that would permit it, but that's not something for a simple default config.)
So you need to try to avoid doing any authentication at all. The default developer qmgr config which creates that "app" user with an empty password can be used by connecting to the correct channel and passing no credentials at all. No userid or password. The "app" user is then assigned to the connection based on CHLAUTH rules.
In the Spring Boot configuration, that can be done by setting the userid property to be blank.
ibm.mq.user=
If there is no property at all, then "admin" is the default ID asserted, along with "passw0rd" to match the usual password in the mq-container developer templates.
But if the user property exists and is empty, then the client doesn't try to send any credentials so you end up with the results of the CHLAUTH map.
I know this issue is old an closed but maybe @ibmmqmet you have an idea on how to achieve this:
I need to connect a Queue using only the userId and now password. Sadly if i leave ibm.mq.password
blank, Spring / YAML will convert this to an empty string (https://github.com/spring-projects/spring-framework/issues/19986#issuecomment-453453915) which leads to the authentication not working.
Are there any workarounds for this?
Please include the following information in your ticket.
Using ibm-mqadvanced-server-dev helm chart, I left the app password blank, and I tried setting the password in mq-jms-spring to empty string, but I'm unable to successfully send a message,
exec'ing into the mq pod, and setting a password for the
app
user (and then configuring that password) allows the application to function as expected.confirmed before changing app's password that /etc/shadow had no password configured for app.
confirmed that using
passwd -d app
to clear apps password reverts the app to being unable to work.