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.
Related
I work on a Java application which uses com.ibm.mqjms version 6.0.2.2. I just upgraded to com.ibm.mq.allclient version 9.3.1.0.
After the upgrade, all attempts to put a message on the queue results the following error :
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
The error message given by queue manager is :
AMQ9557E: Queue Manager User ID initialization failed for '[username]'.
EXPLANATION:
The call to initialize the User ID '[username]' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a
userID flow was used, the User ID in the UID header was '' and any CHLAUTH
rules applied prior to user adoption were evaluated case-sensitively against
this value.
ACTION:
Correct the error and try again.
I've tried to add the following in the java application to disable MQCSP, but this did not help.
Hashtable props = new Hashtable();
props.put(MQConstants.USER_ID_PROPERTY, false);
props.put(MQConstants.PASSWORD_PROPERTY, false);
props.put(MQConstants.USE_MQCSP_AUTHENTICATION_PROPERTY, Boolean.FALSE);
this.queueManager = new MQQueueManager(getManager(), props);
What can I do to troubleshoot this issue? Since the issue only exists with the more recent version of the MQ java client, I'd think the issue is caused by the client?
AMQERR01.LOG
2023-01-03 13:28:41 - Process(2838.71) User(mqm) Program(amqrmppa)
Host([HOSTNAME]) Installation(Installation1)
VRMF(9.2.5.0) QMgr(TSTMQ01)
Time(2023-01-03T12:28:41.959Z)
ArithInsert1(2) ArithInsert2(2035)
CommentInsert1([USERNAME])
AMQ9557E: Queue Manager User ID initialization failed for '[USERNAME]'.
EXPLANATION:
The call to initialize the User ID '[USERNAME]' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a
userID flow was used, the User ID in the UID header was '' and any CHLAUTH
rules applied prior to user adoption were evaluated case-sensitively against
this value.
ACTION:
Correct the error and try again.
To get the prior v6 behavior set the java system property user.name to an empty value, for example on the command line add this:
-Duser.name=
or in your program add this:
System.setProperty("user.name", "")
Background:
The IBM MQ classes for Java and IBM MQ classes for JMS are the only libraries where IBM allows you to set the username that is passed to MQ in the protocol field called RemoteUserIdentifier. This has been in place since the Java and JMS classes were released. IBM has stated this is because a java app does not have direct access to the user the process runs under only the java system property user.name which will be filled in by the JVM with a username but can be overridden as a java system property. On the other hand C, C++, .NET and XMS MQ client APIs all pass the user that the process is running as in the RemoteUserIdentifier field and you cannot override this and specify an arbitrary value.
Java and JMS also were the only APIs to allow you to specify a password value and this would be sent to the queue manager in the RemotePassword field. The RemoteUserIdentifier/RemotePassword fields are part of the MQCD (MQ channel defination) that the client sends to the queue manager when connecting.
Prior to v8 the queue manager had no built in functionality to authenticate any username or password value that was provided, you would need a security exit to get any additional validation. If you configure your MQ SVRCONN channel to allow connections as any ID with no protection (Blank MCAUSER and no security exits or SSLCIPH/SSLPEER to restrict access, then anyone can write a simple Java or JMS MQ application to assert any user value and get access to what that user would have access to on MQ, even without java someone with admin rights on there own desktop or server can just create a local user with the right name and run a C program and get similar access. It is never a good idea to accept an arbitrary asserted ID without some form of validation.
Prior to CHLAUTH which was added in MQ v7.1 the default configuration of a new queue manger was to allow the asserted id to be administrative unless you protected against this, this could be as simple as passing the value "mqm" to a linux queue manager or simply passing a blank value, if the MCAUSER was also blank on the SVRCONN channel the channel would run under the authority of the process running the listener which would be the "mqm" user.
With 7.1 and higher a new queue manager is created by default with CHLAUTH(ENABLED) and a few default CHLAUTH rules, one restricts access to all channels that start with "SYSTEM" and another denies connections to SVRCONN channels from any user MQ determines has administrative authority. Note that if a queue manager was created at a version prior to 7.1, then later upgraded to 7.1 or higher the default is to leave CHLAUTH(DISABLED), so unless you alter it to set it to ENABLED at some point you do not have these protections.
On the Java/JMS client side prior to 7.1, if you did not set the username a blank value would be passed in the RemoteUserIdentifier, after 7.1, if you do not set the username then the client defaults to sending the value of the java system property user.name, if you do set the username it is still sent in favor to the user.name value.
Since MQ v7.0 non-java APIs have had the ability to send an additional structure to the queue manager during the channel connection called the MQCSP which has fields for a username and password and AuthenticationType, but similar to what I said about RemoteUserIdentifier/RemotePassword prior to v8 there was no built in functionality to actually authenticate or do anything with these values, you would need to use a security exit to get this functionality. Note the MQCSP.AuthenticationType field has two possible values, MQCSP_AUTH_NONE (indicating that you do not want authentication performed) or MQCSP_AUTH_USER_ID_AND_PWD (indicate that you want authentication performed).
Since MQ v8.0 the Java and JMS APIs now also have the ability to send the username and password values in the MQCSP instead of the MQCD RemoteUserIdentifier/RemotePassword fields, but for all versions of MQ v8.0, MQ v9.0.0.x (LTS) and 9.0.x (CD), 9.1.0.x (LTS), and 9.1.x (CD) the default is to send the username and password in compatibility mode still using the RemoteUserIdentifier/RemotePassword fields of the MQCD. To have Java and JMS use the MQCSP, you have to specifically set a property. When the specified username and password is sent in the MQCSP the RemoteUserIdentifier is filled in with the java system property user.name by default. Note that in 9.3 it seems the default is now send the username and password in the MQCSP structure instead of in compatibility mode.
At v8.0 and later the queue manager now has the feature called CONNAUTH which can authenticate a username and password that is sent via either MQCSP or RemoteUserIdentifier/RemotePassword. There are various configuration options around how this is configured, but by default at v8 or later if a username and password (note the password could be empty in this case) are sent to the queue manager and MQCSP.AuthenticationType is set to MQCSP_AUTH_USER_ID_AND_PWD, they will be validated to be correct, and if an administrative user is sent to the queue manager it must provide a password and be correct.
For Java/JMS APIs, if no MQCSP is sent by the client but RemoteUserIdentifier and RemotePassword both have a value, the queue manager will build a MQCSP with MQCSP.AuthenticationType set to MQCSP_AUTH_USER_ID_AND_PWD and validate it the same way, note in this case if RemotePassword is empty a MQCSP structure is not built.
Conclusion:
Based on the description of how you state that the Java app with v6 jars is functioning, this means that anyone that has access to connect the MQ listener port of your queue manager can specify any username that has access to MQ including the queue manager admin user. It would be much better to send a username and password that will be validated, or use client TLS certificates to assert identity (When combined with setting the channels SSLPEER and a MCAUSER (or a CHLAUTH SSLPEERMAP rule) you can greatly restrict who can connect to your channel, and you eliminate the ability for them to assert any arbitrary username.
Following instructions provided in https://developer.ibm.com/tutorials/mq-jms-application-development-with-spring-boot/, I developed a sample Spring boot web application in order to be able to send and receive messages over IBM MQ using JMS template.
In case of a MQ server not on local host, I updated the application.properties file with:
ibm.mq.conn-name=<my-server-host-name>(<my-server-port>)
Unfortunately this is not the appropriate property as the application is searching for a queue manager on localhost.
I did not find in the documentation anything about the property to use for that. And yes, I gave a try to ibm.mq.host and ibm.mq.port.
For IBM config you need to provide the following properties:
Yml extension:
ibm:
mq:
queueManager: {queueManagerName}
channel: {channelName}
connName: localhost(1415)
user: {UserName}
property extension:
ibm.mq.queueManager={queueManagerName}
ibm.mq.channel={channelName}
ibm.mq.connName=localhost(1415)
ibm.mq.user={userName}
connName you can find in the Listener directory:
In my case IP address is equal: localhost
Port is equal: 1415
channelName you can find in Channels directory.
As per https://github.com/ibm-messaging/mq-jms-spring the default connection properties for mq-jms-spring-boot-starter are
The default attributes are
ibm.mq.queueManager=QM1
ibm.mq.channel=DEV.ADMIN.SVRCONN
ibm.mq.connName=localhost(1414)
ibm.mq.user=admin
ibm.mq.password=passw0rd
You will most likely need to set connName, user and password. The default port is 1414, but if you are running MQ in the cloud then you will need to look up in you cloud what port to use. You will get the port from the same place you look up the server url.
You may also need to supply TLS parameters - https://github.com/ibm-messaging/mq-jms-spring#tls-related-options
You can find sample code here - https://github.com/ibm-messaging/mq-dev-patterns/tree/master/Spring-JMS The 101 sample ( https://github.com/ibm-messaging/mq-dev-patterns/tree/master/Spring-JMS/src/main/java/com/ibm/mq/samples/jms/spring/level101 ) has very little code, so a good test of whether the connection parameters are right.
I have a spring app, and I've received information to connect to ibm mq. I've got everything except user and password. When I was using docker image I had a user and password (specified using MQ_APP_PASSWORD env. variable). It's obvious that I can connect to ibmmq queue with just a username, but the question is, if I can connect without both ? does ibmmq allow for something like this ?
The MQ Advanced for Developers container images come with a default configuration which enables security. In this configuration, applications connect using the DEV.APP.SVRCONN channel. I think that you should take a look at the CHCKCLNT attribute in CONNAUTH. In the default configuration, the CHCKCLNT attribute on the channel (CHLAUTH) is set to REQUIRED if you've set a password on the container (by setting the MQ_APP_PASSWORD environment variable), or set to ASQMGR otherwise. The queue manager setting which this will fall back to, is set using CONNAUTH, on the AUTHINFO object, which is set to REQDADM by default. So, not sending a user ID and password should already work. However, if not, try adjusting the AUTHINFO object's CHCKCLNT setting. Note that this could also have a knock-on effect on the DEV.ADMIN.SVRCONN channel, which also uses this default.
You can change the MQ configuration used in a Docker image by adding an MQSC as described here. You will need to refresh security at the end of your MQSC.
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.
I am trying to connect to Websphere MQ 7.1 with Hermes JMS but I am not able to. I have followed their giude, loaded all the jars without problems, set the plugin, set all the variables (hostname, port, transportType, queuemanager), checked the box at the bottom that says user and typed the username and password and after confirming I tried to discover however I get the following message back:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at
com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233)
at
com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) at
com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at
com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95)
at
com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at
com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
at
com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770)
at
com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719)
at
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) at
hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107)
at
hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280)
at
hermes.impl.HermesAdminAdapter.discoverDestinationConfigs(HermesAdminAdapter.java:82)
at
hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126)
at
hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175) at
hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170) at
java.lang.Thread.run(Thread.java:662)
After a few hours of trial and error and research on the net, it seems that the issue is that it cannot connect due to bad authorization however I am able to connect using Java code (Using same lib MQQueueConnectionFactory) and I am also able to connect using QueueZee with the exact same libraries, get a list of all queues and browse them so I know user authorization issues should not be the problem.
I am running Hermes JMS 1.14 and I tried using both Java 1.6.0_33 and 1.7.0_5. Websphere MQ is running on version 7.1.0.0 and the libraries were gotten from this installation on a remote server.
I tried setting the channel variable to SYSTEM.DEF.SVRCONN which is what I used in QueueZee to get it to work but still the same issue.
Has anybody seen this issue before and hopefully can shed some light in the situation?
At V7.1 the new CHLAUTH rules shut off access to all SYSTEM.* channels except SYSTEM.ADMIN.SVRCONN by default and do not allow any administrative access on any SVRCONN channel by default. In order to diagnose this it would be necessary to know what channel was used, the CHLAUTH rules that are set, the channel definition (in particular, the MCAUSER value) and whether the ID used is in the mqm group.
You didn't mention whether the QueueZee setup was also to a V7.1 QMgr or this one in particular. Taking a wild guess, I'd say that CHLAUTH rules are enabled and that the SYSTEM.DEF.SVRCONN channel is disabled at this point. Recommended steps are to define a new channel whose name doesn't start with SYSTEM. and make sure the ID used is not in the mqm group but is authorized as a non-admin ID.
Alternatively, an ID in the mqm group can be used but you'd have to define a CHLAUTH rule to allow it to work. For example, the default CHLAUTH rule uses CHANNEL(*) BLOCKUSER(*MQADMIN) and you could change that to CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). The new rule would be more specific than the old rule and thus take precedence on your channel. It tells the QMgr to block the user ID 'nobody' but omits any mention of *MQADMIN. Since 'nobody' doesn't have access anyway but since *MQADMIN is not mentioned (and thus not blocked by thei rule) the effect of the rule is to allow admins on this channel.
As a quick, dirty and temporary measure, you can also ALTER QMGR CHLAUTH(DISABLED) to get the same behavior as in v7.0 and earlier QMgrs. Be aware though that this allows anonymous remote admin and remote code execution using the mqm user ID. That's why the default settings were changed. Now you must explicitly provision remote admin access if you need it.
For more on this topic, I recommend the Securing Your QMgr presentation from the IMPACT conference.
Note that the password the app sends in is not checked by the QMgr. The field exists so that channel exits can validate the password against AD, LDAP, etc. Without such an exit, the password is ignored. The user ID passed in by the client is either accepted at face value or modified by the channel's MCAUSER or by CHLAUTH rules.
Finally, when having authorization problems the easiest way to diagnose is to ALTER QMGR AUTHOREV(ENABLED) and then use SupportPac MS0P to decode the PCF messages in WMQ Explorer. The auths errors end up in the QMgr Event queue. Each message tells you the object that failed auths, the API call made against that object, the options of the call and the ID that made the call. Often we find the ID making the call isn't the one we wanted or that the program is using options it isn't authorized for so this can be extremely helpful.
Not really an answer, just a little research on the problem.
I have faced the same problem about hour ago. I am passing the username like domain\sortoflongusername and what i see in systemlog on WSMQ server is that my username is being truncated to 12 symbols.
I'm not really familiar with hermesJMS and soapui at all (just wanted to offer it to our testers to check it out as testing platform), so maybe anyone here does know about roots of this problem.