WebSphere MQ running under local account / group cannot read group memberships for Active Directory user. Workaround or alternative resolution?

1

2

I am developing an application that is using WebSphere MQ v6.0. WebSphere MQ is currently not working due to the following issue:

  • WebSphere MQ service runs under local user "MUSR_MQADMIN" in the local group "mqm"
  • I attempt to use the service using my own account, BIZ\noahz
  • MUSR_MQADMIN needs to check if BIZ\noahz is in local group "mqm"
  • MUSR_MQADMIN does not have permission to read the Active Directory group membership of BIZ\noahz
  • The following error appears in the MQ log file:

----- amqzfubn.c : 3582 -------------------------------------------------------

1/31/2011 18:51:32 - Process(704.1105) User(MUSR_MQADMIN) Program(amqzlaa0.exe) AMQ8079: Access was denied when attempting to retrieve group membership information for user 'noahz@biz'.

EXPLANATION: WebSphere MQ, running with the authority of user 'musr_mqadmin@noahz-biz', was unable to retrieve group membership information for the specified user. ACTION: Ensure Active Directory access permissions allow user 'musr_mqadmin@noahz-biz' to read group memberships for user 'noahz@biz'. To retrieve group membership information for a domain user, MQ must run with the authority of a domain user.

----- amqzfubn.c : 3582 -------------------------------------------------------

I found more information is here on IBM's web site: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqtac.doc/wq10830_.htm

I don't have Active Directory admin rights for my Windows machine, so my question is:

Is there anything else I can do to resolve (or work-around) this issue and get WebSphere MQ working for me again? For example, can I disable this security check in WebSphere MQ?

UPDATE Here's the response I got from IBM support:

Usually, these errors indicate a issue with the userid the MQ service is configured to run under in dcom. If you are unsure of what userid this is, you can check with the following:

Open a command prompt and type: dcomcnfg. Once the Component Services MMC opens, double-click "Component Services" double-click "Computers" double-click "My Computer" double-click "DCOM Config". In the window, look for "IBM MQSeries Services", and on it right click, then choose properties. Click on the "Identity" tab. It should show "this user" followed by a id.

Please make sure the MQ services id (from the Identity tab above) has the needed rights locally. Grant it any rights that are missing for the following:

Open Start->Programs->Administrative Tools->Local Security Settings.

Open up Local Policies then User Rights Assignments, double click to check that the following rights are set:
- Logon as batch job
- Logon as service
- Shut down the system
- Debug programs
- Increase quotas
- Act as part of the operating system
- Bypass traverse checking
- Replace a process level token

The end result was that my IT department and InfoSec decided that WebSphere MQ is "server software" and therefore is not allowed on individual work stations, so I never even got to test out the above solution!

noahz

Posted 2011-02-01T18:23:28.700

Reputation: 243

It is worth noting that the solutions given by Rob, AJ and Eduardo address different problems than the one in the question. They work by making sure that the ID presented to MQ is one that MQ can resolve locally. The original problem was that the ID presented was not a local ID and MQ needs to query the domain to get group info. To get MQ running on your workstation those solutions are fine. If what you need is to make sure the Production QMgr doesn't crater because a domain ID was presented, then follow the advice from IBM or my response to grant the needed rights to the MQ svc acct. – T.Rob – 2015-10-14T23:15:22.287

Please see update below. Not sure if that would work for you but it's worth noting for other users with a similar problem. If you care to pass along this experience to the WMQ dev lab, please submit a WMQ Requirement at http://bit.ly/WMQReq which describes how you might want that problem addressed - i.e. disable security at install time, WMQ equivalent of HTACCESS file, LDAP repository, or whatever would work for you.

– T.Rob – 2011-12-06T16:29:48.310

Answers

3

Although I could not find the above mentioned DCOM entries (V7.1 related?), I was able with the aid of the earlier mentioned runas-tip to create, start and connect to a local Windows V7.1 Qmgr without having Active Directory access. This is what I did:

  • Change the password for user MUSR_MQADMIN in the lusrmgr of Windows
  • Check that the MQService has stopped
  • In the service list, change the password for user MUSR_MQADMIN as well
  • Open a DOSbox and execute: C:> runas /user:MUSR_MQADMIN "crtmqm QMGR1" C:> runas /user:MUSR_MQADMIN "strmqm QMGR1" (note that for each command you will have to supply the password)
  • Right-click on the MQ-icon in taskbar and select "WebSphere MQ Explorer"
  • The MQ Explorer opens and should indicate the Qmgr "QMGR1" with a red arrow pointing down. Right-click this icon and select "Start..."
  • In the pop-up select "Start interactive" and click "OK"
  • The QMGR1 icon should now have a green arrow pointing up (started) and its square should be yellow (connected).
  • In the MQ Explorer create a Queue called TEST1 and make its default persistence persistent
  • In the DOSbox execute:
    C:> amqsput TEST1 QMGR1 Type a message ... and then an empty line to end the sample program
  • Now check in the MQ Explorer that your message is there!

Tip: MQ returncodes can be quickly check with the command "mqrc , f.i. C:>mqrc 2085

Rob van der Spek

Posted 2011-02-01T18:23:28.700

Reputation: 31

This was a life-saver. I'd also like to add that it might be necessary to run the MQ Explorer explicitly as MUSR_MQADMIN if you use this solution. – G_H – 2013-11-06T11:48:36.730

1

I know this is an old question, but this is something I've come up against a couple of times since then; so I thought I'd share my experience.

What I did, was get through the installer by selecting no to the domain user options; then:

  1. Check the service is running as Local System Account (Task Manager -> Services -> Services -> IBM Websphere MQ -> Properties -> Log On -> Local System Account)
  2. Set the environment variable to disable OAM (WARNING: THIS DISABLES AUTHENTICATION IN MQ), by setting MQSNOAUT=NO
  3. Add everyone to the mqm group, to be on the safe side.

It worked for me, anyway (Windows 7)

simonalexander2005

Posted 2011-02-01T18:23:28.700

Reputation: 191

Thanks! This is indeed an old question (and I've since moved on from the employer where I encountered this) but I think the core problem I had was no Admin rights over my own machine. Basically, running WebSphere MQ as a developer with no Admin rights on your own machine is a chore :( – noahz – 2017-01-17T16:21:54.920

Agreed!! But I think setting that environment variable removes the need for admin rights, or at least to read group membership – simonalexander2005 – 2017-01-17T17:50:44.183

1

WebSphere MQ will always need to obtain the group membership of any ID attempting to run it's components or authorize access to its resources. If those IDs are non-local then MQ will need rights to perform SAM membership lookups in the domain that owns the ID. There are a couple of workarounds available:

  1. Use a local ID. MQ will always be able to perform lookups in the local SAM database because it must have been installed by an administrator and will have granted itself the appropriate local rights during the install. It doesn't have to be MUSR_MQADMIN but it must be in the mqm group if it's going to run the QMgr.
  2. Use WMQ Explorer to start the QMgr. Any recent version of WMQ Explorer will prompt for different options, one of which is to start the QMgr under the ID that owns the service. Once it is started you can use your regular ID to access queues and topics.

UPDATE:
Wish I'd thought of this before your IT department clamped down, but it is possible to disable the Object Authority Manager. That is the component which performs the lookup on the AD domain. I know that disabling it allows anything to connect to the QMgr without domain permission issues. I am pretty sure doing so also allows your ID to execute the processes that run the QMgr.

T.Rob

Posted 2011-02-01T18:23:28.700

Reputation: 176

My problem is that all user ids and group memberships are managed centrally by Active Directory, I actually don't have permissions to do anything you said. See my response from IBM customer support btw. Thanks! – noahz – 2011-12-06T14:42:17.553

1

I am also developing application with Websphere Message Broker. Currently I have a "developer" edition. I found a way to workaround this by installing MQ with the SAM membership lookout disabled.

For this, I ran "Websphere MQ Launchpad" (run Setup.exe in Windows) from the Installation Directory (Websphere_MQ_V7.5). In the "Network configuration" tab, there is an option to disable the User Id configuration. Choose "No" and perform the installation.

Not that this may not be the best option for production and QA environments.

ajkret

Posted 2011-02-01T18:23:28.700

Reputation: 111

In fact, using another user would be much better, one without spaces, or a pre-configured Websphere Message Broker instance. Later, I had a similar problem running the application. – ajkret – 2016-04-03T13:54:56.197

0

I guess the best shot is to use runas to run as the mq user: 

runas /user:MUSR_MQADMIN "strmqm <qmgr-name>"

Eduardo Costa

Posted 2011-02-01T18:23:28.700

Reputation: 141

Hah, thanks. I uninstalled WebSphere MQ since posting this question, but will try it should the need arise once again. – noahz – 2011-08-19T03:57:32.233

See my latest update. – noahz – 2011-12-06T14:41:11.843

Asked: 2011-02-01T18:23:28.700

Viewed: 28 068 times

Active: 2017-01-17T15:33:34.220