What Cipersuites and Cipher Specs, can I use for IBM MQ v9 + Oracle-JDK v8?
I need more information on the FIPS parameter. When I tried with FIPS parameter, I didn't change anything in MQ level, but changed it to true in JMS client. What is use of this? How is it related to cipher-spec or cipher-suite?
Getting Authorization exception in MQ9 and resolved
just want to review below process are correct way to avoid Authorization exception
setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n '**' +put +get
+browse +dsp +inq
runmqsc TLSTEST.QM ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
ALTER QMGR CHLAUTH(DISABLED)
REFRESH SECURITY TYPE(CONNAUTH)
The information already provided in my answer to your question "TLSv2 with JDk8 Ciphersuites with MQ8? regarding MQ8 + Oracle-JDK8 will apply to this question.
Per a presentation given by Mark Taylor "What’s new in IBM MQ?", the GA release of MQ v9.0.0.0 was based on MQ v8.0.0.4 plus functional changes.
– Plus functional changes on top of MQ 8.0.0.4…
APAR IV66840 shows the fix is targeted for delivery in 8.0.0.2.
Based on this v9.0.0.0 would have this APAR included with the same Oracle mapping available in v8.0.0.2 and higher.
For information on FIPS please refer to the IBM MQ v9.0 Knowledge Center page "Federal Information Processing Standards (FIPS).
In general this caused MQ to disable weak cipherspecs.
In relation to Java, the settings like sslFipsRequired would cause MQ to use TLS in preference to SSL for Cipersuites that had a dual mapping, but as of any recent version of MQ any of those Ciphersuites that had dual mapping have been disabled by default as weak Ciphersuits.
IBM developerWorks blog post "MQ Java, TLS Ciphers, Non-IBM JREs & APARs IT06775, IV66840, IT09423, IT10837 -- HELP ME PLEASE!" has details on how the sslFipsRequired and preferTLS behavior has changed over recent APARs.
Related
An application needs to clear a local queue using PCF commands. The application is getting reason code 2035 MQRC_NOT_AUTHORIZED. Channel authentication records are disabled.What are the minimum required permissions needs to assign to the application users.
A blank MCAUSER in the server connection channel.
or Connect authority to the queue manager object and Clear authority to the queue.
If you view the AMQERR01.LOG it should show you what object and permission is missing, these errors are enabled by default on any supported version of MQ, in older now unsupported versions you would need to set a ENV variable to see these errors in the AMQERR01.LOG.
In general you would need the following permissions:
+connect +dsp on the qmgr.
+put +inq on the SYSTEM.ADMIN.COMMAND.QUEUE
+get +dsp on the SYSTEM.DEFAULT.MODEL.QUEUE
+dsp +inq +clr on any local queue you want clear
Reference two other answers I provided related permissions required for PCF commands:
IBM MQ - Permissions - Read perspective
How to monitor MQ within ITRS Geneos
Guys I am trying to connect to MQ Hub from WAS Liberty application. Our MQ Hub supports only SSL certificate authentication. I have created QCF, Keystore with JKS file and with certificate inside it. Then I created defaultSSLConfig and pointed to that keystore.
But I could not find anyway to specify the SSLConfig in the QCF and read on some page that it was not possible. The only way was to use defaultSSLConfig and specify keystore from there which I did. So now I am here and MQ connection does not work. On the MQ Hub logs I see the error saying that "The channel is lacking a certificate to use for the SSL handshake."
This is how my QCF looks like, no parameter to specify an SSL config
<jmsConnectionFactory connectionManagerRef="ConMgr" jndiName="jms/wmqCF">
<properties.wmqJms channel="TEST_CHANNEL" hostName="REMOVED" port="1415" queueManager="ALQ.TEST" transportType="CLIENT" sslCipherSuite="SSL_RSA_WITH_AES_128_CBC_SHA"/>
</jmsConnectionFactory>
Full error on MQ side
EXPLANATION:
The channel is lacking a certificate to use for the SSL handshake. The
channel
name is 'XXX.ADM.SVRCONN' (if '????' it is unknown at this stage in the
SSL
processing).
The remote host is 'XXX (10.xx.xx.x)'.
The channel did not start.
ACTION:
Make sure the appropriate certificates are correctly configured in the
key
repositories for both ends of the channel.
----- amqccisa.c : 7355
02/14/17 15:07:44 - Process(7510.304808) User(mqm) Program(amqrmppa)
Host(xxx) Installation(Installation1)
VRMF(7.5.0.6) QMgr(XXXXX)
AMQ9999: Channel 'XXX.ADM.SVRCONN' to host 'xxx (10.xx.xx.xx)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 7510 for channel 'XX.ADM.
SVRCONN'
ended abnormally. The host name is 'xx (10.xx.xx.xx)'; in some
cases the
host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error
logs to
determine the cause of the failure. Note that this message can be
excluded
completely or suppressed by tuning the "ExcludeMessage" or
"SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information
can be
found in the System Administration Guide.
It is working now :) What we think was the cause of the problem is this bug http://www-01.ibm.com/support/docview.wss?uid=swg1IT16056
Although the error in APAR above is not the same I was getting. I was seeing this error on the Liberty (client side)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with
compcode '2' ('MQCC_FAILED') reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').
at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.
java:203)
I was using this resource adapter when the problem was manifesting itself: 9.0.1.0-IBM-MQ-Java-InstallRA.jar
Then we decided to try lower version of the adapter which had that APAR/fix in it and thus used this one: 8.0.0.6-WS-MQ-Java-InstallRA.jar
So that solved the problem.
I was pretty sure that the above bugfix was included in Ver 9.X of the resource adapter but as it turns out it is not the case.
I checked with IBM and they confirmed that APAR IT16056 is not included in the 9.0.1.0 CD release. They are working to correct the APAR to show the right target release for the fix.
Quote from IBM support is below.
I can confirm that the APAR in question, "IT16056" is NOT included in
the 9.0.1.0 CD release, and is currently targeted to be included in
the 9.0.2.0 CD release.
Based on this if you want you use a version of the RA higher than 8.0 you would need to do one of the following:
Wait until the 9.0 LTS (Long Term Support) 9.0.0.1 fixpack is released (IBM has a site where they list they are targeting 1Q 2017).
Wait until the 9.0 CD (Continuous Delivery) 9.0.2.0 release is out (IBM does not publish a target for CD)
Open a PMR to IBM and ask them for a IFIX to apply the 9.0.0.1 LTS or 9.0.1.0 CD release.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
how can i properly setup Kerberos in Websphere MQ? In the documentation, it says can use
SCYEXIT('amqrspin(SCY_KERBEROS)')
I suppose this attribute is defined when when create the channels? eg
define CHANNEL (...) .... SCYEXIT('amqrspin(SCY_KERBEROS)')
how about SCYDATA('remote_principal_name') ? Does this need to defined after scyexit ? What other setups do I need to consider besides these 2 channel attributes?
is there other good tutorial on this subject? thanks.
The amqrspin security exit shipped with MQ supports KERBEROS and NTLM. A channel can be defined to use the security exit as
define channel(ABC) chltype(SVRCONN) SCYEXIT('amqrspin(SCY_KERBEROS)') SCYDATA('domusr')
where 'domusr' is in the form DOMAIN\user. The secure channel is established only if the name of the remote principal matches 'domusr'. Here is some more information on amqrspin security exit.
I have a queue manager QM_TEST created using the following MQSC command:
SET AUTHREC OBJTYPE(QMGR) GROUP('mq-user') AUTHADD(INQ,DSP,CONNECT,SET,SETALL)
SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,GET)
SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,PUT)
DEFINE CHANNEL ($cname) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('tcs-mq-user') REPLACE
SET CHLAUTH($cname) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('tcs-mq-user')
DEFINE QLOCAL ($dlqname) REPLACE
SET AUTHREC PROFILE($dlqname) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(ALL)
ALTER QMGR DEADQ($dlqname) FORCE
DEFINE LISTENER ($lname) TRPTYPE (TCP) CONTROL (QMGR) PORT ($port)
START LISTENER ($lname)
I have two queues TEST1 and TEST2 created using:
DEFINE QLOCAL ($qname) GET(ENABLED) PUT(ENABLED) MAXDEPTH($maxdepth) REPLACE
SET AUTHREC PROFILE($qname) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(ALL)
I am trying to copy messages from TEST1 to TEST2 using the q program utility:
q -xb -mQM_TEST -iTEST1 -mQM_TEST -oTEST2 -p20
However I get this error:
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 2 2012 ]
Connecting ...failed. MQCONNX on object 'QM_TEST' returned 2035 Not
authorized..
I am running WebSphere MQ v7.1. q SupportPac is installed on the server and I am executing the q command on the server. I can't figure out a way to pass the channel name TEST_CHANNEL and port number 1414, is that the issue?
The program is connecting to the QMgr in bindings mode via shared memory rather than using the SVRCONN channel. You can verify this by ALTER QMGR AUTHOREV(ENABLED) then looking at the authorization event that is produced in the QMgr event queue. If you have installed SupportPac MS0P you can right-click on the queue and select "Format event messages" to see it in human-readable format. Either way, you should see that the ID being used to connect is not tcs-mq-user but rather whatever ID you are using to run the Q program. Try:
q -lmqic -xc -iTEST1 -oTEST2 -p20
The program will prompt you for the channel details when run with -xc.
The Q program can dump queues to files but it is not designed for that. The QLoad program from SupportPac MO03 is designed for that and will capture all aspects of the message and, if you are suitably authorized, also restore them intact. This includes message ID, timestamp, etc.
Finally, a quick note about the AUTHREC statements in your post. Since you have bothered to create a low-privleged MCAUSER and set authorities for it, I presume that you would like that ID not to have administrative privileges. Please be aware that granting a user +set or +setall on the QMgr allows them to manage authorization records using WMQ Explorer or anything else that uses PCF commands. Consider restricting authorities on the QMgr to +dsp +inq +connect.
Generally, the applications don't get access to the DLQ but rather get access to an application-specific backout queue. If the app is granted access to the DLQ it is usually only to put messages there and not to get them back out. This is because the DLQ is a system-wide resource and if the QMgr is shared, the messages from multiple apps might land in the DLQ. As a security precaution, restrict delete access on that queue to administrators. This way someone cleaning up after their app can't accidentally (or otherwise) delete the messages belonging to another app.
UPDATE:
Reviewing your post, I noticed another discrepancy. I had assumed that you were getting the 2035 Authorization Error because you were connecting in bindings mode with an ID other than mqm or tcs-mq-user. After looking again, I realized that you never authorized the mq-user group to the queues you are trying to access. You authorized it to the Command Queue and the reply model which aren't used in this scenario. (WMQ Explorer uses them.) So, add the following rules:
SET AUTHREC PROFILE(TEST1) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(PUT,GET,INQ,BROWSE)
SET AUTHREC PROFILE(TEST2) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(PUT,GET,INQ,BROWSE)
This will solve the auths problem if in fact you are connecting as tcs-mq-user.
There isn't a way to pass the channel to Q on the command line, as far as I know, but it does accept the standard MQSERVER variable. For example:
export MQSERVER="$cname/TCP/localhost($port)"
...where $cname is the channel name and $port is the port. Here's my test:
tcs-mq-user:~> export MQSERVER="TEST.SVRCONN/TCP/localhost(1414)"
tcs-mq-user:~> q -xb -iTEST1 -mQMTEST -lmqic
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 2 2012 ]
Connecting ...connected to 'JMSDEMO'.
No more messages.
tcs-mq-user:~>
As to why its not finding the client libs, do you have them installed?
tcs-mq-user:~> rpm -qa | grep MQSeriesClient
MQSeriesClient-7.5.0-0