Author |
Message
|
T.Rob |
Posted: Wed Oct 26, 2016 7:03 am Post subject: ID/Password with CHLAUTH doesn't work like you think |
|
|
 Acolyte
Joined: 16 Oct 2001 Posts: 56 Location: Charlotte, NC
|
One of my sessions at MQTC was MQ Security Bugs, Issues & Gotchas and a section of that was CHLAUTH Doesn't Work Like You Think. In discussions with Morag and Rob Parker who also presented on MQ security I realized it was actually worse than what I described. When I got home I set up a lab with every version of MQ from v8.0.0.0 to v9.0.0.0 and tested password-based authentication with ADOPTCTX and CHLAUTH. Turns out the behavior changes many times across versions and Fix Packs.
If you use ID and password validation in MQ, you may be surprised by the findings. In fact, if you use MQAUSX you may want to keep using it for a while. I have posted a more detailed write-up at Store and Forward, as well as the test results matrix. The testing tools are on GitHub and I plan to develop these further to make a more generic testing suite.
I will be posting more on this topic in weeks to come, including much deeper technical deep dive into the MQ security model, how it changes to accommodate password based authentication, and some of the ways it breaks unexpectedly. _________________ -- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
Back to top |
|
 |
blorro |
Posted: Tue Feb 14, 2017 2:40 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
Excellent job done !
Were puzzled by another fact regarding CHLAUTH.
"Privileged Users" in MQ Version 8.0.0.5.
Were trying to get a userID that a customer ordered named :
'mqixxxx' (last four chars xxx-out).
Appropriate MQ Authority group created where said user is a member of, authorities assigned to both Queuemanager and Queues ment to be used.
Still , the Queuemanager refuses connections and throws :
"AMQ5534: User ID 'mqixxxx' authentication failed.
Could it be that MQ Version 8.0.0.5 assumes 'mqixxxx' being a Privileged User but since its NOT, no membership exists in mqm for it and the Queuemanager denies the connection attempt ? _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
exerk |
Posted: Tue Feb 14, 2017 3:25 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
blorro wrote: |
"AMQ5534: User ID 'mqixxxx' authentication failed. |
What else was in the log regarding that user?
For example, on a test system I deliberately induced a failure for a privileged user:
Quote: |
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'musr_mqadmin' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM). |
Have you checked whether the password being passed is correct? Using the amqsput/amqsputc or mqccred exit is a good way to cut-out test independent of the application. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
blorro |
Posted: Tue Feb 14, 2017 4:01 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
Password is correct , even shortened from 14 characters to 10 Chars .
And yes, tested with amqpsutc .
AMQ5534: User ID 'mqitest' authentication failed
EXPLANATION:
The user ID and password supplied by the 'WebSphere MQ Client for Java' program
could not be authenticated.
Additional information: 'N/A'.
ACTION:
Ensure that the correct user ID and password are provided by the application.
Ensure that the authentication repository is correctly configured. Look at
previous error messages for any additional information.
AMQ5542: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'mqitest' and its password were checked because the queue manager
connection authority (CONNAUTH) configuration refers to an authentication
information (AUTHINFO) object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with
CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
ACTION:
Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
If the CHCKCLNT setting is OPTIONAL, the authentication check can be avoided by
not passing a user ID across the channel. For example, by omitting the MQCSP
structure from the client MQCONNX API call.
To avoid the authentication check, you can amend the authentication
configuration of the queue manager connection, but you should generally not
allow unauthenticated remote access. _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
exerk |
Posted: Tue Feb 14, 2017 4:58 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
OK, I'm a little confused. You say you tested it with amqsputc but this...
Quote: |
The user ID and password supplied by the 'WebSphere MQ Client for Java' program could not be authenticated. |
...suggests you're using something like the MQIVP.class to test?
If you managed a successful connection with amqsputc, how did you pass the username? Using the variable? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
blorro |
Posted: Tue Feb 14, 2017 5:04 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
I didnt manage to do a successful connection.
Running the amqpsut/amqsputc via commandline. _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
exerk |
Posted: Tue Feb 14, 2017 6:58 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
blorro wrote: |
I didnt manage to do a successful connection.
Running the amqpsut/amqsputc via commandline. |
Yes, but how did you pass the username? You should have been prompted for a password if you set the MQSAMP_USER_ID environment variable, however, you can also use the MQIVP.class (look in the java samples directory) which takes the username and password but the downside is that it wants access to the SYSTEM.DEFAULT.LOCAL.QUEUE _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
blorro |
Posted: Wed Feb 15, 2017 12:40 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
SYSTEM.DEFAULT.LOCAL .QUEUE is not used in our shop at all.
The problem here is that we have this setup working for other "Systemusers" without issues.
It is this particular userID that is giving us headaches "mqitest"...
We provide username/password via commandline .
C:\>Set MQSAMP_USER_ID=mqitest
C:\>Amqsput AQP.TEST.DIGABIT
Sample AMQSPUT0 start
Enter password: xxxxxxxx
MQCONNX ended with reason code 2035
Hence my "Tinfoilhat" on having "mq" as part of the username for a nonprivileged user being a possible issue ? _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
exerk |
Posted: Wed Feb 15, 2017 1:52 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
blorro wrote: |
We provide username/password via commandline .
C:\>Set MQSAMP_USER_ID=mqitest |
OK so far...
blorro wrote: |
C:\>Amqsput AQP.TEST.DIGABIT
Sample AMQSPUT0 start
Enter password: xxxxxxxx
MQCONNX ended with reason code 2035 |
...and still 'good' in terms of fault diagnosis.
blorro wrote: |
Hence my "Tinfoilhat" on having "mq" as part of the username for a nonprivileged user being a possible issue ? |
As you've used SET for the environment variable and camel-cased an executable name I'm going to assume this is Windows. The fact that you've used amqsput means it's a bindings connection so blocking of a privileged user isn't in the picture - no CHLAUTH involved. So, does that user actually exist anywhere, e.g local or AD? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
blorro |
Posted: Wed Feb 15, 2017 5:52 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
AD-user.
Password lenght being 10 Chars long.. _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
exerk |
Posted: Wed Feb 15, 2017 6:14 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Try logging in as that user and see what happens... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Feb 15, 2017 11:52 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
exerk wrote: |
Try logging in as that user and see what happens... |
If the user is not in the same domain as the queue manager- The user must be given as domain\user
- The user must be able to be checked (like for a login) on the server running MQ (cross domain login / trust)
- The user cannot be used for authorization but needs to be mapped to a user in the same domain as the MQ Server.
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
blorro |
Posted: Thu Feb 16, 2017 3:53 am Post subject: |
|
|
 Acolyte
Joined: 09 Jan 2014 Posts: 57 Location: Sweden
|
Ok.
So i think i found the issue.
Tried to logon the mentioned user on a Windows Server but immediately got a response about account being locked due to too many incorrect logons.
Checked MQ Error logs from this morning (10MB logs, which were all from today!)
Discovered that the same user had tried to logon 8743 times during a 3 hour period.
Asked customer to check who else was running this particular user and response was that a connection already existed from another node towards this Queuemanager.
Wrong password configured most likely.
Using 'MQxxxx" as a username is not anything that gets blocked invisibly.
Problem Solved!
Thanks all who helped out once again!
 _________________ "Anything is possible, all the time." |
|
Back to top |
|
 |
|