ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » ID/Password with CHLAUTH doesn't work like you think

Post new topic  Reply to topic
 ID/Password with CHLAUTH doesn't work like you think « View previous topic :: View next topic » 
Author Message
T.Rob
PostPosted: Wed Oct 26, 2016 7:03 am    Post subject: ID/Password with CHLAUTH doesn't work like you think Reply with quote

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
View user's profile Send private message Visit poster's website
blorro
PostPosted: Tue Feb 14, 2017 2:40 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Feb 14, 2017 3:25 am    Post subject: Reply with quote

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
View user's profile Send private message
blorro
PostPosted: Tue Feb 14, 2017 4:01 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Feb 14, 2017 4:58 am    Post subject: Reply with quote

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
View user's profile Send private message
blorro
PostPosted: Tue Feb 14, 2017 5:04 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Tue Feb 14, 2017 6:58 am    Post subject: Reply with quote

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
View user's profile Send private message
blorro
PostPosted: Wed Feb 15, 2017 12:40 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed Feb 15, 2017 1:52 am    Post subject: Reply with quote

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
View user's profile Send private message
blorro
PostPosted: Wed Feb 15, 2017 5:52 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed Feb 15, 2017 6:14 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

blorro wrote:
AD-user

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Feb 15, 2017 11:52 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20695
Location: LI,NY

exerk wrote:
blorro wrote:
AD-user

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
View user's profile Send private message Send e-mail
blorro
PostPosted: Thu Feb 16, 2017 3:53 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » ID/Password with CHLAUTH doesn't work like you think
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.