| Author |
Message
|
| fjb_saper |
 Posted: Wed Jun 18, 2014 5:22 am Post subject: V8 connauth... what am I missing? |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Running MQ V8 on Windows 8.1 (no domain) (local account)
The only way I get the MQExplorer or JMS to do a client connection is to set checkclient(none) on the connauth record.
using c samples or even runmqsc as client runs fine though ...
So far: with checkclnt(reqdadmin):
C clients: my.user runs fine whereas my.user@hostname fails...
java / jms: my.user and my.user@hostname fail with a 2035 but will work if checkclnt is set to (none)...
The dot in the user name is intentional as this is how the user id got defined...
Note: that this is not a channel auth problem but a connauth problem (V8 )
Anybody can point me to the correct way to make connauth work in java /JMS ?
Thanks 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Wed Jun 18, 2014 11:29 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
I have been doing some reading of CONNAUTH in MQ v8 (I'll need to create a "competitive advantage" for MQAUSX over CONNAUTH) and CONNATUH is not very straight-forward.
| fjb_saper wrote: |
So far: with checkclnt(reqdadmin):
C clients: my.user runs fine whereas my.user@hostname fails...
java / jms: my.user and my.user@hostname fail with a 2035 but will work if checkclnt is set to (none)... |
"reqdadmin" value means ONLY check the UserID if it is part of the mqm group. Is my.user or my.user@hostname part of the mqmq group? Also, native applications (C clients) will use the UserID that it is running under and NOT the UserID you set unless you used the mqccred exit.
checkclnt supports 4 values: none, optional, reqdadmin and required. Why don't you try required.
On a "what were they thinking note", most MQAdmins will probably set checkclnt to optional and then tell their boss/manager/director that they have a secure queue manager but the opposite is true and it will drive T.Rob and myself crazy trying to explain what they have done is not secure. 
Here's my standard response when someone implements half-@ss security in MQ:
This isn't security. A queue manager needs to have ALL of its channels locked-down or else the rogue user will use the least secure channel.
Think of MQ security like home security. Would you lock JUST the front down and leave all of the windows and back-door (side-door) unlocked and then say you have a secure house? Does a burglar try just the front-door then go away? Most burglars don't start with the front-door and even if they do and it is locked, they simply move on to the next window or door.
The same is true for MQ security. A rogue user may try the channel you tell them to use but if it does not give them access to sensitive data then they will try a channel with more permissions.
On the bright-side, Morag will definitely be explaining CONNAUTH at MQTC v2.0.1.4.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 18, 2014 11:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RogerLacroix wrote: |
| On the bright-side, Morag will definitely be explaining CONNAUTH at MQTC v2.0.1.4. |
Justifies the cost of the ticket by itself.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 18, 2014 3:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The user is part of the priviledged users.
runmqsc has the optional setting. runmqsc -c has the reqdadmin setting and both workd fine with the my.user ID.
Like I said I tested all values and the only one that worked with java / jms was none! Haven't yet tried with JMS2.0 yet though...
This leads me to believe I am either missing something or this needs a pmr.
The user passed with runmqsc -c -u is the same user that was passed on the MQExplorer connection or used on the JMS attempt...
I know to authenticate the user on a client channel you really need an SSL cert, the likelyhood of the cert being available to a different user being less than the likelyhood of the password being known...
Try and duplicate and have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jun 19, 2014 3:11 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 19, 2014 7:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok, so.
It's really not connauth.
Connauth is the property of the queue manager that names an authorization information object.
So, connauth is just a name, it has no behavior. All of the behavior is controlled by the authinfo object, and it depends entirely on what the TYPE of the authinfo object is.
The second thing to be clear on is that it's the *queue manager* that executes whatever authinfo behavior is specified by the authinfo object named in the queue manager's connauth.
Thirdly, I *believe* that authinfo behavior takes place *before* MCAUSER and CHLAUTH rules have been enforced. But that's a guess, not a fact. I think it would take place before to ensure that the userid+password are validated as a pair, rather than having to guess which userid will be set after MCAUSER/CHLAUTH and then validated.
So, as MichaelDag says, you really need to look at the authority events to see what id is actually being authenticated, and where it's failing.
You might be correctly validating the userid/password sent over the channel, getting turned to MUSER_MQADMINx user and then getting failed by CHLAUTH. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 19, 2014 2:42 pm Post subject: Re: V8 connauth... what am I missing? |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
C clients: my.user runs fine whereas my.user@hostname fails...
java / jms: my.user and my.user@hostname fail with a 2035 but will work if checkclnt is set to (none)...
|
What does the error in your errorlog on the queue manager say?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 19, 2014 3:41 pm Post subject: Re: V8 connauth... what am I missing? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
C clients: my.user runs fine whereas my.user@hostname fails...
java / jms: my.user and my.user@hostname fail with a 2035 but will work if checkclnt is set to (none)...
|
What does the error in your errorlog on the queue manager say?
Cheers
Morag |
This is what the log says. And before you ask the password is correct as it works fine when using the C interface (runmqsc -c -u)...
| Code: |
6/19/2014 06:29:51 - Process(3784.14) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(FJS-HP) Installation(mq8)
VRMF(8.0.0.0) QMgr(TES)
AMQ5534: User ID 'f.j' authentication failed
EXPLANATION:
The user ID and password supplied by 'Mytest' could not be authenticated.
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.
----- amqzfuca.c : 4242 -------------------------------------------------------
6/19/2014 06:29:51 - Process(3784.14) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(FJS-HP) Installation(mq8)
VRMF(8.0.0.0) QMgr(TES)
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'f.j' 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.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.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
-------------------------------------------------------------------------------
6/19/2014 06:29:52 - Process(9400.7) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(FJS-HP) Installation(mq8)
VRMF(8.0.0.0) QMgr(TES)
AMQ9557: Queue Manager User ID initialization failed for 'f.j'.
EXPLANATION:
The call to initialize the User ID 'f.j' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2199 -------------------------------------------------------
|
I thought that was pretty clear and either I am doing something wrong (somebody guide me please, oh pretty please) or it's time IBM looked at the code again. By the way it's failing the same way from MQExplorer!
What is the max length for the password? I have 16 chars...
Didn't think that would be a problem as it worked fine with the C interface.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 20, 2014 4:02 am Post subject: Re: V8 connauth... what am I missing? |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| What is the max length for the password? I have 16 chars... |
Aha!
So, here's a little bit of additional information about user IDs and passwords from Java clients.
You may recall that the Java client has always sent a user ID and password across the client channel, putting it into the Security Exit MQCD fields, RemoteUser and RemotePassword fields. This is not the same as using an MQCSP structure.
Since this particular use of user ID and password from Java is so prevalent, and there are so many security exits out there using it, we have retained this behaviour and at the queue manager, if there is nothing supplied in an MQCSP structure, we pick this other flow up and use it instead.
However, there are some downsides to this old mechanism that the MQCSP structure doesn't have:- It has a limit of 12 chars for password!
- It has a limit of 12 chars for the user ID (thus making it hard to use with longer LDAP user IDs.
- It is not covered by the password protection feature
The Java client is also capable of using the MQCSP structure instead. In MQ Explorer you may have noticed an extra check box entitled "User identification compatibility mode" (new in V8 explorer). If you uncheck that you should find that your 16 character password is now accepted.
You can see a screenshot in here (http://www.slideshare.net/MoragHughson/websphere-mq-v8-security-deep-dive) on slide 71.
To have the equivalent behaviour in your own Java program:-
This mode of operation can be enabled on a connection-by-connection basis or globally for your own Java program.
- To set this mode operation on a connection in MQ Classes for Java, set the property MQConstants.USE_MQCSP_AUTHENTICATION_PROPERTY to true in the properties hashtable passed to the com.ibm.mq.MQQueueManager constructor.
- To set this mode operation on a connection in MQ Classes for JMS, set the property JMSConstants.USER_AUTHENTICATION_MQCSP to true on the appropriate connection factory prior to creating the connection
- To set this mode globally, set the System Property "com.ibm.mq.cfg.jmqi.useMQCSPauthentication" to a value indicating true, for example by adding "-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=Y" to the command line
I apologise for the confusion, we struggled with the best way to retain the existing behaviour for the many customers who currently use it, and also supply the new behaviour for use in the same environment.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 20, 2014 4:40 am Post subject: Re: V8 connauth... what am I missing? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
| What is the max length for the password? I have 16 chars... |
Aha!
.....
However, there are some downsides to this old mechanism that the MQCSP structure doesn't have:- It has a limit of 12 chars for password!
- It has a limit of 12 chars for the user ID (thus making it hard to use with longer LDAP user IDs.
- It is not covered by the password protection feature
The Java client is also capable of using the MQCSP structure instead. In MQ Explorer you may have noticed an extra check box entitled "User identification compatibility mode" (new in V8 explorer). If you uncheck that you should find that your 16 character password is now accepted.
You can see a screenshot in here (http://www.slideshare.net/MoragHughson/websphere-mq-v8-security-deep-dive) on slide 71.
To have the equivalent behaviour in your own Java program:-
This mode of operation can be enabled on a connection-by-connection basis or globally for your own Java program.
- To set this mode operation on a connection in MQ Classes for Java, set the property MQConstants.USE_MQCSP_AUTHENTICATION_PROPERTY to true in the properties hashtable passed to the com.ibm.mq.MQQueueManager constructor.
- To set this mode operation on a connection in MQ Classes for JMS, set the property JMSConstants.USER_AUTHENTICATION_MQCSP to true on the appropriate connection factory prior to creating the connection
- To set this mode globally, set the System Property "com.ibm.mq.cfg.jmqi.useMQCSPauthentication" to a value indicating true, for example by adding "-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=Y" to the command line
I apologise for the confusion, we struggled with the best way to retain the existing behaviour for the many customers who currently use it, and also supply the new behaviour for use in the same environment.
Cheers
Morag |
Hi Morag,
Here is the results of my latest tests:
using
| Code: |
| jcf.setBooleanProperty(JmsConstants.USER_AUTHENTICATION_MQCSP, true); |
worked like a charm
As for the MQExplorer
| Morag wrote: |
| The Java client is also capable of using the MQCSP structure instead. In MQ Explorer you may have noticed an extra check box entitled "User identification compatibility mode" (new in V8 explorer). If you uncheck that you should find that your 16 character password is now accepted. |
Checked or unchecked makes no difference. Still failing!
Same error in the log.
BTW when entering the password the max you see in MQE is 8 dots...
Does that mean that the password entry popup does not care about the unchecked field?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 20, 2014 7:54 am Post subject: Re: V8 connauth... what am I missing? |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
BTW when entering the password the max you see in MQE is 8 dots...
Does that mean that the password entry popup does not care about the unchecked field? |
I think you have found an MQ Explorer defect, it looks to be truncating the password to 12 characters when it shouldn't be. I've reported it internally now, but can you follow the PMR route to kick off an official fix.
Sorry
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 20, 2014 11:36 am Post subject: Re: V8 connauth... what am I missing? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hughson wrote: |
| fjb_saper wrote: |
BTW when entering the password the max you see in MQE is 8 dots...
Does that mean that the password entry popup does not care about the unchecked field? |
I think you have found an MQ Explorer defect, it looks to be truncating the password to 12 characters when it shouldn't be. I've reported it internally now, but can you follow the PMR route to kick off an official fix.
Sorry
Cheers
Morag |
Would love to .... but not possible with developer version (no entitlement).
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Sat Jun 21, 2014 3:49 am Post subject: Re: V8 connauth... what am I missing? |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fjb_saper wrote: |
| hughson wrote: |
| can you follow the PMR route to kick off an official fix. |
Would love to .... but not possible with developer version (no entitlement). |
ok fair enough, well, we have found it internally, so that's at least goodness. Thank you for that 
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mehedi |
| Posted: Wed Apr 01, 2015 10:04 am Post subject: password greater than 12, was a fix made |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
Morag,
Did this issue ever get fixed. ? Connection attemtps fail with passwords > 12 characters.
MQExlplorer v 8.0.0.2 , checked the boxes for 'Enable User Identification' and 'User compatibility'. Wireshar confirms Userid and Password are truncated beyond 12 characters. I've got a PMR open.
Thanks
Mehedi |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Apr 01, 2015 2:28 pm Post subject: Re: password greater than 12, was a fix made |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| mehedi wrote: |
| Did this issue ever get fixed. ? |
It was my understanding that it was, but your PMR will confirm.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
