Skip to content

Empty/Blank passwords don't seem to work. #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
BarDweller opened this issue Dec 5, 2018 · 2 comments
Closed

Empty/Blank passwords don't seem to work. #18

BarDweller opened this issue Dec 5, 2018 · 2 comments

Comments

@BarDweller
Copy link

Please include the following information in your ticket.

  • ibmmq-jms-spring version(s) that are affected by this issue.

    com.ibm.mq
    mq-jms-spring-boot-starter
    2.0.9
  • Java version (including vendor and platform).
    Launching defaultServer (Open Liberty 18.0.0.3/wlp-1.0.22.cl180320180905-2337) on IBM J9 VM, version 8.0.5.25 - pxa6480sr5fp25-20181030_01(SR5 FP25) (en_US)
  • A small code sample that demonstrates the issue.

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,

2018-12-05T15:33:58.797Z AMQ5534E: User ID 'app' authentication failed
2018-12-05T15:33:58.797Z AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'stocktrader' with connection mode 'Client' and host name 'mqtrader1-ibm-mq.stocktrader(1414)'.
...
[err] Caused by: 
[err] com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

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.

@ibmmqmet
Copy link
Collaborator

ibmmqmet commented Dec 6, 2018

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.

@timmhirsens
Copy link

timmhirsens commented Jan 6, 2022

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 (spring-projects/spring-framework#19986 (comment)) which leads to the authentication not working.

Are there any workarounds for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants