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)
Related
I'm running a Queue Manager on docker using the latest ibmcom/mq image, but I have an access denied when I try to connect to it from my windows using MQ Explorer.
I've disabled CHLAUTH in MQSC (runmqsc) using the command:
ALTER QMGR CHLAUTH(DISABLED)
I've disabled CONNAUTH using the commands:
ALTER QMGR CONNAUTH(' ')
REFRESH SECURITY TYPE(CONNAUTH)
I've removed the default CHLAUTH rules of the image
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) ACTION(REMOVE)
I've set a Listener and a channel, and added a queue to them
DEFINE LISTENER(LISTENER.TCP) TRPTYPE(TCP) PORT(30002) CONTROL(QMGR) REPLACE
START LISTENER(LISTENER.TCP)
DEFINE CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
DEFINE QLOCAL('MyQueue') REPLACE
When I try to connect to the Channel SYSTEM.DEF.SVRCONN from windows using MQ Explorer, I'm getting the error (AMQ4036). The error in /var/mqm/qmgrs/MyQueueManager/errors/AMQERR01.LOG into the docker container is:
----- cmqxrsrv.c : 2552 -------------------------------------------------------
02/06/20 10:18:13 - Process(1658.19) User(mqm) Program(amqrmppa)
Host(5652aa2322eb) Installation(Installation1)
VRMF(9.1.4.0) QMgr(MyQueueManager)
Time(2020-02-06T10:18:13.718Z)
ArithInsert1(2) ArithInsert2(2035)
CommentInsert1(myWindowsId)
AMQ9557E: Queue Manager User ID initialization failed for 'myWindowsId'.
EXPLANATION:
The call to initialize the User ID 'myWindowsId' 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 want to used the queue manager for local development. Do you have any idea on how to disable the security for my windows user id to be able to connect with MQ Explorer and Application Server Weblogic ?
I am wondering why you need to disable security. If you have explorer running then the next step will be to add your queue manager in explorer. From the tutorial -
https://developer.ibm.com/tutorials/mq-macos-dev/
(I know it's for Mac, but the principal is the same for windows).
This will be:
Right click on ‘Queue managers’ in the MQ Explorer Navigator box, then ‘Add remote queue manager’. A pop up appears.
Add your queue manager name – if Docker – QM1, then click Next.
Add Host name or IP Address – if Docker – localhost.
Add Server connection channel – if Docker – DEV.ADMIN.SVRCONN, then click ‘Next’ twice
Tick ‘Enable user identification’, if Docker – default is admin. Leave ‘Prompt for password’ selected.
Click Finish, then add password for user – if Docker – passw0rd. Your queue manager should appear.
If you truly want to disable security and don't care anything about access to this queue manager, just do the following (in addition to all the turning off of security settings you have already done).
ALTER CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('user-id-in-mqm-group-on-docker')
The problem is that your 'myWindowsId' is not defined to the OS in your docker container. The above command asserts the user id specified in the MCAUSER field, and will ignore the user id flowed by the channel from your Windows box.
I would however, encourage you to try the earlier answer, and learn how to do enough in security to let yourself in rather than turning it all off.
We are using IBM MQ version 9.0 windows server. We require a little information about MUSR_MQADMIN. Can we rename MUSR_MQADMIN to some other user? If it's renamed to some other user and pointing to the "IBM Websphere MQ services", will it face any challenges?
#Team,
we have a one more question why we always get the " error 1069:the services didn't start due to the logon error " and we have seen logon properties ./musr_mqadmin is having some encrypted password.Kindly confirm us after installation this password is created by with operational user password( mqm#123 )( means Ex: user : op_mqm & password : mqm#123 )or is there any default password ? if it is default password how we can decrypt the default password
Yes, default user MUSR_MQADMIN can be deleted, before that you should create another user account and make this user member of mqm group, then associate this new user name with IBM MQ Services. If you are working with MQ Client then MUSR_MQADMIN user is NOT needed.
I have tried this and it works fine.
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.
There are similar questions to this one, but not quite the same...
I have a C# program that is using amqmdnet.dll (from 9.0.1.0 MQC Redist)
The code to connect is:
Hashtable mqProperties = new Hashtable();
mqProperties.Add(MQC.CHANNEL_PROPERTY, channelName);
mqProperties.Add(MQC.HOST_NAME_PROPERTY, hostname);
mqProperties.Add(MQC.PORT_PROPERTY, port);
queueManager = new MQQueueManager(strQueueManagerName, mqProperties);
It works fine and writes to the queue. I assume it picks up my current login id from Windows.
When I run the same code on IIS, it connects but fails with an auth error 2035 when trying to write to the Queue.I assume this is because IIS is running as a different user-id.
I tried adding:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
and it did not work. Trying "mydomain\myuserid" did not work either. Some other posts mentioned that MQ needs the Windows SID. I tried using that string, but that did not work either.
At this point, I am playing with this, so I'd prefer not to ask the admins to set up a new userid on the MQ server side. With this in mind, is there any way I can login when running under the IIS user, but pass in my userid/password or some other credential to make this work?
If the queue manager is v8.0 or later and is configured to use CONNAUTH and has ADOPTCTX(YES) set you can present an id and password. If it does not have this set then the value presented in the UserId and Password property of a .NET client will be ignored.
A IBM developerWorks MQdev blog post "MQCSP Password Protection in MQ V8 has details on how to do this in various languages."
For .NET you should be able to use what you have with the addition of the MQC.USE_MQCSP_AUTHENTICATION_PROPERTY set to true:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
mqProperties.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
The queue manager will then authenticate this ID. If the queue manager is set with ADOPTCTX(YES) then it will always use the authenticated ID for OAM checks. If it is set to ADOPTCTX(NO) it will still use the ID the process is running under to perform OAM checks. It is highly recommended that this be set to ADOPTCTX(YES).
Update 2017/02/20:
Related to the comment "I can see that it might be turned off by admins so that MQ relies on the larger organizational SSO infrastructure.". Without setting up CONNAUTH and ADOPTCTX(YES) you can assert any id you want to over the channel. If a CHLAUTH rule is not in place to block administrative users then you can obtain full MQ administrative authority without any form of authentication.
I am trying to figure out how we would configure / setup the authentication, Queues, and Queue managers for connecting an MQ Client that is on a server / domain completely separate from the MQ Server it will be forwarding messages to.
I would assume that in a normally organizational environment you could just use Active Directory (if hosted on windows servers) for the authentication / AD lookup. However, in this scenario because they are different orgs you couldn't do that?
Can you simply apply SSL certs to both client / server and use that as your authentication? If so is that just applied to the Channel used in the connections?
Not sure how to proceed forward with this.
Any suggestions would be greatly appreciated.
Thanks,
S
Take a look at the Hardening WebSphere MQ presentation for v7.0 and earlier. The thing to remember is that WMQ does not authenticate anything. It authorizes based on OS identities and groups but there is no password checking being done.
For situations where QMgrs and clients live on Windows networks, the connection uses the SID and so it appears that some useful authentication was performed. BUT if a connection from a non-Windows platform is attempted, the Windows QMgr uses the string representation of the ID. So for example, if someone has a Linux VM on their desktop they can easily create a user ID called MUSR_MQADMIN and the Windows QMgr will accept the connection. There is a setting that causes the Windows QMgr to only accept connections with SIDS that it can resolve but even there its just a matter of knowing what the SID values are to spoof them on a connection.
The lesson here is that any QMgr, even one on Windows, must be configured to authenticate remote connections. With WMQ v7.1 and later, the QMgr has functionality to map X.509 certificate DNs to user IDs, or to perform IP filtering. Prior to v7.1 these functions required an exit such as BlockIP2. Capitalware sells MQAUSX which has the functions of BlockIP2, plus will perform ID and password authentication and is supported.
The first recommendation is to use a v7.1 QMgr so that you get the CHLAUTH rules for mapping and filtering. Even if you don't use certificates v7.1 limits administrative connections so it is harder for an attacker to gain full admin rights. Then if you need password validation, use SSL channels (to encrypt the password and prevent simply replay attacks) in combination with an exit that you can write yourself or purchase.
Just be aware that allowing a connection from outside your domain doesn't present any new challenges. The pre-v7.1 Windows QMgr that does not have MCAUSER set in the channel definition or by an exit allows remote administrative access, even from connections originating in the local Windows domain. There was always a need to harden that QMgr, even though honest users will have received authorization errors if the administrator did not set up auths for them.
Summary:
For clients originating outside your administrative domain, I'd recommend mutually authenticated TLS/SSL channels. The same page I linked to above also contains the WMQ Security Lab guide and scripts which show how to script the creation and exchange of WMQ certs and configure WMQ Explorer with them.
Whatever else you do, the MCAUSER on any legitimate channel must be set either in the configuration or by an exit. If the client is allowed to specify the ID, there is nothing to prevent it from specifying an administrative ID. For channels that are NOT being used such as SYSTEM.DEF.* and SYSTEM.AUTO.*, set the MCAUSER to a value that cannot be a local ID such as no!body or on v7.1 and later *NOACCESS.