I am facing above error while connecting to queue manager. Let me first explain you what I'm doing.
I have created a new user on Linux machine(test) and then created a server connection channel(xystest.SVRCONN) with MCAUSER as test on XHUB queue manager.
Later i have granted access with the below commands.
setmqaut -m XHUB -t qmgr -p test +connect
setmqaut -m XHUB -n '**' -t q -p test +dsp +inq
setmqaut -m XHUB -n '**' -t channel -p test +dsp
When i try connecting to XHUB using the xystest.SVRCONN I am facing above error.
Can you please help me in understand where i have made mistake while allowing test user to access WMQ ?
I think you should add +inq +dsp permissions for the queue manager too:
setmqaut -m XHUB -t qmgr -p test +connect +inq +dsp
Seems, you are facing authorization error.
WebSphere MQ does not dynamically pick up new users or groups until queue manager been restarted or the Refresh Security of the queue manager. run MQSC command runmqsc XHUB and do REFRESH SECURITY. I hope you made sure, the newly created group is part of mqm group.
The suggestion to refresh security is a valid one so if you have already done that, then try these tips for troubleshooting your authority error:
Set MQSAUTHERRORS to generate WMQ FDC file which will show the error.
Use the MQS_REPORT_NOAUTH environment variable to create an entry in the QMGR error logs to show reason for security failures.
Once you have FDC and/or Log error to show why the authority is failing, you can determine what additional security you may need and then use setmqaut accordingly.
Related
Is it possible to use qload utility to connect to remote queue manager.
I am not able to connect currently and has anyone tried and connected, if so how?
QLoad version : 1.9
I cant see any documentation on how to connect to remote queue manager.
I also tried set MQSERVER variable from command line before executing the command.
qload -m <QM> -i <Queue> -f <filename>
QLOAD Program by Paul Clarke [ V1.9 Build:Jun 19 2012 ]
MQCONN on object '<QM>' returned 2058 QMgr name error..
Invoke QLOAD as follows to use the client libraries.
qload -m <QM> -i <Queue> -l mqic -f <filename>
The -l flag allows to chose the library to be used, mqic vs mqm. The default if the flag is omitted is to use mqm. You can read documentation for a rather more up-to-date version of qload here.
Alternatively, if you want to continue to use the mqm library, you can set the MQ_CONNECT_TYPE environment variable, as described here to make a client connection using the mqm library.
Below commands done for Authorization in Unix + MQ9. Want to review(is this a correct approach or not?) as well as How below commands can be achieved in Windows server?
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)
Update on 29-Mar-2017
is setmqaut can be used as only to required is fine as below ,instead of '**'?
setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n RECEIVE +put +get +browse +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n SEND +put +get +browse +dsp +inq
below commands are required for me , because my jms-client will not pass user details on connection request.Is good approach to pass as below in client code or externalize these values?
MQEnvironment.userID = "mqm";
MQEnvironment.password = "password";
runmqsc TLSTEST.QM
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
ALTER QMGR CHLAUTH(DISABLED)
REFRESH SECURITY TYPE(CONNAUTH)
The commands you provided in your question would work equally as well in windows as they do in Unix.
NOTE The commands you propose turn off security which is not a good thing to do and also authorized the user "clientadmin" to all queues on the queue manager including SYSTEM* queues which allows that user to leverage MQ administrative authority.
Commands from your 29-Mar-2017 update look fine for providing specific permissions to queues SEND and RECEIVE.
In my opinion it would be a good approach to externalize the values for userID and password so that you do not need to recompile things if these change in the future.
Having an application connect as mqm is not a good approach since mqm has full administrative authority.
Setting CHLAUTH(DISABLED) does not prevent password checking it just turns off the normal out of the box CHLAUTH rules which prevent MQ admins from connecting to SVRCONN channels, as well as preventing usage of SYSTEM.* channels.
Setting CHCKCLNT(OPTIONAL) from the default of CHCKCLNT(REQDADM) configures MQ to check that a password is valid only if a password is supplied to MQ.
The default value CHCKCLNT(REQDADM) is the same as CHCKCLNT(OPTIONAL) with the additional requirement that that accounts with MQ admin authority are required to supply a valid password. Accounts without MQ admin authority are not required to present a valid password but if a password is supplied it must be valid.
If your configuration only works with CHCKCLNT(OPTIONAL) it would indicate that you are connecting as an account that has MQ admin authority.
There is a security issue with setting MQ to not enforce that a valid password is sent unless you use SSLCIPH and SSLPEER to restrict a SVRCONN to allow only specific client certs to connect and you make sure all other channels are locked down. The default CHLAUTH rules lock down all channels by not allowing users with MQ admin authority to connect, and they block connections to all SYSTEM* channels.
Setting SSLCAUTH(OPTIONAL) configures MQ to not require that the client have a certificate, if the client does have a certificate MQ will validate it is trusted, and if you have a SSLPEER set will make sure the client certificate DN value matches.
SSLCAUTH(REQUIRED) configures MQ to require that the client have a cert. You would also want to pair this with the channels SSLPEER setting to ensure the cert is the one that you expect not just a cert that is trusted by the queue manager, you also want to set the MCAUSER to a low privileged user.
Setting CHLAUTH(DISABLED) likely is making the SYSTEM.* channels insecure.
If you have no other mitigating controls the configuration presented is insecure.
I need to backup the queue and delete the first message in the queue. I have used the below code
./qload -m qmgr SYSTEM.CLUSTER.TRANSMIT.QUEUE -r 1
Also I need to display first message has been deleted
I have found the answer.It works for me
qload -m $qmgr -I $qname -f <qmgr>_<qname>_<date>.log -r 1
I have tried saveqmgr and dmpmqcfg. i cannot get expected output.
dmpmqcfg -m qm.apple -t all -a -x all -o setmqaut
I am using MQ_7.5 version. Which command is used to take backup of MQ Message queue in linux
You can use a command similar to the following to backup the details of a specific queue (TEST.QUEUE in this example). The output will include both the DEFINE Q command along with SET AUTHREC commands to restore any OAM permissions granted to that specific queue. Note that this command will not backup OAM for any other queue or wild carded permissions.
dmpmqcfg -m qm.apple -n TEST.QUEUE -t queue -a -x all -o 1line
To backup the data in the queue you can use the MO03 SupportPac (aka QLOAD) from IBM. This SupportPac from IBM has been withdrawn because at v8 of the product it was integrated and renamed to dmpmqmsg. For versions of MQ prior to v8 you can still download the MQ03 SupportPac at the above link. The original author of the SupportPac also now maintains a version of the program called QLOAD.
Example command below will backup a queue called TEST.QUEUE with out removing the messages from the queue (change the -i to capital -I to also remove them from the queue).
qload -m qm.apple -i TEST.QUEUE -f TEST.QUEUE.qload
Output will show how many messages were read and written, example output is below:
Read - Files: 0 Messages: 3 Bytes: 4
Written - Files: 1 Messages: 3 Bytes: 4
Example command below will put the messages from the file back onto the queue.
qload -m qm.apple -f TEST.QUEUE.qload -o TEST.QUEUE
Hello I have queue manager with name QM_1. Here I have taken backup of QM_1 like following.
after that I created queue manager(QM_1) with same name in other system and I need to restore the save qmgr properties. Pls provide how to restore the queuemanager properties?
saveqmgr -m QM_1 -f
Some of the options are are on the SupportPac MS03 landing page. (MS03 is the SupportPac that contains the saveqmgr program.) Detailed instructions are in the download documentation. The following instructions are copied from the SupportPac MS03 page:
You can run the following saveqmgr command (see below) to create 2 output files. Both output files are text and they can be edited.
one with the object definitions (using option -f) - the file name in this example is: qmgr_data.mqsc
the other with the authority records (using option -z which generates entries for setmqaut)
the file name in this example is: qmgr_auth.bat (in Windows) or qmgr_auth.sh (in UNIX)
The following command saves both the objects and the authority records:
UNIX:
saveqmgr -m QMGR -f /tmp/mq/qmgr_data.mqsc -z /tmp/mq/qmgr_auth.sh
Windows:
saveqmgr.exe -m QMGR -f C:\temp\mq\qmgr_data.mqsc -z C:\temp\mq\qmgr_auth.bat
The file qmgr_data.mqsc can be run as follows when trying to restore the contents into a new queue manager:
runmqsc TEST < qmgr_data.mqsc
The file qmgr_auth.bat (in Windows) or qmgr_auth.sh (in UNIX) has stand-alone entries that invoke the setmqaut command with the proper parameter for each authority record. This batch/script file will need to be executed in order to restore the authority records.
UNIX:
chmod u+x qmgr_auth.sh
./qmgr_auth.sh
Windows:
qmgr_auth.bat
To find this and all the other SupportPacs, go to the SupportPac landing page here.
Update 6 November 2014:
Although OP asked how to restore from a saveqmgr backup, it is worth noting that IBM has provided the dmpmqcfg command beginning with version 7.1. You can back up the QMgr in MQSC format using this syntax:
dmpmqcfg -m [QUEUE_MANAGER] > BACKUP_FILE.mqsc
This captures the object deinifions and the authorizations in a single file. The authorizations are captured as SET AUTHREC entries rather than as setmqaut commands by default.
Please note that the initial versions of dmpmqcfg did not capture all of the authorization settings that you might have defined. It is necessary for all versions to apply the latest Fix Pack to get a reliable backup using dmpmqcfg. This behavior may regress in later Fix Packs so it is advisable to reconcile your backup against your auths creation script when switching to this command and after applying a Fix Pack.
Restore a QMGgr from the dmpmqcfg file the same as you would from the saveqmgr file:
runmqsc [QMNAME] < output_of_dmpmqcfg_or_saveqmgr.mqsc > logfile.txt 2>&1
This runs the MQSC file definitions into the QMgr (including SET AUTHREC commands) and saves the output of STDOUT and STDERR to a log file.