I am using MQ Transport on the Oracle Service Bus to connect to external MQ server. The problem, however, is that the external MQ server cannot have any authority records other than:
CONNECT/INQUIRE (for Queue Manager)
PUT/GET/INQUIRE (for Queue)
This is a problem, because the OSB MQ Transport is always trying to connect with a context, and also put message with context as well. Even when I set up the MQC.MQPMO_NO_CONTEXT on the PUT message options, in the business service settings.
Is it even possible to exchange the messages with MQ, using the OSB MQ Transport and not having SET/SETALL authority records set?
PS. The MQ logs the following errors:
AMQ8077: Entity 'osbtest ' has insufficient authority to access
object 'TESTQMGR'.
EXPLANATION: The specified entity is not authorized to access the
required object. The following requested permissions are unauthorized:
setall
// ...
AMQ8077: Entity 'osbtest ' has insufficient authority to access
object 'TEST.QUEUE'.
EXPLANATION: The specified entity is not authorized to access the
required object. The following requested permissions are unauthorized:
set
Versions:
Oracle Service Bus: 11gR1
Websphere MQ: 7.5
Try creating an environment variable on the MQ server host named "MQSNOAUT" and setting its to "YES"
Related
Am using WebSphere 9.0.5.10 and trying to connect DB2 database over SSL port.
I tried to retrieve the certificate from DB2 database by using the below procedure.
Import the database server certificate.
1.Open the WebSphere Application Server administrative console.
Security > SSL certificate and key management > Key stores and certificates > {NodeDefKeystore}
Signer certificates > Retrieve from port.
Clicked Retrieve from port.
Enter the host name and security port of the database server.
Type an alias name for the certificate.
Click Retrieve signer information.
Click OK to save the configuration.
2.Configure the data source to support SSL connections.
Select Resources > JDBC > Data sources.
Select WebSphere Commerce database DataSource demo in the data source list, where database can be either DB2 or Oracle.
Update the port number in the Common and required data source properties section. Enter the value of the security port that you set in the database server.
Clicked Apply.
In the Additional Properties section, select Custom properties.
Clicked New
Enter sslConnection in the Name field, and enter true in the Value field.
Click OK to save the configurations.
Post service restart, tried to check the database connection and got below error.
Someone please help to resolve the issue.
Error: The test connection operation failed for data source on server nodeagent at node with the following exception: java.sql.SQLException: [jcc][t4][2030][11211][4.29.24] A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - socketInputStream.read (-1). Message: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target. ERRORCODE=-4499, SQLSTATE=08001 DSRA0010E: SQL State = 08001, Error Code = -4,499. View JVM logs for further details.
The Test Connection function makes a best attempt at connecting, but some security requirements are not supported by this, since Test Connection is not an equivalent application.
Test Connection does not have the same quality of function available as an application, hence, an application in this case is the best method to test any database connections.
Another document that is well worth checking is:
WebSphere Application Server Data Source driver connection over SSL with Database server
https://community.ibm.com/community/user/wasdevops/blogs/ajit-jariwala/2021/10/06/websphere-application-server-data-source-driver-c
Otherwise it's more of a DB2 JDBC Driver issue with the error -4499
Perhaps, also test the very latest JDBC Driver 4.32.28
https://www.ibm.com/support/pages/db2-jdbc-driver-versions-and-downloads
Hope it helps!
Dave
we are using websphere MQ version 9.0.0.1,basically we have configured the active/passive cluster setup on linux machine, all queue managers are running on fine on both active/passive node.we have configured the channels queues in queue managers,
while application is trying to connecting my queue manager we are facing errors
below error getting at application side.
The Security athuntication was not valid that supplied for QUEUEMANAGER 'xxxxx_OUTWARD'WITH CONNECTION 'CLIENT' and HOST NAME 'xxxxx'PLEASE CHECK IF THE ERROR QUEUEMANAGER 'xxxxx_OUTWARD'WITH CONNECTION MODE 'CLIENT'AND HOST NAME'xxxxxx.
below ERROR we found in queuemanager level error logs
----- cmqxrsrv.c : 2362 -------------------------------------------------------
04/27/2018 07:52:35 PM - Process(29498.16) User(mqm) Program(amqzlaa0)
Host(xxxxxxx) Installation(Installation2)
VRMF(9.0.0.1) QMgr(xxxxx_INWARD)
AMQ5534: User ID 'mqm' 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.
----- amqzfuca.c : 4486 -------------------------------------------------------
04/27/2018 07:52:35 PM - Process(29498.16) User(mqm) Program(amqzlaa0)
Host(JPRIPAYMENTMQ2) Installation(Installation2)
VRMF(9.0.0.1) QMgr(xxxxx_INWARD)
AMQ5542: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(OPTIONAL) configuration.
EXPLANATION:
The user ID 'mqm' 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(OPTIONAL).
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.
-------------------------------------------------------------------------------
04/27/2018 07:52:36 PM - Process(18265.105) User(xxx) Program(amqrmppa)
Host(xxxxx) Installation(Installation2)
VRMF(9.0.0.1) QMgr(xxxxx_INWARD)
AMQ9557: Queue Manager User ID initialization failed for 'mqm'.
EXPLANATION:
The call to initialize the User ID 'mqm' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was 'mqm'.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2362 -------------------------------------------------------
after this i have provided permission to 'mqm' user in queue manager level and queue level with the below command still we are facing same error.
setmqaut -m queue manager name -t qmgr -p mqm +connect &
setmqaut -m queue manager name -n queue name -t queue -p mqm user name +all
can any one help this issue
#Morag Hughson:-
How to turn off userid and password in queue manager level
#Morag Hughson:-
any command for turn off user id and password please share the command to resolve this issue.
#JoshMC:- if i was turn it off it is a good practice or is there any other option to resolve this issue from queue manager/application side?
#Hello all , i was informed to application to place the messages without mentioning any user id and password.after that my application able to access the all queue managers.
issue got resolved. Thanks to all for helping this issue.
The queue manager error messages tell you exactly the problem. First it says:-
AMQ5534: User ID 'mqm' authentication failed
EXPLANATION:
The user ID and password supplied by the 'WebSphere MQ Client for Java' program
could not be authenticated.
So the Java application that was trying to connect over a client was sending up 'mqm' as the user id and either the wrong password (or possibly no password at all).
The password is being checked by the queue manager. The second error message tells you WHY it is being checked.
AMQ5542: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(OPTIONAL) configuration.
EXPLANATION:
The user ID 'mqm' 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(OPTIONAL).
The configuration described in the second error message is there by default on your queue manager.
You have two options.
Send the correct password to go with the 'mqm' user id on your Java application.
Choose to turn off user id and password checking on the queue manager.
First off, no applications should be using the 'mqm' account except for MQAdmins and those MQ services that run under 'mqm' account. Regular business applications should NEVER EVER use the 'mqm' account. It is a BIG security risk and goes against the IBM's MQ Best Practices.
Secondly, the 'mqm' account already has full authority to everything.
setmqaut -m queue manager name -t qmgr -p mqm +connect &
setmqaut -m queue manager name -n queue name -t queue -p mqm +all
You are trying to give permission to a UserId that already has full permission.
Third, by doing those commands, you are potentially messing up your queue manager.
Fouth, the error message is not about authorization but as JoshMc pointed out it is about authentication. setmqaut command is for authorization (i.e. permission).
Fifth, create a UserId and Password on the server where you are running the queue manager (or use MS AD) and supply those credentials when your application connects to the queue manager. Note: you will need to use the setmqaut command to give your new UserId permission to access the queue manager and the queues.
I am new to IBM WebSphere MQ. I am running it within a docker container. The user 'sampleuser' and 'root' are part of the 'mqm' group within the conatiner. I am able to access the MQ from the host as a 'root' user and as a 'sampleuser' (I created 'sampleuser' in the host aswell).
I want to enable anonymous authentication, so that irrrespective of the client user id, they should be able to access the MQ. I though MCAUSER('sampleuser') would do it for me. But it does't work. I get error AMQ4036 (not authorized) from the eclipse IBM explorer. Please advice.
ALTER QMGR PSNPRES(SAFE)
ALTER QMGR PSMODE (ENABLED)
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('sampleuser') REPLACE
Update #1
I updated the code to allow privileged user. But still fails.
ALTER QMGR PSNPRES(SAFE)
ALTER QMGR PSMODE (ENABLED)
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('*NOACCESS')
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('sampleuser') REPLACE
Here is the log, that I have got.
EXPLANATION:
The user ID 'sampleuser' 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).
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.
Update #2 Based on JohnMC's answer and refernce to Provide anonymous access to IBM WebSphere MQ I finally made it work.. : )
ALTER QMGR PSNPRES(SAFE)
ALTER QMGR PSMODE (ENABLED)
ALTER QMGR CHLAUTH(DISABLED)
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('*NOACCESS')
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('sampleuser') REPLACE
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
I will assume you are using a supported version of MQ (7.1 or later).
With MQ 7.1 and later a new queue manager by default will come with a few CHLAUTH rules, one of these disables connections to SVRCONN channels from users with MQ administrative authority. In this case you have placed the user sampleuser in the MCAUSER of the channel. Since sampleuser is a member of the mqm group it is disallowed by default.
Based on the setup you present if the connection was allowed you would be allowing any user that can connect over the network to your MQ listener port the ability to manage the queue manager, define queues, delete queues, add permissions, etc.
Look at this answer by T.Rob for some more detail on how to make this work without disabling security "Unable to connect to queue manager in WebSphere MQ 7.1".
I also have another post with some similar information "C# MQ Connect get Error 2035 but Java MQ Connect works well"
Update #1
The logs show that you are getting a connection authentication error. With MQ 8.0 and later by default the queue manager is configured to require a valid password be specified for MQ Administrative users, since sampleuser is part of the mqm group it falls into this category.
You can configure MQ Explorer to send a username and password when connecting to the queue manager.
Right click the queue manager name
Select Connection Details
Select Properties...
Select Userid
Check the box next to "Enable user identification"
Fill in the Userid field
If you leave it as "Prompt for password" it will ask you each time you open MQ Explorer for the password when you attempt to connect to the queue manager. You have the option of selecting "Use saved password" and then providing the password.
I do not recommend you do this, but if you want to disable security and allow anyone to connect as a MQ administrator to your queue manager with out providing a valid password you can disable this with the following command.
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
I installed MQ8.0.0.4 on a ubuntu(14.4) server. I am able to launch a local MQ explorer and connect to local Queue Managers. I want to connect to the same Queue Manager from a remote windows machine. When I try this I get authorization errors:
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.
This link shows a list of auth commands to enable remote windows connection, but the page only lists upto version 7.5 for which this is applicable. Will I have to do the same setup on 8.0 as well?
I already enabled remote administration using the local MQ Explorer.
"The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object." Are you using the mqm ID or another ID? You could use the MQS_REPORT_NOAUTH or MQSAUTHERRORS setting to get more info the authority failure.
To answer your other question, I believe the settings in the link will also apply to v8 - but v8 also has additional new authority checks as well.
In WebSphere 6.1 I have created a datasource to an Oracle 11g instance using the thin JDBC client.
In Oracle I have two users, one existing and another newly created.
My websphere datasource is OK if I use the component-managed authentication alias of the existing user, but fails with "invalid user/password" message if I use the alias of the new user. The error message is:
The test connection operation failed for data source MyDB (Non-XA) on
server nodeagent at node MY_node with the following exception:
java.sql.SQLException: ORA-01017: invalid username/password;
logon denied DSRA0010E: SQL State = 72000, Error Code = 1,017.
View JVM logs for further details.
There is nothing in the JVM logs. I have grepped all websphere logs and they do not mention my connection at all.
I can confirm that the username and password are correct by logging in via SQLPlus or (to prove the JDBC connection is OK) via SQuirreL.
I have checked in Oracle that the new user has all the system privs that the existing user has.
Any thoughts on what is going on or how I can debug this further?
Just FYI. I am guessing you are running WebSphere in Network Deployment mode.
This behavior you're experiencing is actually by design.
The reason for it is that the "Test Connection" button you see on the admin console, invokes the JDBC connection test from within the process of the Node Agent. There is no way for the J2C Alias information to propagate to the Node Agent without restarting it; some configuration objects take effect in WebSphere as soon as you save the configuration to the master repository, and some only take effect on a restart. J2C aliases take effect on restarts.
In a Network Deployment topology, you may have any number of server instances controlled by the same Node Agent. You may restart your server instances as you'd like, but unless you restart the Node Agent itself, the "test connection" button will never work.
It's a known WebSphere limitation... Which also exists on version 7.0, so don't be surprised when you test it during your next migration. :-)
If this happens to anyone else, I restarted WebSphere and all my problems went away. It's a true hallmark of quality software.
Oftentimes when people tell me they can't log into Oracle 11g with the correct password, I know they've been caught out by passwords becoming case-sensitive between 10g and 11g.
Try this :
data source definition
security
use the j2c alias both autentication managed by component and autentication managed by container
IBM WAS 8.5.5 Knowledge Center - Managing Java 2 Connector Architecture authentication data entries for JAAS
If you create or update a data source that points to a newly created J2C authentication data alias, the test connection fails to connect until you restart the deployment manager.
After you restart the deployment manager, the J2C authentication data is reflected in the runtime configuration. Any changes to the J2C authentication data fields require a deployment manager restart for the changes to take effect.
The node agent must also be restarted.
I have point my data source to componenet-manage authentication as well as container-managed authentication.Its working fine now........