Can create Websphere Queue Manager but not connect

Question

I need to write a .Net connector to WebSphere MQ queues so I've installed a trial version of IBM WebSphere MQ on my Windows 7 machine. I initially setup some dummy queues in MQ Explorer to play with the setup process and I was able to connect to those queue managers and create queues. I deleted those dummy queues and followed the first set of instructions from Lesson 1.1 from IBM here where I created some queues from the command line

I failed to run Lesson 1.2 because of security issues, and I now cannot connect to any queue managers in MQ Explorer. when I try to connect I get the error message

An unexpected error (2063) has occurred. (AMQ4999)

• I am local admin on my machine.
• I've added myself to the mqm group that was created
• I've run the MQ Explorer both with and without the 'Run as Administrator' option
• I've uninstalled MQ and re-installed it
• I've rebooted several times

I've also noticed that when I create a queue manager in MQ Explorer, the last part fails with AMQ8135: Not authorized. (see output below)

Is there something obvious that I am missing?

Is there some way that I can work out what the problem is myself - the log files don't seem to give me any idea where to look

---

****************************************
* Command: "C:\Program Files (x86)\IBM\WebSphere MQ\bin\crtmqm"  -sa  QM1
****************************************
There are 90 days left in the trial period for this copy of WebSphere MQ.
WebSphere MQ queue manager created.
Directory 'C:\Program Files (x86)\IBM\WebSphere MQ\qmgrs\QM1' created.
The queue manager is associated with installation 'Installation2'.
Creating or replacing default objects for queue manager 'QM1'.
Default objects statistics : 74 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
exitvalue = 0
****************************************
* Command: "C:\Program Files (x86)\IBM\WebSphere MQ\bin\strmqm" QM1
****************************************
There are 90 days left in the trial period for this copy of WebSphere MQ.
WebSphere MQ queue manager 'QM1' starting.
The queue manager is associated with installation 'Installation2'.
5 log records accessed on queue manager 'QM1' during the log replay phase.
Log replay for queue manager 'QM1' complete.
Transaction manager state recovered for queue manager 'QM1'.
WebSphere MQ queue manager 'QM1' started using V7.1.0.0.
exitvalue = 0
****************************************
* Command: "C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqsc" QM1
* Input: DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)
****************************************
5724-H72 (C) Copyright IBM Corp. 1994, 2011.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM1.
AMQ8135: Not authorized.
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
exitvalue = 20

Answer 1

If you have a recent trial version of WMQ then you are working with a v7.1 QMgr. As of v7.1 WMQ will allow only non-privileged remote connections. In order to connect with an administrator account, it will be necessary to either disable the restrictions or, better yet, to define a new channel for the administrative connection and authenticate it.

With Windows the biggest issue is that WMQ authenticates domain IDs and must look up their groups. One very common problem when running WMQ in a corporate environment is that it attempts to lookup an ID or group and does not have the domain rights to do so. Domain accounts, even those with local admin rights, often fail because they don't have access to inquire in the domain SAM to do group lookups. There's a whole section in the Infocenter here describing the requirements for Windows accounts.

One workaround for this for dev environments only is to create a local administrator's account, then log on with that and create the QMgr. Or make sure that the default account MUSR_MQADMIN has local admin rights and login rights. Again,, you must actually log in with the account to make this work because that way there is never a requirement to look up an account in Active Directory because it all hits the local SAM database. Again, this is just for development! In Production you'd want to use a real domain account and grant it the correct access rights to do SAM lookups but NOT make it a local admin, as described in the Infocenter section linked above.

Assuming that you have succeeded in creating the QMgr, next create a new channel and authorize it to accept your local connections using the admin account:

runmqsc
* Define the channel, anyone connecting runs as MUSR_MQADMIN
DEFINE CHL('DOTNET.SVRCONN')  CHLTYPE(SVRCONN) MCAUSER('MUSR_MQADMIN@hostname')

* Override default block-list - channel now allows ANYBODY
SET CHLAUTH('DOTNET.SVRCONN') TYPE(BLOCKUSER) USERLIST('nobody')

* Block access from ALL IP addresses
SET CHLAUTH('DOTNET.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) WARN(NO) ACTION(ADD)

* Allow access from local host only
SET CHLAUTH('DOTNET.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('127.0.0.1') USERSRC(CHANNEL) ACTION(ADD) 

END

Now you have a channel that will accept local connections ONLY, map these to an administrative account and then override the security that prevents administrative accounts from connecting remotely. Using the admin account means that no queue or QMgr authorizations are required and the account being a local admin means that there are no domain lookup issues. The MCAUSER('MUSR_MQADMIN) converts every remote ID to the local admin ID so that WMQ doesn't need to look up the remote IDs. The mapping rule restricts connections to the local host only. Anyone who can connect to the channel will have local admin on the box with the ability to remotely execute OS code so if you wanted to accept connections from other users, authenticating them with certificates would be recommended.

Answer 2

You may want to read this post by T.Rob here. Also other security related posts from him, they are very helpful.